[MEGOLDVA] OpenVPN nem tudok csatlakozni

Fórumok

Sziasztok!

Van egy debian (4.0) serveren azon egy OpenVPN. Még tavaly év első felében használtam azóta nem.
Persze most kellene.
Azóta annyiban változott a dolog, hogy az internet nem megy közvetlen a szerverre
hanem van előtte egy TP-link TL-R860 router.

XP alól szeretnék csatlakozni, de nem sikerül.

proto tcp:
Wed Jan 13 13:41:12 2010 TCP: connect to xx.xx.xx.xx:183 failed, will try again in 5 seconds: Connection timed out (WSAETIMEDOUT)

proto udp:
TLS Error: TLS key negotiation failed to occur within 60 seconds

telnet xx.xx.xx.xx 183 viszont működik.
A router-en kikapcsoltam a tűzfalat.
A szerveren üres a VPN logja. :(

Van valakinek ötlete, hogy mi lehet a gond?

Hozzászólások

Elfelejtetted bemasolni a konfigot.

client
dev tun
proto tcp
remote xx.xx.xx.xx
port 183
;nobind

persist-key
persist-tun

ca ca.crt
cert home01.crt
key home01.key

ns-cert-type server

comp-lzo
verb 3

--------------------
mosaic:/etc/openvpn# cat server.conf
port 183
proto tcp
dev tun
ca /etc/openvpn/keys/molnarnet/ca.crt
cert /etc/openvpn/keys/molnarnet/server.crt
key /etc/openvpn/keys/molnarnet/server.key # This file should be kept secret
dh /etc/openvpn/keys/molnarnet/dh2048.pem
server 10.8.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option WINS 10.8.0.1"
;ns-cert-type server
keepalive 20 240
comp-lzo
max-clients 3
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
log-append /var/log/openvpn/openvpn-append.log
verb 4
mute 20

Sziasztok!

A routeren a megfelelő port forwardok megvannak?
--
Nem az erős, aki sosem esik el, hanem az, aki mindig fel tud állni!

mosaic:/var/log/openvpn# telnet localhost 183
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

És nem üres a log:
mosaic:/var/log/openvpn# cat openvpn.log
Wed Jan 13 19:15:51 2010 us=675155 MULTI: multi_create_instance called
Wed Jan 13 19:15:51 2010 us=675220 Re-using SSL/TLS context
Wed Jan 13 19:15:51 2010 us=675240 LZO compression initialized
Wed Jan 13 19:15:51 2010 us=675309 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Wed Jan 13 19:15:51 2010 us=675326 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Jan 13 19:15:51 2010 us=675361 Local Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Wed Jan 13 19:15:51 2010 us=675370 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Wed Jan 13 19:15:51 2010 us=675388 Local Options hash (VER=V4): 'c0103fa8'
Wed Jan 13 19:15:51 2010 us=675404 Expected Remote Options hash (VER=V4): '69109d17'
Wed Jan 13 19:15:51 2010 us=675421 TCP connection established with 127.0.0.1:56809
Wed Jan 13 19:15:51 2010 us=675432 Socket Buffers: R=[131072->131072] S=[131072->131072]
Wed Jan 13 19:15:51 2010 us=675443 TCPv4_SERVER link local: [undef]
Wed Jan 13 19:15:51 2010 us=675453 TCPv4_SERVER link remote: 127.0.0.1:56809
Wed Jan 13 19:15:59 2010 us=700412 127.0.0.1:56809 WARNING: Bad encapsulated packet length from peer (65524), which must be > 0 and <= 1544 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attemping restart...]
Wed Jan 13 19:15:59 2010 us=700445 127.0.0.1:56809 Connection reset, restarting [0]
Wed Jan 13 19:15:59 2010 us=700456 127.0.0.1:56809 SIGUSR1[soft,connection-reset] received, client-instance restarting
Wed Jan 13 19:15:59 2010 us=700529 TCP/UDP: Closing socket

Tehát fut a szerver.

Wed Jan 13 19:15:59 2010 us=700412 127.0.0.1:56809 WARNING: Bad encapsulated packet length from peer (65524), which must be > 0 and <= 1544 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attemping restart...]

?

Akkor volt nekem hasonló, mikor más IP-ről jött a válasz, mint ahova ment a kérés (elcseszett NAT).

Én is jártam már így, nem is egyszer. Mindegyik esetben az volt a gond, hogy rossz volt a szerveren a dátum és az idő beállítás. Lehet, hogy bután hangzik, de miután ezt helyreállítottam működött szépen.

mosaic:~# netstat -tpldn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:20000 0.0.0.0:* LISTEN 4592/perl
tcp 0 0 127.0.0.1:2208 0.0.0.0:* LISTEN 2366/hpiod
tcp 0 0 127.0.0.1:10025 0.0.0.0:* LISTEN 4023/perl
tcp 0 0 0.0.0.0:36906 0.0.0.0:* LISTEN 4095/rpc.statd
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 2455/mysqld
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 3958/smbd
tcp 0 0 0.0.0.0:4559 0.0.0.0:* LISTEN 3864/hfaxd
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 2689/cyrmaster
tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTEN 2553/spamd.pid
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 2111/portmap
tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 4602/perl
tcp 0 0 0.0.0.0:113 0.0.0.0:* LISTEN 3886/inetd
tcp 0 0 127.0.0.1:7634 0.0.0.0:* LISTEN 2725/hddtemp
tcp 0 0 92.52.196.252:53 0.0.0.0:* LISTEN 16370/named
tcp 0 0 10.8.0.1:53 0.0.0.0:* LISTEN 16370/named
tcp 0 0 192.168.1.100:53 0.0.0.0:* LISTEN 16370/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 16370/named
tcp 0 0 0.0.0.0:4949 0.0.0.0:* LISTEN 4208/munin-node
tcp 0 0 127.0.0.1:38326 0.0.0.0:* LISTEN 2370/python
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 2663/cupsd
tcp 0 0 0.0.0.0:3128 0.0.0.0:* LISTEN 4126/(squid)
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN 2515/postmaster
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 16370/named
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 3946/master
tcp 0 0 127.0.0.1:2905 0.0.0.0:* LISTEN 2629/bld
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 3958/smbd
tcp6 0 0 :::143 :::* LISTEN 2689/cyrmaster
tcp6 0 0 :::80 :::* LISTEN 10598/apache2
tcp6 0 0 :::22193 :::* LISTEN 4037/sshd
tcp6 0 0 :::631 :::* LISTEN 2663/cupsd
tcp6 0 0 :::5432 :::* LISTEN 2515/postmaster
tcp6 0 0 ::1:953 :::* LISTEN 16370/named
tcp6 0 0 :::25 :::* LISTEN 3946/master

mosaic:/var/log/openvpn# /etc/init.d/openvpn start
Starting virtual private network daemon: server(OK).

mosaic:/var/log/openvpn# cat /var/log/openvpn/openvpn.log
Thu Jan 14 21:12:33 2010 OpenVPN 2.0.9 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Sep 20 2007
Thu Jan 14 21:12:33 2010 Diffie-Hellman initialized with 1024 bit key
Thu Jan 14 21:12:33 2010 WARNING: file '/etc/openvpn/keys/molnarnet/server.key' is group or others accessible
Thu Jan 14 21:12:33 2010 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Jan 14 21:12:33 2010 TUN/TAP device tun0 opened
Thu Jan 14 21:12:33 2010 ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Thu Jan 14 21:12:33 2010 route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Thu Jan 14 21:12:33 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Jan 14 21:12:33 2010 UID set to nobody
Thu Jan 14 21:12:33 2010 UDPv4 link local (bound): [undef]:183
Thu Jan 14 21:12:33 2010 UDPv4 link remote: [undef]
Thu Jan 14 21:12:33 2010 MULTI: multi_init called, r=256 v=256
Thu Jan 14 21:12:33 2010 IFCONFIG POOL: base=10.8.0.4 size=62
Thu Jan 14 21:12:33 2010 Initialization Sequence Completed

Ezek után próbálok csatlakozni és ez a kliens log:

Thu Jan 14 21:14:50 2010 OpenVPN 2.1.1 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Dec 11 2009
Thu Jan 14 21:14:50 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Jan 14 21:14:50 2010 LZO compression initialized
Thu Jan 14 21:14:50 2010 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Jan 14 21:14:50 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Jan 14 21:14:50 2010 Local Options hash (VER=V4): '41690919'
Thu Jan 14 21:14:50 2010 Expected Remote Options hash (VER=V4): '530fdded'
Thu Jan 14 21:14:50 2010 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Jan 14 21:14:50 2010 UDPv4 link local (bound): [undef]:183
Thu Jan 14 21:14:50 2010 UDPv4 link remote: 92.52.196.252:183
Thu Jan 14 21:15:50 2010 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Jan 14 21:15:50 2010 TLS Error: TLS handshake failed
Thu Jan 14 21:15:50 2010 TCP/UDP: Closing socket
Thu Jan 14 21:15:50 2010 SIGUSR1[soft,tls-error] received, process restarting
Thu Jan 14 21:15:50 2010 Restart pause, 2 second(s)
Thu Jan 14 21:15:52 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Jan 14 21:15:52 2010 Re-using SSL/TLS context
Thu Jan 14 21:15:52 2010 LZO compression initialized
Thu Jan 14 21:15:52 2010 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Jan 14 21:15:52 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Jan 14 21:15:52 2010 Local Options hash (VER=V4): '41690919'
Thu Jan 14 21:15:52 2010 Expected Remote Options hash (VER=V4): '530fdded'
Thu Jan 14 21:15:52 2010 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Jan 14 21:15:52 2010 UDPv4 link local (bound): [undef]:183
Thu Jan 14 21:15:52 2010 UDPv4 link remote: xx.xx.xx.xx:183

A szerver log pedig bejegyzés mentes. :(

Kezdek megőrülni :(
Újra konfiguráltam mindent és a helyzet továbbra sem javul. :(( áá

Digi halozatbol probaltam vpn-ezni ceges halora, nem ment, megallt timeouttal, regebben meg mukodott, annyi valtozas volt, hogy chellorol digi-re valtottam.
Ott ilyen ppoe-s szaron keresztul lehet kapcsolodni, es a router-em beallitasai kozott engedelyezni kellett a vpn over ppoe-t, vagy vmi ilyesmit.
ha mashonnan elered, otthonrol meg nem, es routeren keresztul mesz ki a netre, akkor nezz korul a beallitasok kozott.

Tyrael

Bocs, ha esetleg hülye a kérdés, de OpenVPN esetén miért is érzékeny a router a VPN-re? Az TCP és UDP felett üzemel, szállítási rétegben. Ha IPSec vagy pptp lenne, úgy érteném.

--------------------
Tegnap beállított hozzám egy Tyrannosaurus Rex és Hamlet. Volt nagy dinóm-dánom...

már EMKTV idejében is nálunk voltam, de soha semmi bajom nem volt az OpenVPN használatával, ráadásul egyszerre több VPN-re is csatlakozok, sza nem a Digi az oka, igaz, a default UDP helyett TCP-t használok

így azt is meg tudom tenni, hogy VPN hálózaton belül SSH-val belépek a szerverre dolgozni, lehajtom a laptopot, hazajövök (kb 1 óra), laptop felnyit, kapásból visszacsatlakozik a VPN-re és használható tovább az SSH kapcsolat, nem szakad meg :)

Szóval megoldódott a dolog.

1. Volt a tűzfalban egy beállítás ami blokkolta a szerveren.
2. Az XP-n nem volt elég a Comodo-t kikapcsolni. Mérgemben töröltem és azóta működik :)

float sem kell ;)