Dotaz: OpenVPN a GPRS

[Zdeněk Zámečník]

Už druhým dnem bojuji se zprovozněním OpenVPN přes GPRS/EDGE T-mobilu. Připravil jsem si konfiguraci, která mi mezi serverem (Debian Etch) a PocketPC s (Windows Mobile 6.1) s wifi jede bez problému. Jakmile se pokusím připojit přes GPRS nebo EDGE, spojení se jakoby naváže (logy na serveru jsou ok, na pPC je ikonka OpenVPN zelená), ale stroje na sebe nemohou ani pingnout natož nějak dále komunikovat. Zkoušel jsem různé porty a vypnout šífrování, ale neúspěšně V logu pPC se poté nachází toto:

Sat Aug 09 12:04:19 2008 OpenVPN 2.1_rc8 Win32-MSVC++ [SSL] [LZO2] built on Jun 28 2008
Sat Aug 09 12:04:19 2008 MANAGEMENT: TCP Socket listening on 127.0.0.1:10000
Sat Aug 09 12:04:20 2008 Need hold release from management interface, waiting...
Sat Aug 09 12:04:20 2008 MANAGEMENT: Client connected from 127.0.0.1:10000
Sat Aug 09 12:04:20 2008 Using Windows Connection Manager with destination 'auto' resolving to provider guid {436EF144-B4FB-4863-A041-8F905A62C572} (exclusive)
Sat Aug 09 12:04:25 2008 Acquisition of Windows Connection Manager provider succeeded...
Sat Aug 09 12:04:25 2008 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sat Aug 09 12:04:25 2008 LZO compression initialized
Sat Aug 09 12:04:25 2008 Control Channel MTU parms [ L:1576 D:140 EF:40 EB:0 ET:0 EL:0 ]
Sat Aug 09 12:04:25 2008 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
Sat Aug 09 12:04:25 2008 Local Options hash (VER=V4): '31fdf004'
Sat Aug 09 12:04:25 2008 Expected Remote Options hash (VER=V4): '3e6d1056'
Sat Aug 09 12:04:25 2008 Attempting to establish TCP connection with 77.77.77.77:80
Sat Aug 09 12:04:25 2008 MANAGEMENT: >STATE:1218276265,TCP_CONNECT,,,
Sat Aug 09 12:04:26 2008 TCP connection established with 77.77.77.77:80
Sat Aug 09 12:04:26 2008 Socket Buffers: R=[32768->32768] S=[16384->16384]
Sat Aug 09 12:04:26 2008 TCPv4_CLIENT link local (bound): [undef]
Sat Aug 09 12:04:26 2008 TCPv4_CLIENT link remote: 77.77.77.77:80
Sat Aug 09 12:04:26 2008 MANAGEMENT: >STATE:1218276266,WAIT,,,
Sat Aug 09 12:04:27 2008 MANAGEMENT: >STATE:1218276267,AUTH,,,
Sat Aug 09 12:04:27 2008 TLS: Initial packet from 77.77.77.77:80, sid=8b99e5c6 1fad8026
Sat Aug 09 12:04:41 2008 VERIFY OK: depth=1, /C=CZ/ST=Czech_republic/L=Prague/O=Diego191/CN=mail.revomail.cz/emailAddress=developer@way2net.cz
Sat Aug 09 12:04:41 2008 VERIFY OK: depth=0, /C=CZ/ST=Czech_republic/O=Diego191/CN=mail.revomail.cz/emailAddress=developer@way2net.cz
Sat Aug 09 12:05:00 2008 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Aug 09 12:05:00 2008 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Aug 09 12:05:00 2008 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Aug 09 12:05:00 2008 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Aug 09 12:05:01 2008 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 384 bit RSA
Sat Aug 09 12:05:01 2008 [mail.revomail.cz] Peer Connection Initiated with 77.77.77.77:80
Sat Aug 09 12:05:02 2008 MANAGEMENT: >STATE:1218276302,GET_CONFIG,,,
Sat Aug 09 12:05:02 2008 SENT CONTROL [mail.revomail.cz]: 'PUSH_REQUEST' (status=1)
Sat Aug 09 12:05:04 2008 PUSH: Received control message: 'PUSH_REPLY,route 10.10.10.0 255.255.255.0,dhcp-option DNS 4.2.2.5,redirect-gateway,route-gateway 10.10.10.1,ping 10,ping-restart 120,ifconfig 10.10.10.2 255.255.255.0'
Sat Aug 09 12:05:04 2008 OPTIONS IMPORT: timers and/or timeouts modified
Sat Aug 09 12:05:04 2008 OPTIONS IMPORT: --ifconfig/up options modified
Sat Aug 09 12:05:04 2008 OPTIONS IMPORT: route options modified
Sat Aug 09 12:05:04 2008 OPTIONS IMPORT: route-related options modified
Sat Aug 09 12:05:04 2008 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Aug 09 12:05:04 2008 MANAGEMENT: >STATE:1218276304,ASSIGN_IP,,10.10.10.2,
Sat Aug 09 12:05:04 2008 TAP-WIN32 device [TAP1:] opened: TAP1:
Sat Aug 09 12:05:04 2008 TAP-Win32 Driver Version 9.4 
Sat Aug 09 12:05:04 2008 TAP-Win32 MTU=1500
Sat Aug 09 12:05:04 2008 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.10.10.2/255.255.255.0 on interface TAP1: [DHCP-serv: 10.10.10.0, lease-time: 31536000]
Sat Aug 09 12:05:04 2008 Successful ARP Flush on interface [4] TAP DEVICE 1
Sat Aug 09 12:05:09 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Sat Aug 09 12:05:09 2008 Route: Waiting for TUN/TAP interface to come up...
Sat Aug 09 12:05:14 2008 TEST ROUTES: 2/2 succeeded len=1 ret=1 a=0 u/d=up
Sat Aug 09 12:05:14 2008 route ADD 77.77.77.77 MASK 255.255.255.255 172.24.170.205
Sat Aug 09 12:05:14 2008 ROUTE: route addition failed using CreateIpForwardEntry: The parameter is incorrect.   [status=87 if_index=589827]
Sat Aug 09 12:05:14 2008 Route addition via IPAPI failed [adaptive]
Sat Aug 09 12:05:14 2008 Route addition fallback to route.exe
Sat Aug 09 12:05:14 2008 route DELETE 0.0.0.0 MASK 0.0.0.0 172.24.170.205
Sat Aug 09 12:05:14 2008 Route deletion via IPAPI succeeded [adaptive]
Sat Aug 09 12:05:14 2008 route ADD 0.0.0.0 MASK 0.0.0.0 10.10.10.1
Sat Aug 09 12:05:14 2008 Route addition via IPAPI succeeded [adaptive]
Sat Aug 09 12:05:14 2008 MANAGEMENT: >STATE:1218276314,ADD_ROUTES,,,
Sat Aug 09 12:05:14 2008 route ADD 10.10.10.0 MASK 255.255.255.0 10.10.10.1
Sat Aug 09 12:05:14 2008 Route addition via IPAPI succeeded [adaptive]
Sat Aug 09 12:05:14 2008 Initialization Sequence Completed
Sat Aug 09 12:05:14 2008 MANAGEMENT: >STATE:1218276314,CONNECTED,SUCCESS,10.10.10.2,77.77.77.77
Sat Aug 09 12:05:38 2008 TCP/UDP: Closing socket
Sat Aug 09 12:05:38 2008 route DELETE 10.10.10.0 MASK 255.255.255.0 10.10.10.1
Sat Aug 09 12:05:38 2008 Route deletion via IPAPI succeeded [adaptive]
Sat Aug 09 12:05:38 2008 route DELETE 77.77.77.77 MASK 255.255.255.255 172.24.170.205
Sat Aug 09 12:05:38 2008 ROUTE: route deletion failed using DeleteIpForwardEntry: The parameter is incorrect.  
Sat Aug 09 12:05:38 2008 Route deletion via IPAPI failed [adaptive]
Sat Aug 09 12:05:38 2008 Route deletion fallback to route.exe
Sat Aug 09 12:05:38 2008 route DELETE 0.0.0.0 MASK 0.0.0.0 10.10.10.1
Sat Aug 09 12:05:38 2008 Route deletion via IPAPI succeeded [adaptive]
Sat Aug 09 12:05:38 2008 route ADD 0.0.0.0 MASK 0.0.0.0 172.24.170.205
Sat Aug 09 12:05:38 2008 ROUTE: route addition failed using CreateIpForwardEntry: The parameter is incorrect.   [status=87 if_index=589827]
Sat Aug 09 12:05:38 2008 Route addition via IPAPI failed [adaptive]
Sat Aug 09 12:05:38 2008 Route addition fallback to route.exe
Sat Aug 09 12:05:38 2008 Closing TUN/TAP interface
Sat Aug 09 12:05:38 2008 SIGTERM[hard,] received, process exiting
Sat Aug 09 12:05:38 2008 MANAGEMENT: >STATE:1218276338,EXITING,SIGTERM,,
Sat Aug 09 12:05:38 2008 Releasing Windows Connection Manager provider

Pro jistotu přikládám konfiguraci klienta:

remote 77.77.77.77
port 80
tls-client
proto tcp-client
dev tap
route-delay 5
pull
comp-lzo
verb 3
ca \\ca.crt
cert \\client1.crt
key \\client1.key
comp-lzo
persist-tun
persist-key
verb 3
resolv-retry infinite

77.77.77.77 je veř. adresa serveru 10.10.10.1 je vnitřní adresa serveru 10.10.10.2 je vnitřní adresa klienta kde se tam pořád bere ta další IP vůbec netuším

Díky za jakékoliv popostrčení

Odpovědi

[Zdeněk Zámečník]

Tak jsem o něco pokročil. Na serveru jsem zakomentoval routování, viz níže:

mode server
tls-server
port 80
proto tcp-server
dev tap
server 10.10.10.0 255.255.255.0
push "route 10.10.10.0 255.255.255.0"
push "dhcp-option DNS 4.2.2.5"

#push "redirect-gateway"
#route-gateway 10.10.10.1

dh dh384.pem
ca ca.crt
cert server.crt
key server.key
persist-tun
persist-key
keepalive 10 120
comp-lzo
verb 3

A už na sebe vidí. Teď ještě vymyslet, jak nastavit, aby to dokázalo routovat veškerý provoz na 10.10.10.1. Netušíte vlastně někdo, proč toto nastavení na jakémkoliv "normálním" připojení běhá, ale na GPRS/EDGE ne?

[billgates]

Ja by som to videl skor v nestabilite pripojenia. Autori odporucaju pouzivat UDP pri tychto pripojeniach.

Este taka vec, nepouziva to GPRS/EDGE pripojenie prave adresy 10.10.10.0/24? (netusim, len sa pytam)

[Zdeněk Zámečník]

Nestabilitou by to být nemělo, když to vyloženě křičí, že tam jsou chybné parametry. Nevím jak u TM, ale u Vodafone a O2 se používá 10.0.0.0/24, ale to by stejně nemělo mít vliv, jelikož to jsou vnitřní adresy. Ano, UDP by bylo rozhodně lepší, ale já to nutně potřebuji přes TCP

[lukash]

Zdravim, myslim, ze jediny problem, ktery ted uz existuje je prave routovani, kvuli tomu ze ISP pouziva stejny ip rozsah, staci navazat spojeni pres to openvpn a routovani dat klidne dokopy pres route (ci uz v linuxu nebo windowsu), pripadne nastavit ve vpnce uplne jiny rozsah nez ma ISP pro zjednoduseni routovani.

[rsaf]

Ja jsem narazil na podobny problem (stejne projevy akorat linka nebyla GPRS) a problem byl v tom, ze OpenVPN pridalo do routovacich tabulek takovy zaznam (nejakou cestu do nasi site) ktera "sezrala" cestu skrz internet k VPN serveru - spojeni se korektne navaze, po jeho nabehnuti se pridaji u klienta routy a ty nasmerujou provoz OpenVPN do VPNky - VPN tak "sama sebe sezere"