OpenVPN

Security-all

OpenVPN

  • 10638 megtekintés

( oaki | 2005. 03. 08., k – 18:35 )

[quote:3cc2a9fd05="norcrys"]Az a problémánk, hogy új Win-es Xp-s gépen az OpenVPN nem hozza létre a TAP interface-t. A gynús, hogy ez Service Pack 2-s, míg az előző nem, azon gond nélkül megy.
Valakinek van ebben tapasztalata?

Szió! Nekem megy a 2.0-s SP2-n és SP1-esen is. Bár azt nemtudom, hogy mi volt fent előbb, de biztos volt olyan is ahol vent volt az SP2 mielött az OVPN felment volna. Simán felment mindenhol és nem volt vele szívás.

( dragi v | 2005. 11. 14., h – 10:30 )

Nekem annyi problemam akadt openvpn-el, hogy egyik helyen server-cliens teljesen jol mukodik, masik server-kliens paros ugyan azzal a configgal nem mukodik jol. Ertem ez alatt, hogy a kapcsolat letrejon, nincs hibauzenet, de olyan mintha a route-t elszurna az openvpn, mert nem tudom pingelni a servert. Mit kell megadni a tun devicenak route-nak? Vagy az openvpnnek?

( asd | 2005. 11. 14., h – 10:33 )

[quote:ed8bb7d068="dragi"]cliens

client vagy kliens, legyszi ne alkoss uj szavakat. Kerdesedre valaszolva olvasd el a mant.

( tolmi | 2005. 09. 07., sze – 18:42 )

Egy kis segítséget kérnék én is. Tudom hogy vmi egyszerű dolgot b*sztam el, de már sztem túlságosan ráálltam és nem látom a fától az erdőt.

OpenVPN-nel csináltam VPN tunnelt. A hálózatok paraméterei:
Server tűzfal mögött van, de rálátok az OpenVPN tcp port-jára közvetlen. A serverben egy db hálókártya van.
Server IP: 222.111.0.1/24
OpenVPN server endpoint: 222.111.0.253/24
A kliens meg ezt kapja: 222.111.0.2/24

A kapcsolat felépül, a kliens tudja pingelni a szerver mind külső, mind tun0-s IP-jét. Szerver tudja pingelni klienst. De kliens semmit sem lát a szerverrel azonos hálón levő gépekből, sem ők a kliensből.

Megpingeltem egy gépet a serverrel azonos hálón a kliensről. a tcpdump -i eth0 azt mondja hogy request kimegy és a célállomás arp-who val keresi, hogy ki az a 222.111.0.2, de nem kap választ. Nem kellene a VPN szerveremnek válaszolni véletlen a kérdésre? Szóval vmit bizton elnéztem.

Segítséget előre is köszönöm,
egy meggyötört lélek :roll:

( trey | 2005. 02. 04., p – 11:10 )

Tipp: ha NAT mogott van a kliens, akkot --float -tal kene szerintem inditani rajta az OpenVPN-t.

--verb 9 sokat tud segiteni

( vavhab v | 2005. 01. 08., szo – 12:32 )

Hi!

Problemam: Elerni egy NAT-tol belso halozatot kivulrol, viszont a routerre nem lehet VPN servert rakni.
Azt csinaltaom, hogy a kint gepen ugy alllitottam be openvpn-t, hogy az legyen a szerver
a kliens pedig a NAT-olt halozatban van(de nem a router). Igy a kliens tud kapcsolodni a kint levo gephez.
A tunnel fel is epul rendesen es a NATolt halobol akár internetezni is tudok a VPN csatornan keresztul. A problema az hogy a kint geprol nem lehet elerni a natolt haloban levo kliens mogotti halozatot. Kinti geprol pingelek egy belso halon levo gepet. tcpdump -i tun0 mindket gepen a kinti gepen latni hogy a csomagok megjelennek a tun0 device-on viszont a cliens vpn gepen nem jelenik meg a tun0 device-on. Otlet hogy hol veszik el a csomag? Olyan mintha a szerver openvpn nem kuldene tovabb a csomagot a kliens fele.

szerver config:
local x.x.x.x
port xxxxx
proto tcp
dev tun

ca /etc/openvpn/ssl/cacert.pem
cert /etc/openvpn/ssl/server_pubcert.pem
key /etc/openvpn/ssl/server_key.pem
tls-server
dh /etc/openvpn/ssl/dh1024.pem
server 10.2.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir /etc/openvpn/ccd
keepalive 10 120
comp-lzo
max-clients 15
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 4
up /etc/openvpn/server.up

Kliens config:
client
dev tun
proto tcp
remote x.x.x.x xxxxx

resolv-retry infinite
nobind
persist-key
persist-tun
ca /usr/local/etc/openvpn/ssl/cacert.pem
cert /usr/local/etc/openvpn/ssl/client1_pubcert.pem
key /usr/local/etc/openvpn/ssl/client1_key.pem
tls-client
tls-auth /usr/local/etc/openvpn/server.key 1
comp-lzo
verb 4

Bocs ha kicsit hosszra sikerult, remelem erthetoen irtam le a problemat.
Elore is koszi a valaszt!

( nc | 2005. 03. 08., k – 14:05 )

Az a problémánk, hogy új Win-es Xp-s gépen az OpenVPN nem hozza létre a TAP interface-t. A gynús, hogy ez Service Pack 2-s, míg az előző nem, azon gond nélkül megy.
Valakinek van ebben tapasztalata?

( LiRul v | 2005. 03. 08., k – 15:39 )

[quote:d4d1995d99="norcrys"]Az a problémánk, hogy új Win-es Xp-s gépen az OpenVPN nem hozza létre a TAP interface-t. A gynús, hogy ez Service Pack 2-s, míg az előző nem, azon gond nélkül megy.
Valakinek van ebben tapasztalata?

Jah, Friczy szivott a 2.0-as ovpn-nel, nem tudom mire jutott, de az 1.6 allitolag megy neki. Na most jo sokat segitettem. :lol:

( Gaab | 2005. 03. 08., k – 16:11 )

[quote:89ca3e12b3="norcrys"]Az a problémánk, hogy új Win-es Xp-s gépen az OpenVPN nem hozza létre a TAP interface-t. A gynús, hogy ez Service Pack 2-s, míg az előző nem, azon gond nélkül megy.
Valakinek van ebben tapasztalata?

Marmint a telepito nem hozza letre az interface-t? mert annak kellene, nem maganak az openvpnnek.. ami nalam szokott elofordulni az az, hogy a gepek ~20%-an a vpn kapcsolat inditasakor, az autentikacio utan egy hibat dob, ami a faq szerint azt jelenti, hogy a tap interface-en nem lehetett beallitani a megfelelo IP cimet. Sot, van hogy a tobbi gepen is csak 2-3-4-szeri inditasra megy, es eloszor szinten a fenti hibaval elszall.

( bterv | 2010. 09. 23., cs – 13:25 )

Sziasztok!

Az OpenVPN beállításában szeretnék segítséget kérni.

Egy CentOS 5.4-es rendszerre telepítettem az OpenVPN-t.


rpm -qa | grep openvpn
openvpn-2.0.9-1el5.rf
rpm -qa | grep lzo
lzo2-2.02-3.el5.rf

A server.conf tartalma:


port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
server 192.168.10.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/ipp.txt
push "route 10.0.0.0 255.255.255.0"
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3
mute 20

A kliensen lévő szerver.ovpn tartalma:


client
remote "külső IP címünk"
port 1194
proto udp
ca C:\\Progra~1\\OpenVPN\\config_szerver\\ca.crt
cert C:\\Progra~1\\OpenVPN\\config_szerver\\client00.crt
key C:\\Progra~1\\OpenVPN\\config_szerver\\client00.key
dev tun
comp-lzo
verb 3
mute 10
ns-cert-type server
persist-key
persist-tun

A router beállításai szerintem megfelelőek, mert a kapcsolat létrejön. Lényegében működik az OpenVPN kapcsolat mert ha távolról feljelentkezek, akkor sikeresen csatlakozik, kapok IP-t, bekerülök a hálózatba.

A probléma az, hogy nem látom a szervert, nem tudok ráPuttyolni, sem pingelni, sőt ha kapcsolódtam OpenVPN-en keresztül, akkor onnantól kezdve megszűnik a helyi hálózatom.

Ebben kérném a segítségeteket! Köszi!

Ha a LAN-od a 10.0.0.*, akkor kell az a push 10.0.0.0 ...
ezzel csinálsz route-ot a kliensen a szerver felé, hogy a szerver routolja majd a 10.0.0.*-os címeket.

Kérdés, hogy a szerveren engedélyezve van-e az ip_forward-ing. Anélkül nem fog route-olni a szerver, hiába van route info megadva.

Továbbá a szerveren a VPN ip tartományából/ba menő cuccokat át kell engedni.
A tun device forgalmát meg full-ban át kell engedni.

Emellett meg a tcp-wrappers esetleges tiltásait is át kell molyolni (hosts.allow, hosts.deny )
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

"Ha a LAN-od a 10.0.0.*, akkor kell az a push 10.0.0.0 ...
ezzel csinálsz route-ot a kliensen a szerver felé, hogy a szerver routolja majd a 10.0.0.*-os címeket."

miert kellene belekeverni a LAN settinget az openvpn szerver konfigba?
az elobb irtam, hogy a route-ot a kliensen a szerver fele megoldja a "server 192....", ha tun-t hasznal

"Kérdés, hogy a szerveren engedélyezve van-e az ip_forward-ing. Anélkül nem fog route-olni a szerver, hiába van route info megadva."

minek ide ip forward? mit nem fog routolni a szerver? a sajat szubnetjeben levo packeteket??

szerintem pont az a gond, hogy a push felulirja a lokalis LAN route-jat.

miert kellene belekeverni a LAN settinget az openvpn szerver konfigba?
Mert a push route-tal mondod meg a kjliens netconfigjának, hogy milyen subnetek rout-ja menjen a klien tun/tap eszközén keresztül (feltéve, hogy nem default route-nak tette be a tun/tap eszközt).

az elobb irtam, hogy a route-ot a kliensen a szerver fele megoldja a "server 192....", ha tun-t hasznal
Ez korántsem biztos. Pontosabban a VPN ip tartomáyn címeire való route-olást igen, de egyebet nem.

minek ide ip forward? mit nem fog routolni a szerver? a sajat szubnetjeben levo packeteket??
Azért, hogy ha a szerver VPN-es subnetjéből ki szeretnél látni a szerver oldalon, akkor lehessen forwardolni.
Partikuláris esetben, ha szervernek van még 3 net interfésze, akkor nemhogy azokra, de még a localhost-ra sem fogsz tudni átmenni a szerveren a tun eszközről.
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

szerver config:

port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
server 192.168.10.0 255.255.255.0 -> VPN subnet: 192.168.10.0/24
ifconfig-pool-persist /etc/openvpn/ipp.txt
push "route 10.0.0.0 255.255.255.0" -> LAN? subnet: 10.0.0.0/24
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3
mute 20

ehhez képest a kliens log:

Thu Sep 23 14:32:04 2010 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Thu Sep 23 14:32:05 2010 PUSH: Received control message: 'PUSH_REPLY,route 192.168.10.0 255.255.255.0,route 192.168.10.0 255.255.255.0,ping 10,ping-restart 120,ifconfig 192.168.10.6 192.168.10.5' -> kétszer push-ol route-ot ugyanarra a subnetre (ergo a push route 10.0.0.0 stb.-t kivette a szerver configból a kolléga (valszeg a psuh sorban átírta az ip tartományt 10.0.0.0-ról 192...-ra és így lesz kétszer route adás ugyanarra a tartományra)
Thu Sep 23 14:32:05 2010 OPTIONS IMPORT: timers and/or timeouts modified
Thu Sep 23 14:32:05 2010 OPTIONS IMPORT: --ifconfig/up options modified
Thu Sep 23 14:32:05 2010 OPTIONS IMPORT: route options modified
Thu Sep 23 14:32:05 2010 TAP-WIN32 device [Helyi kapcsolat 2] opened: \\.\Global\{6CDA63AB-DE6D-4893-A5D6-3E3A24F564BC}.tap
Thu Sep 23 14:32:05 2010 TAP-Win32 Driver Version 8.1
Thu Sep 23 14:32:05 2010 TAP-Win32 MTU=1500
Thu Sep 23 14:32:05 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.10.6/255.255.255.252 on interface {6CDA63AB-DE6D-4893-A5D6-3E3A24F564BC} [DHCP-serv: 192.168.10.5, lease-time: 31536000]
Thu Sep 23 14:32:05 2010 Successful ARP Flush on interface [3] {6CDA63AB-DE6D-4893-A5D6-3E3A24F564BC}
Thu Sep 23 14:32:05 2010 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Thu Sep 23 14:32:05 2010 Route: Waiting for TUN/TAP interface to come up...
Thu Sep 23 14:32:06 2010 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Thu Sep 23 14:32:06 2010 route ADD 192.168.10.0 MASK 255.255.255.0 192.168.10.5 -> ez a server 192.168.10.0 255.255.255.0 szerverconfig sor miatt
Thu Sep 23 14:32:06 2010 Route addition via IPAPI succeeded
Thu Sep 23 14:32:06 2010 route ADD 192.168.10.0 MASK 255.255.255.0 192.168.10.5 -> ez meg a (szerintem) átírt push "route 10.0.0.0 ..." -> push "route 192..." miatt
Thu Sep 23 14:32:06 2010 Route addition via IPAPI succeeded
Thu Sep 23 14:32:06 2010 Initialization Sequence Completed

nem lelkes write-only módú vitatkozó vagyok ... :)

de a fentiek alapján, ha csatlakozott a VPN-re világvégéről és nem tudja PUTTY-olni a szervert, akkor:
A szerveren az SSH vagy nem a keresett porton figyel, vagy hosts.denied áldozata lett a VPN kliens IP-ről a request. Vagy a szerveren tűzfal is van (nem tudom).

Ha a VPN-re csatlakozott kliensről a LAN-os masinákat akarná elérni, akkor az előbbiek mellett még ip-forward is kell (+ tűzfalon való áteregetés VPN ip subnetről vagy a kliens VPN-es IP-jéről a cél host felé, ha van tűzfal is)
+ a LAN-on csücsülő host-nak kell legyen route információja arról, hogy merre kell küldeni a packeteket, ha el akar jutni a VPN-en csücsülő csatlakozott klienshez (mivel enélkül az eddigiek alapján a request a VPN-es kliensről a LAN-os hostra elér, de a válasz már nem megy vissza.)

és még lehet ragozni.

Az, hogy a VPN-re csatlakozás után elmegy a LAN a kapcsolódot hoston, sokminden miatt lehet.

---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

( bterv | 2010. 09. 23., cs – 14:37 )


Thu Sep 23 14:32:03 2010 OpenVPN 2.0 Win32-MinGW [SSL] [LZO] built on Apr 17 2005
Thu Sep 23 14:32:03 2010 LZO compression initialized
Thu Sep 23 14:32:03 2010 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Sep 23 14:32:03 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:23 ET:0 EL:0 AF:3/1 ]
Thu Sep 23 14:32:03 2010 Local Options hash (VER=V4): '41690919'
Thu Sep 23 14:32:03 2010 Expected Remote Options hash (VER=V4): '530fdded'
Thu Sep 23 14:32:03 2010 UDPv4 link local (bound): [undef]:1194
Thu Sep 23 14:32:03 2010 UDPv4 link remote: külsőipcím:1194
Thu Sep 23 14:32:03 2010 TLS: Initial packet from külsőipcím:1194, sid=5921e64d b049205c
Thu Sep 23 14:32:03 2010 VERIFY OK: depth=1, /C=HU/L=Jaszbereny/O=HairCare/CN=HairCare_CA/emailAddress=tarjani.peter@abas.hu
Thu Sep 23 14:32:03 2010 VERIFY OK: nsCertType=SERVER
Thu Sep 23 14:32:03 2010 VERIFY OK: depth=0, /C=HU/L=Jaszbereny/O=HairCare/CN=server/emailAddress=tarjani.peter@abas.hu
Thu Sep 23 14:32:03 2010 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Sep 23 14:32:03 2010 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 23 14:32:03 2010 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Sep 23 14:32:03 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 23 14:32:03 2010 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Sep 23 14:32:03 2010 [server] Peer Connection Initiated with külsőipcím:1194
Thu Sep 23 14:32:04 2010 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Thu Sep 23 14:32:05 2010 PUSH: Received control message: 'PUSH_REPLY,route 192.168.10.0 255.255.255.0,route 192.168.10.0 255.255.255.0,ping 10,ping-restart 120,ifconfig 192.168.10.6 192.168.10.5'
Thu Sep 23 14:32:05 2010 OPTIONS IMPORT: timers and/or timeouts modified
Thu Sep 23 14:32:05 2010 OPTIONS IMPORT: --ifconfig/up options modified
Thu Sep 23 14:32:05 2010 OPTIONS IMPORT: route options modified
Thu Sep 23 14:32:05 2010 TAP-WIN32 device [Helyi kapcsolat 2] opened: \\.\Global\{6CDA63AB-DE6D-4893-A5D6-3E3A24F564BC}.tap
Thu Sep 23 14:32:05 2010 TAP-Win32 Driver Version 8.1
Thu Sep 23 14:32:05 2010 TAP-Win32 MTU=1500
Thu Sep 23 14:32:05 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.10.6/255.255.255.252 on interface {6CDA63AB-DE6D-4893-A5D6-3E3A24F564BC} [DHCP-serv: 192.168.10.5, lease-time: 31536000]
Thu Sep 23 14:32:05 2010 Successful ARP Flush on interface [3] {6CDA63AB-DE6D-4893-A5D6-3E3A24F564BC}
Thu Sep 23 14:32:05 2010 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Thu Sep 23 14:32:05 2010 Route: Waiting for TUN/TAP interface to come up...
Thu Sep 23 14:32:06 2010 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Thu Sep 23 14:32:06 2010 route ADD 192.168.10.0 MASK 255.255.255.0 192.168.10.5
Thu Sep 23 14:32:06 2010 Route addition via IPAPI succeeded
Thu Sep 23 14:32:06 2010 route ADD 192.168.10.0 MASK 255.255.255.0 192.168.10.5
Thu Sep 23 14:32:06 2010 Route addition via IPAPI succeeded
Thu Sep 23 14:32:06 2010 Initialization Sequence Completed

Ez az OpenVPN kliens log-ja. Köszi a segítséget és a villám gyorsaságot! :)

Elso korben 2x van route add bejegyzes, ami felesleges, illetve

Thu Sep 23 14:32:05 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.10.6/255.255.255.252 on interface {6CDA63AB-DE6D-4893-A5D6-3E3A24F564BC} [DHCP-serv: 192.168.10.5, lease-time: 31536000]

itt /22 a netmask, mig a sima route bejgyezesnel /24. Kellene meg netstat -r kimenet.

Most akkor épp mi a helyzet?

LAN:192.168.10.0/24
VPN:10.8.0.0/24

?
Igy a szerver konfigban:
server 10.8.0.0 255.255.255.0
...
push "route 192.168.10.0 255.255.255.0"
# szerver oldali LAN IP tartomány route infója a kliensre

hm?
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Ahogy mondod igen. Módosítottam is a szerver.conf-ot ahogy írtad és így jelenleg működik is a dolog. Elérhető a szerver, de még nem tudtam mindent alaposan kipróbálni, betallózni még nem sikerült a szerverre, de holnap még megnézem mi lehet a baja. Végre már el lehet érni meg a kapcsolat is rendben van. Köszi szépen a segítséget!!!

Jelenleg odáig jutott a dolog, hogy teljesen jól működik az OpenVPN kapcsolat, simán felcsatlakozik, sőt most már a helyi hálózatomat sem dobja el, ugyanúgy a net-re is kilátok. A probléma az, hogy tudom ugyan a szervert ping-elni, rá tudok már putty-olni de nem látom a samba megosztásait.

OpenVPN kliens log-ja:


Fri Sep 24 08:39:46 2010 OpenVPN 2.1_rc19 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Jul 16 2009
Fri Sep 24 08:39:46 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Sep 24 08:39:46 2010 LZO compression initialized
Fri Sep 24 08:39:46 2010 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Sep 24 08:39:46 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Sep 24 08:39:46 2010 Local Options hash (VER=V4): '41690919'
Fri Sep 24 08:39:46 2010 Expected Remote Options hash (VER=V4): '530fdded'
Fri Sep 24 08:39:46 2010 Socket Buffers: R=[8192->8192] S=[64512->64512]
Fri Sep 24 08:39:46 2010 UDPv4 link local (bound): [undef]:1194
Fri Sep 24 08:39:46 2010 UDPv4 link remote: külsőipcím:1194
Fri Sep 24 08:39:46 2010 TLS: Initial packet from külsőipcím:1194, sid=796ca71e f30a8d35
Fri Sep 24 08:39:47 2010 VERIFY OK: depth=1, /C=HU/L=Jaszbereny/O=HairCare/CN=HairCare_CA/emailAddress=tarjani.peter@abas.hu
Fri Sep 24 08:39:47 2010 VERIFY OK: nsCertType=SERVER
Fri Sep 24 08:39:47 2010 VERIFY OK: depth=0, /C=HU/L=Jaszbereny/O=HairCare/CN=server/emailAddress=tarjani.peter@abas.hu
Fri Sep 24 08:39:47 2010 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 24 08:39:47 2010 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 24 08:39:47 2010 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 24 08:39:47 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 24 08:39:47 2010 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Sep 24 08:39:47 2010 [server] Peer Connection Initiated with külsőipcím:1194
Fri Sep 24 08:39:48 2010 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Fri Sep 24 08:39:48 2010 PUSH: Received control message: 'PUSH_REPLY,route 192.168.10.0 255.255.255.0,route 10.8.40.0 255.255.255.0,ping 10,ping-restart 120,ifconfig 10.8.40.6 10.8.40.5'
Fri Sep 24 08:39:48 2010 OPTIONS IMPORT: timers and/or timeouts modified
Fri Sep 24 08:39:48 2010 OPTIONS IMPORT: --ifconfig/up options modified
Fri Sep 24 08:39:48 2010 OPTIONS IMPORT: route options modified
Fri Sep 24 08:39:48 2010 ROUTE default_gateway=10.0.0.2
Fri Sep 24 08:39:48 2010 TAP-WIN32 device [Helyi kapcsolat 2] opened: \\.\Global\{475CD124-7E62-40F4-AD71-DC2AAE0C4485}.tap
Fri Sep 24 08:39:48 2010 TAP-Win32 Driver Version 9.6
Fri Sep 24 08:39:48 2010 TAP-Win32 MTU=1500
Fri Sep 24 08:39:48 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.8.40.6/255.255.255.252 on interface {475CD124-7E62-40F4-AD71-DC2AAE0C4485} [DHCP-serv: 10.8.40.5, lease-time: 31536000]
Fri Sep 24 08:39:48 2010 Successful ARP Flush on interface [3] {475CD124-7E62-40F4-AD71-DC2AAE0C4485}
Fri Sep 24 08:39:53 2010 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Fri Sep 24 08:39:53 2010 C:\WINDOWS\system32\route.exe ADD 192.168.10.0 MASK 255.255.255.0 10.8.40.5
Fri Sep 24 08:39:53 2010 Route addition via IPAPI succeeded [adaptive]
Fri Sep 24 08:39:53 2010 C:\WINDOWS\system32\route.exe ADD 10.8.40.0 MASK 255.255.255.0 10.8.40.5
Fri Sep 24 08:39:53 2010 Route addition via IPAPI succeeded [adaptive]
Fri Sep 24 08:39:53 2010 Initialization Sequence Completed

Ha már fel vagyok csatlakoztatva, akkor beírom a futtatásba, hogy:


\\szerver
\\192.168.10.200

De egyik parancsra sem mutatja a megosztást.

A Samba szépen fut.

smbclient -L szerver parancsra szépen kilistázza a megosztásokat.

Köszönöm a segítséget!

Megvan a bűnös!!!

Az smb.conf-ban a hosts allow = 10.8.40.0/24 bejegyzéssel volt a gond, mert az még a régi hálózatra hivatkozott.

Szerintem így már minden teljes és jól működik! Nagyon szépen köszönöm mindenkinek a sok segítséget és a gyorsaságot! Ezer hála érte! :)

Azért azt gondold meg, hogy feltétlen kell-e a redirect-gateway.
Így ugyanis minden hálóforgalmat a VPN szerveren keresztül fog eregetni a felcsatlakozott kliens, ami nem biztos, hogy jó ötlet.

Abban az esetben, ha a (VPN) szerver nem valami vastag madzagon lóg a neten (nem egy ISP szervertermében van pl.), hanem valami DSL-en vagy bérelt vonalon lóg, akkor annak a vonalnak a felfelé menő sebessége lesz a klienseid szűk keresztmetszete, ha elindítasz egy böngészőt és megnézed az index-et pl.

Nem tudom mennyi VPN-es kliensed lesz, de ha azok mind a szerveren keresztül böngészgetnek, akkor a helyi hálón lévők ennek nem biztos, hogy nagyon örülnek majd.

Meg a DHCP-vel is lehetnek gondjaid a VPN klienseken, mivel a default route felülvágás miatt nem fogják elérni a csatlakozás előtti DHCP szervert címfrissítéshez.
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Nem egészen értem ezt a dolgot. Igazából úgy nézne ki a dolog, hogy Budapestről becsatlakoznak OpenVPN-en keresztül ebbe a jászberényi hálózatba és a szerveren lévő samba megosztást használják. Ott van egy program amin dolgoznak. Ez azért kell hogy így legyen mert a szerveren lévő adatbázisokat használja a program.

Hogyan tudnám ezt a redirect-gateway-t kikapcsolni, mert szerintem akkor nekünk erre nem lesz szükségünk? Vagy nem is tudom igazán, most egy kicsit megkavarodtam... :S

Köszi! :)

Simán kiveszed a szerver configból a "redirect-gateway"-t és kész.

Így annyi lesz csak a különbség, hogy nem a VPN-es tun/tap eszköz lesz a default route a klienseken, hanem az, ami egyébként be lett nekik állítva akárhogy.
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Esetleg egy aktuális szerver config fájlt mutathatna a kolléga, mert én csak az előzőekben emlegetettekből, meg a mostani log-ból következtettem erre, mivel ebben van egy ilyen sor:

Fri Sep 24 08:39:48 2010 ROUTE default_gateway=10.0.0.2

Tehát vagy a "redirect-gateway" miatt lehet, vagy direktben van egy: push "...", ami a default route-ot piszkálja.
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)


port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
server 10.8.40.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/ipp.txt
push "route 192.168.10.0 255.255.255.0"
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3
mute 20

Köszi!

Átvizslattam pár VPN kliensem logját és van amelyiknél van, van amelyiknél nincsen ROUTE default_gateway=... bejegyzés.
Ahogy elnéztem ezt nem a szerver tekergeti.
Amit a VPN kliens a szerverről kap configurációt, ahhoz képest a lokális default-route megőrzésére ad ki egy parancsot, amint a logja látszik (gondolom). Merthogy direktben senki nem mondja meg nálam se a kliensnek, hogy mi legyen explicite a default route (hanem a VPN csatlakozás előttit felveszi és ezt logolja).

A fentebbi logdarabban az látszik, hogy a kapcsolódó kliensed default gateway-e a 10.0.0.2 IP-jű host.
De ezek szerint ezt nem a szerver tolta le, hanem az OpenVPN kliens szedte fel a masináról és rakta vissza a route config után, hogy megmaradjon a default route.

Érdekes egy menet ... mindenesetre.
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

szerintem igen.

Bár ha biztosra akarsz menni, hogy nem totlod át a klienseid net frgalmát a VPN-en, akkor ellenőrízd le a kliensen egy traceroute-tal, valami publikus webhely felé, pl. index.hu, vagy orido.hu.

Ha nem kúszik át a VPN szerverre, akkor OK.
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

( knzoltan | 2014. 05. 09., p – 20:48 )

Sziasztok,

Elkezdtem egy vpn szervert, de hibára fut a cert generálásoknál:

source vars
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys
root@openvpnserver:/etc/openvpn/easy-rsa#
root@openvpnserver:/etc/openvpn/easy-rsa#
root@openvpnserver:/etc/openvpn/easy-rsa# ./clean-all
root@openvpnserver:/etc/openvpn/easy-rsa# ./build-ca
error on line 198 of /etc/openvpn/easy-rsa/openssl-1.0.0.cnf
3074549436:error:0E065068:configuration file routines:STR_COPY:variable has no value:conf_def.c:618:line 198

Googliztam és ez egy bug. Hagyjam a fenébe az ubuntu 14.04 est és telepítsem egy debian szerverre, vagy van erra valami normális megoldás szerintetek?

-- Zoli ---

Lenovo T400 @ Crunchbang "Waldorf"

Inkább felhúztam virtualboxban egy debian-t, már elegem van a sudo zásból úgyis:-)

De sajnos nem sikerült beüzemelnem. Tudnátok segíteni a hibakeresésben?

openvpn conf fálj:
http://paste.debian.net/98783/

cert mappa tartalma:
http://paste.debian.net/98784/

A syslogba ez kerül:
"server directive network/netmask combination is invalid"

Ha van ötletetek, kérlek segítsetek, köszönöm előre is!!

-- Zoli ---

Lenovo T400 @ Crunchbang "Waldorf"

Köszi, az csak egy próbálkozás volt, nem megy a statikus ip vel sem. Feltöltöttem a mostani konfig fájlt, de így sem megy.
192.168.0.90 es a virtualis gép statikus ip címe, és betettem a teszetlés erejéig a router dmz jébe.

-- Zoli ---

Lenovo T400 @ Crunchbang "Waldorf"

Azt szeretném, hogy a 192.168.0.0/24 es hálózatba "vpn-ezzek" be egy másik laptoppal 4G stick-kel. Ez lenne a végcél.

Most nézem, hogy a openvpnserver.crt fájl mérete 0:-(
http://paste.debian.net/98865/

Szerintem ez is hiba volt, legeneráltam újra a fájlokat az easy-rsa val, bemásoltam a könyvtárba, és sajnos nem működik.

certek:
http://paste.debian.net/98869/

konfig fájl:
http://paste.debian.net/98870/

-- Zoli ---

Lenovo T400 @ Crunchbang "Waldorf"

A server szakaszban hálózatot kell adnod és nem lehet azonos azzal, mit használ valamelyik kártya, de ezt már írtam.

server 192.168.0.90 255.255.255.0 <- itt a 192.168.0.90 nem értemezhető, mert nem hálózati cím.

Helyesen továbbra is így nézne ki:

server 192.168.1.0 netmask 255.255.255.0

( KisSzikra v | 2015. 11. 21., szo – 15:10 )

Hali

A véleményeteket szeretném kérni :)

Szeretnék egy "gyorsabb" OpenVPN hálózatot csinálni.
Jelenleg van egy 512MB rammal ellátott raspberry pi-m, amin egy raspbian fut. Azon fut egy raspbian, és be van állítva Openvpn servernek.
Rá csatlakoznak többen, egy D-LINK NAS és az én gépem.
A problémám hogy akár le, akár feltöltésnél max 5-600kb/s a sávszél
A raspi otthon van egy TP-Link WDR-4300-as router mögött, Inviteles száloptika 30/10-es internet csomaggal.
A gépem meg általában egyetemi hálón, 100/100-as hálózaton.

A kérdésem: ha a raspit leváltanám egy komolyabb vasra, példul egy barebone pc-re (2 magos proci, 2-4gb ram) akkor javulna-e a hálózati sebesség?
Én szerintem azért nem tudok fentebb kerülni a 600kb/s-nél mert a kis raspi nem bírja.

Vagy esetleg még arra gondoltam hogy a wdr-4300-as routert-t beállítani openvpn servernek?

Véleményeket és válaszokat előre is köszönöm!

KisSzikra - TTZ Modding Csoport

kell egy erősebb gép, olyan, amiben a cpu tud aesni utasításokat.
az openvpn-t úgy állítsd, hogy mindenhol használjon aes-t.
nézd meg, hogy a processzor aesni készlete és használt rendszer cryptoengine-je mely aes módokat támogatja hardveresen, és abból válassz!
javaslom a pfsense -t egyébként, és az openvpn valamint az openvpn-clientexport package-k használatát, nálunk nagyon bevált!
ha pfsense-t nem ismered, akkor elmegy vele pár éjszakád mire beletanulsz, mert nagyon részletesen állítható benne minden, de nagyon remek rendszer!

(egy xeon e5-2620 procis vmware host-on fut egyik helyünkön virtuális gépként (1GB RAM-mal), gigabit kapcsolattal s több helyről csatlakozunk hozzá, egyszerre többen: 60mbit bérelt vonal, 40mbit bérelt vonal, 30mbit VDSL vonal, valamint 3 othoni ADSL-es, mindenki full-speed tud egyszerre samba-n másolni le-fel az openvpn kapcsolaton keresztül, prociterhelés is minimális, hála az aesni -nek.)