PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : OpenVPN-Problem (Inactivity timeout (--ping-restart))



d@tenmaulwurf
29.01.06, 14:28
Morgen!

Ich habe eine OpenVPN-PKI-Lösung gebastelt, die auch in einem großen LAN hervorragend funktioniert.
Die gleiche Config habe ich jetzt genommen, um zwischen einem root-Server und mir verbinden zu können (feste IP).
Hier bekomme ich jetzt jedes Mal in den log (ca alle 5 min) einen Inactivity-Timeout.
Soweit ja irgendwie noch ok (obwohl es so ein Problem innerhalb des LANS mit der selben Config nicht gibt)., aber er macht sofort nach diesem Disconnect wieder einen Reconnect, was mir unlogisch erscheint.
Warum resetted er die Verbindung mit dem Grund sie wird nicht genutzt, um sie gleich wieder aufzubauen ?!

Genaue Fehlermeldung ist (Client-Log):


Sun 01/29/06 02:18 PM: [DOMAIN.de] Inactivity timeout (--ping-restart)
Sun 01/29/06 02:18 PM: TCP/UDP: Closing socket
Sun 01/29/06 02:18 PM: SIGUSR1[soft
Sun 01/29/06 02:18 PM: Re-using SSL/TLS context // hier geht's dann wieder an den reconnect


Clientconfig:


client
dev tun
remote DOMAIN.de // Domain verweist auf eine feste IP - kein DynDNS
tls-client
ca ca.crt
cert 1.crt
key 1.key
proto udp
port 1194
persist-key
persist-tun
user nobody
group nobody // kein nogroup, da *BSD
comp-lzo
verb 3
log openvpn.log
ns-cert-type server


Serevrconfig:


dev tun
server 172.16.0.0 255.255.255.0
tls-server
dh dh4096.pem
ca ca.crt
cert server.crt
key server.key
proto udp
port 1194
persist-key
persist-tun
user nobody
group nogroup
comp-lzo
verb 4
log /var/log/openvpn.log


Und hier nochmal ein Auszug aus der Serverlog, folgender Abschnitt wiederholt sich durch die reconnects immer wieder:


Sun Jan 29 14:22:26 2006 us=469395 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 TLS: new session incoming connection from 85.178.39.216:1194
Sun Jan 29 14:22:32 2006 us=171703 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 VERIFY OK: depth=1, /C=DE/ST=Berlin/L=Berlin/O=DOMAIN_GbR/OU=Internet_Services/CN=DOMAIN.de/emailAddress=service@DOMAIN.de
Sun Jan 29 14:22:32 2006 us=174363 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 VERIFY OK: depth=0, /C=DE/ST=Berlin/O=FIRMA_GbR/OU=OpenVPN/CN=VORNAME_NACHNAME_-_KUNDENNUMMER/emailAddress=EMAIL@DOMAIN2
Sun Jan 29 14:22:32 2006 us=875342 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Jan 29 14:22:32 2006 us=875370 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Jan 29 14:22:32 2006 us=875424 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Jan 29 14:22:32 2006 us=875438 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Jan 29 14:22:32 2006 us=875477 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 TLS: move_session: dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1
Sun Jan 29 14:22:32 2006 us=875662 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 TLS: tls_multi_process: untrusted session promoted to trusted
Sun Jan 29 14:22:32 2006 us=920984 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA
Sun Jan 29 14:22:34 2006 us=86044 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 PUSH: Received control message: 'PUSH_REQUEST'
Sun Jan 29 14:22:34 2006 us=86107 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 SENT CONTROL [VORNAME_NACHNAME_-_KUNDENNUMMER]: 'PUSH_REPLY,route 172.16.0.1,ifconfig 172.16.0.6 172.16.0.5' (status=1)


Ich hoffe ihr könnt mir helfen!

Vielen Dank im voraus,

d@tenmaulwurf

d@tenmaulwurf
31.01.06, 16:21
Ich habe jetzt einfach mal von udp auf TCP umgestellt - gleicher Port - gleiche Config - nur halt das Protkoll auf Server- und Client-Seite verändert. Jetzt bleibt die Verbindung aufrecht.

Ich kann aber nicht TCP nehmen, weil ich TCP Trafic tunneln möchte. Wo zur Hölle liegt genau das Problem ?! :(

geronet
31.01.06, 16:50
Probier doch mal auf beiden Seiten mit den --ping-Optionen ein bisschen rum, eventuell hilft dir der Satz in der man:

In client mode, the --ping-restart parameter is set to 120 seconds by default. This de-
fault will hold until the client pulls a replacement value from the server, based on the
--keepalive setting in the server configuration. To disable the 120 second default, set
--ping-restart 0 on the client.