Szenario:
Niederlassung A:
Gateway (10.23.100.2) läuft als VM (KVM) und besitzt je eine dedizierte NIC (direkt exklusiv an diese VM verbunden) für die 10Mbit Standleitung und fürs LAN.
DMZ ist über eine virtuelle Schnittstelle angebunden.
Firewalling wird per Shorewall konfiguriert - aktuelle policy für den testbetrieb: loc<->vpn ACCEPT ALL
device für vpn = tun0
Läuft als default GW für die clients in diesem Netz
Niederlassung B:
Gateway (10.18.100.2) auch hier als VM, allerdings keine Direktanbindung ans WAN, da die Standleitung hier aktuell an einem extern verwalteten VPN-Router (10.18.100.1) hängt (der nach erfolgreichem Testbetrieb in eine separate Zone ausgegliedert werden soll und nur noch die langsame "normale" DSL-Leitung bekommt - darüber läuft dann nur noch der traffic von einer einzigen Anwendung bzw VM...). Der Gateway hängt also aktuell direkt im LAN und ist nur route ins andere Netz, nicht default GW.
Auch hier: vpn<->loc ACCEPT ALL und tun0 = zone vpn
Gateway A läuft als OpenVPN server, B als client
OpenVPN conf-Dateien:
Gateway A:
Code: Alles auswählen
tls-server
port 1194
proto udp
dev tun0
float
ifconfig 10.10.10.1 10.10.10.2
push "route 10.23.100.0 255.255.255.0"
pull
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/r-gateway.crt
key /etc/openvpn/easy-rsa/keys/r-gateway.key
keepalive 2 120000
comp-lzo # kompression
persist-key
persist-tun
persist-local-ip
status /var/log/openvpn.log
reneg-sec 60
verb 1
Code: Alles auswählen
client
dev tun0
port 1194
proto udp
float
remote <ext. IP GW A>:1194
ifconfig 10.10.10.2 10.10.10.1
push "route 10.18.100.0 255.255.255.0"
pull
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/a-gateway.crt
key /etc/openvpn/easy-rsa/keys/a-gateway.key
daemon
comp-lzo
persist-key
persist-tun
persist-local-ip
persist-remote-ip
reneg-sec 60
verb 1
Die Verbindung wird sauber aufgebaut, routen werden von beiden Seiten übernommen.
Zwischen den Gateways kann ich beliebig pingen, ssh vebrindungen aufbauen, Dateien verschieben usw...
Von Client zu Client kann ebenfalls gepingt werden, traceroutes zeigen an dass in beide Richtungen alles sauber über die gateways läuft. Versuche ich aber z.b. eine SSH-Verbindung zwischen 2 Clients durch den Tunnel aufzubauen, ist die Verbindung sofort tot und wird auch nicht wieder automatisch hergestellt. Manchmal hilft es, vom Gateway B den gateway A anzupingen, dann wird nach ~20-30 sek die Verbindung neu aufgebaut - funktioniert aber auch nur sporadisch. Wirklich sicher ist nur ein neustart von openvpn.
Frustrierend daran ist, dass 2 Wochen alles einwandfrei funktionierte bis der Node von A für ein Kernelupdate neu gestartet wurde.
Hatte dabei aber vorher die routingtabellen und die Ausgabe von ifconfig am Node und an der Gateway-VM gedumpt und nach dem Neustart verglichen (da ich nicht sicher war ob ich hier noch flüchtige Einträge vorgenommen hatte) - es fehlte aber nichts...
Kurzer Test mit ping vom Node auf den entfernten gateway lief durch, also hatte ich es als funktionierend abgehakt - der "Fehler" wurde dann erst am nächsten Morgen entdeckt als die Clients aus Netz B auf den Server in A zugreifen wollten...
In der syslog des Gateway B tauchen einige Zeit nach jedem Verbindungsabbruch folgende Fehler auf:
Code: Alles auswählen
Aug 9 13:38:12 hostname openvpn[8257]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Aug 9 13:38:12 hostname openvpn[8257]: TLS Error: TLS handshake failed
Alle 4 relevanten punkte würden aber bedeuten, dass die Verbindung überhaupt nicht funktioniert - tut sie ja aber beliebig lange. Erst wenn clients versuchen miteinander zu Kommunizieren bricht sie ab...
Ich vermute eher, dass diese Fehler WEGEN des Verbindungsabbruchs generiert werden, nicht URSACHE für den disconnect sind.
Zumal die tun-devices und Routingeinträge (die per push/pull erzeugt werden) auf beiden Seiten erhalten bleiben - die beiden Gateways erkennen also anscheinend nichtmal dass die Verbindung tot ist.
Bin mit meinem (begrenzten) wissen zu openvpn ziemlich am ende, auch manpages und google haben mich die letzten Stunden nicht weiter gebracht - Problem bleibt weiterhin bestehen.... Wäre für jeden Hinweis dankbar - werde sonst einfach mal auf beiden Seiten eine frische VM einsetzen und nochmal von 0 konfigurieren - wenns dann wieder nicht läuft fress ich glaub meinen Schreibtisch
