OpenVPN routeolás

Iroda

Sziasztok!

Van egy problémám, amit nem tudom hogy tudnék megoldani. A probléma, hogy van egy open vpn kapcsolat a linux szerver és a windows kliens között.
A kapcsolat működik, nem is ezzel van a probléma. Hanem hogy a belső hálózatot elveszi az open vpn miután kapcsolódtam. Miután a windows route táblájához hozzáadom az alhálózatot majd törlöm elérhetővé válik az alhálózat és a hálózati nyomtatók is. Ilyet még nem tapasztaltam ovpn-el és nem értem miért csinálja. Valami megoldást tudtok rá?

  • 11799 megtekintés

( 1soproni | 2013. 07. 04., cs – 22:17 )

openvpn config? milyen ip tartományok vannak a két oldalon?

( errotan v | 2013. 07. 04., cs – 22:18 )

log fájlok -> pastebin -> link ide

( rts | 2013. 07. 05., p – 08:16 )

Két probléma okozhat route felhúzási gondokat Vistától fölfelé. Egyik, hogy a gui nem fut megfelelő joggal. A másik, hogy hiányzik ez a két sor a konfigból: route-method exe
route-delay 2

Jeleneleg így néz ki a configom

client

dev tun

ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\molnatesco.crt"
key "C:\\Program Files\\OpenVPN\\config\\molnatesco.key"

resolv-retry infinite

remote *.*.*.*
port 1194
proto udp

verb 3

comp-lzo
ns-cert-type server
persist-key
persist-tun
route-method exe
route-delay 2

A vpn klienst ugyan azzal a profillal telepítettem amiből indítom. UAC pedig nincs XP-n ha jól tudom. A kapcsolatot próbáltam úgy létesíteni hogy kikapcsolt tűzfallal, a probléma akkor is ugyan az volt. Hozzáadtam a kivételekhez szintén ugyan az a probléma. Jelenleg úgy tudom kiküszöbölni, hogy létrehoztam a felhasználónak 2 bat fájlt amit futtatnia kell, hogy ne kelljen neki parancsokat írkálni. Az egyikban routeolom a 192.168.1.0-ás hálózatot majd a másikban törlöm a routeolást és ezután tudom elérni a 192.168.1.0-ás hálózatot.

Ja hogy XP! Ezt eddig eltitkoltad. :) XP-n az a bizonyos plusz két sor sem kell, anélkül is mennie kell. Hirtelen nincs több tippem. Bár nem írtad, de feltételezem, hogy full admin a felhasználód. (XP alatt egyébként sincs sok választék.) Innentől kezdve kismillió oka lehet a problémának és egyik sem valószínű... annyit tudok még hozzátenni, hogy bat fájlokat hozzárendelheted az ifup / ifdown eseményekhez, ha megfelelően elnevezed a bat-okat és berakod a config dirbe, akkor nem kell az usernek ezekkel bajlódnia. Persze ezzel nincs megoldva, de ettől szép a feladat, hajrá hajrá! ;D

( Swifty v | 2013. 07. 05., p – 14:57 )

Log fájl vége felé adja a route parancsok eredeményeit...
Ha valami gáz van, ott megtalálod...
Bemásolnád ide a log végét?
--
Debian Linux rulez... :D

Meg van a log.

Mon Jul 08 14:25:56 2013 OpenVPN 2.3.2 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Jun 3 2013
Mon Jul 08 14:25:56 2013 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon Jul 08 14:25:56 2013 Need hold release from management interface, waiting...
Mon Jul 08 14:25:56 2013 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon Jul 08 14:25:56 2013 MANAGEMENT: CMD 'state on'
Mon Jul 08 14:25:56 2013 MANAGEMENT: CMD 'log all on'
Mon Jul 08 14:25:56 2013 MANAGEMENT: CMD 'hold off'
Mon Jul 08 14:25:56 2013 MANAGEMENT: CMD 'hold release'
Mon Jul 08 14:25:57 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Jul 08 14:25:57 2013 UDPv4 link local (bound): [undef]
Mon Jul 08 14:25:57 2013 UDPv4 link remote: [AF_INET]62.77.201.210:1194
Mon Jul 08 14:25:57 2013 MANAGEMENT: >STATE:1373286357,WAIT,,,
Mon Jul 08 14:25:57 2013 MANAGEMENT: >STATE:1373286357,AUTH,,,
Mon Jul 08 14:25:57 2013 TLS: Initial packet from [AF_INET]62.77.201.210:1194, sid=e1127e44 b641346c
Mon Jul 08 14:25:57 2013 VERIFY OK: depth=1, C=HU, ST=JNSZ, L=Jaszbereny, O=Molnar, CN=server, emailAddress=mkesztyu@invitel.hu
Mon Jul 08 14:25:57 2013 VERIFY OK: nsCertType=SERVER
Mon Jul 08 14:25:57 2013 VERIFY OK: depth=0, C=HU, ST=JNSZ, L=Jaszbereny, O=Molnar, CN=server, emailAddress=mkesztyu@invitel.hu
Mon Jul 08 14:25:57 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jul 08 14:25:57 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jul 08 14:25:57 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jul 08 14:25:57 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jul 08 14:25:57 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Jul 08 14:25:57 2013 [server] Peer Connection Initiated with [AF_INET]62.77.201.210:1194
Mon Jul 08 14:25:58 2013 MANAGEMENT: >STATE:1373286358,GET_CONFIG,,,
Mon Jul 08 14:25:59 2013 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Mon Jul 08 14:25:59 2013 PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.122 10.8.0.121'
Mon Jul 08 14:25:59 2013 OPTIONS IMPORT: timers and/or timeouts modified
Mon Jul 08 14:25:59 2013 OPTIONS IMPORT: --ifconfig/up options modified
Mon Jul 08 14:25:59 2013 OPTIONS IMPORT: route options modified
Mon Jul 08 14:25:59 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Jul 08 14:25:59 2013 MANAGEMENT: >STATE:1373286359,ASSIGN_IP,,10.8.0.122,
Mon Jul 08 14:25:59 2013 open_tun, tt->ipv6=0
Mon Jul 08 14:25:59 2013 TAP-WIN32 device [Helyi kapcsolat 5] opened: \\.\Global\{7DFBBEF0-91EA-4B98-83E3-BCDD3600576F}.tap
Mon Jul 08 14:25:59 2013 TAP-Windows Driver Version 9.9
Mon Jul 08 14:25:59 2013 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.122/255.255.255.252 on interface {7DFBBEF0-91EA-4B98-83E3-BCDD3600576F} [DHCP-serv: 10.8.0.121, lease-time: 31536000]
Mon Jul 08 14:25:59 2013 Successful ARP Flush on interface [3] {7DFBBEF0-91EA-4B98-83E3-BCDD3600576F}
Mon Jul 08 14:26:02 2013 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Mon Jul 08 14:26:02 2013 MANAGEMENT: >STATE:1373286362,ADD_ROUTES,,,
Mon Jul 08 14:26:02 2013 C:\WINDOWS\system32\route.exe ADD 192.168.0.0 MASK 255.255.255.0 10.8.0.121
Mon Jul 08 14:26:02 2013 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Mon Jul 08 14:26:02 2013 C:\WINDOWS\system32\route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.121
Mon Jul 08 14:26:02 2013 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Mon Jul 08 14:26:02 2013 Initialization Sequence Completed
Mon Jul 08 14:26:02 2013 MANAGEMENT: >STATE:1373286362,CONNECTED,SUCCESS,10.8.0.122,62.77.201.210

Bár furcsa, hogy hálózat szakadás után nem a 10.8.0.114-es ip-t kapta amit szokott, hanem a 10.8.0.122-őt

Vannak olyan remkepeim, hogy az XP figyelmen kivul hagyja a netmaszkot, vagyis osztalyokban tud csak gondolkodni(192.168.0.0/16) es azt rutolja.

Azert kivancsi lennek a kovetkezokre:
- kapcsolodas elotti ruting tabla
- kapcsolodas utani ruting tabla
- a korabban elmitett elso bat file tartalmara
- az elso bat file futtatasa utani ruting tablara
- a korabban elmitett masodik bat file tartalmara
- az masodik bat file futtatasa utani ruting tablara

"Az egyikban routeolom a 192.168.1.0-ás hálózatot majd a másikban törlöm a routeolást és ezután tudom elérni a 192.168.1.0-ás hálózatot."
Ezt nem igazan ertem, tehat rutolod, aztan torlod a rutot, es megis elerheto?
Milyen halozatok vannak ott(IP/netmask)?
Ugyanis egy korabbi hozzaszolasban ezt irtad:
"az openvpn ip tartomány 10.8.40.0, az alhálózat pedig 192.168.1.0"
Ehhez kepest a log-ban ez van:
"route 192.168.0.0 255.255.255.0,route 10.8.0.0 255.255.255.0"
Tehat jo lenne, ha a kerdes(ek)re pontosan valaszolnal, ha segitseget szertnel :)

"Bár furcsa, hogy hálózat szakadás után nem a 10.8.0.114-es ip-t kapta amit szokott, hanem a 10.8.0.122-őt"
A doksiban az ipp-t keresd...

( dj | 2013. 07. 05., p – 21:34 )

Csak próba képpen, tiltsd le a windowson a tűzfalat.

tűzfal tiltásokon túl vagyok. Nagyon már nem tudok logfájlokat másolni, mert nem a mi cégünké a gép, hanem egy cégé akivel kapcsolatban állunk. Így jelenleg működik nekik, bár feltételezhetőleg ma telefonálni fognak, mert a felhasználó hibabejelentést írt azért, hogy nem megy a nyomtatás, de lap meg nem volt a nyomtatóban... :)

( iron v | 2013. 07. 08., h – 15:01 )

Tfh: az openvpn mindkettő oldalán ugyanaz a subnet, így mikor csatlakozik VPNre, a windows kliens subnetje át van route-olva a VPN-re. Innentől ugyebár a lokális gépeket nem tudja címezni (OpenVPN Howto is írja)

Nem ehhez kapcsolódik, de nem akarok ezért új témát indítani.

A problémám, hogy van egy openvpn szerver amihez régebben generált kulccsal feltudok lépni gond nélkül, amit viszont a napokban generáltam azokkal egyikkel sem lép fel. A log így néz ki.

Fri Jul 12 10:02:32 2013 OpenVPN 2.2.2 Win32-MSVC++ [SSL] [LZO2] [PKCS11] built on Dec 15 2011
Fri Jul 12 10:02:32 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Jul 12 10:02:32 2013 LZO compression initialized
Fri Jul 12 10:02:32 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Jul 12 10:02:32 2013 Socket Buffers: R=[8192->8192] S=[64512->64512]
Fri Jul 12 10:02:33 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Jul 12 10:02:33 2013 Local Options hash (VER=V4): '41690919'
Fri Jul 12 10:02:33 2013 Expected Remote Options hash (VER=V4): '530fdded'
Fri Jul 12 10:02:33 2013 UDPv4 link local (bound): [undef]:48620
Fri Jul 12 10:02:33 2013 UDPv4 link remote: 91.82.13.13:48620
Fri Jul 12 10:02:33 2013 TLS: Initial packet from 91.82.13.13:48620, sid=b13291b4 f01b4071
Fri Jul 12 10:02:33 2013 VERIFY OK: depth=1, /C=KG/ST=NA/L=BISHKEK/O=OpenVPN-TEST/CN=server/emailAddress=me@myhost.mydomain
Fri Jul 12 10:02:33 2013 VERIFY OK: nsCertType=SERVER
Fri Jul 12 10:02:33 2013 VERIFY OK: depth=0, /C=KG/ST=NA/O=OpenVPN-TEST/CN=server/emailAddress=me@myhost.mydomain
Fri Jul 12 10:03:33 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Jul 12 10:03:33 2013 TLS Error: TLS handshake failed
Fri Jul 12 10:03:33 2013 TCP/UDP: Closing socket
Fri Jul 12 10:03:33 2013 SIGUSR1[soft,tls-error] received, process restarting