VPN und Zwangstrennung Provider

[grosser]

Hallo Leute,

ich bin komplett neu hier, und habe mit einen VPN Server auf meinem Debian Jessie aufgebaut.
Zu Testzwecken habe ich einen Client eingerichtet der ständig mit dem Server verbunden ist. Leider ist nach Zwangstrennung der ganze Spaß dann vorbei und der Client verbindet sich nicht mehr mit dem Server.
Nur nach einem vollständigen Neustart des Clients verbindet sich dieser wieder mit dem Server.

Hier mal die Configs:

Server

Code: Alles auswählen

dev tun
proto udp
port 4624
ca /etc/openvpn/easy-rsa2/keys/ca.crt
cert /etc/openvpn/easy-rsa2/keys/server.crt
key /etc/openvpn/easy-rsa2/keys/server.key
dh /etc/openvpn/easy-rsa2/keys/dh2048.pem
user nobody
group nogroup
server 10.8.0.0 255.255.255.0
persist-key
persist-tun
status /mnt/Log/vpn/openvpn-status.log
verb 3
client-to-client
push "redirect-gateway def1 bypass-dhcp"
#set the dns servers
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
log-append /var/log/openvpn
comp-lzo
duplicate-cn
keepalive 10 120

Client

Code: Alles auswählen

dev tun
client
proto udp
remote xxxxxxxxxxxxxxxxxxxx 4624
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
comp-lzo
verb 3

Der Provider ist die Telekom und ich habe ein dyndns eingerichtet und auch in der Fritz!Box hinterlegt.

Habe ich eventuell etwas vergessen?

[tuxedo]

Hallo

connect-retry xx
connect-retry-max xx

Setzten beim Client dürfte helfen.

Grüsse

[mistersixt]

Willkommen im DebianForum!

Hast deine OpenVPN-Verbindung auch beim systemd "angemeldet" mit "systemctl enable openvpn@client.service" und die Verbindung darüber gestartet mit "systemctl start openvpn@client.service"? Bei mir überlebt das OpenVPN die Zwangstrennung bei Jessie, auch ohne "connect-try".

Gruss, mistersixt.

[mat6937]

connect-retry xx
connect-retry-max xx

Setzten beim Client dürfte helfen.

BTW: Der TE nutzt ja (m. E. richtigerweise) "proto udp" und "connect-retry" sollte ja nur mit dem "proto tcp-client" genutzt (d. h. evtl. geändert) werden. Auch wenn man diese Optionen nicht in der config des Clienten hat, "greifen" die default-Werte (z. B. 5 Sekunden und infinite).

EDIT:

Nur nach einem vollständigen Neustart des Clients verbindet sich dieser wieder mit dem Server.

Was genau meinst Du mit "vollständigem Neustart"?

Eigentlich wäre es ausreichend, wenn nur der VPN-Client neu gestartet wird? Das kannst Du auch provozieren, in dem Du vom VPN-Client aus, versuchst (... etwas nach der Zwangstrennung durch den Provider) eine TCP-Verbindung durch den Tunnel zum VPN-Server (... wenn auf dem VPN-Server an einem TCP-Port gelauscht wird) herzustellen (... dann restartet der VPN-Client). Evtl. auch mit einem job in der crontab von root auf dem Client, möglich. Z. B. (alle 5 Minuten ein tcp-syn-Flag):

Code: Alles auswählen

*/5 *	* * * /usr/bin/nping -c 1 --quiet --tcp --ttl 20 --data-length 10 --df --flags syn -g 3333 -p <lauschender-TCP-Port-Server> <IP-Adresse-tun0-Interface-Server> > /dev/null 2>&1

(oder gleichwertig).

[grosser]

Mit einem Neustart des VPN Dienstes auf dem Client ist meiner Meinung nach nicht getan.

Ich werde das aber noch mal probieren.

Der VPN Dienst läuft auf einem Receiver und da ist Autostart etc eingestellt.

[mat6937]

Mit einem Neustart des VPN Dienstes auf dem Client ist meiner Meinung nach nicht getan.

Bei meinem VPN-Client funktioniert das. Z. B. den VPN-Client um 08:28:04 Uhr gestartet, den VPN-Server um 09:16:30 Uhr rebootet. Alle 5 Minuten einen tcp-Ping (um 09:15:00 Uhr und um 09:20:00 Uhr). der tcp-Ping um 09:20:00 Uhr hat zum Neustart des VPN-Clienten geführt bzw. hat die VPN-Verbindung (zwischen Client und Server) wieder verwendbar gemacht:

VPN-Server:

Code: Alles auswählen

shutdown -r now
Broadcast message from root@xxxxxx (pts/1) (Wed Feb  3 09:16:30 2016):
The system is going down for reboot NOW!

VPN-Client (Log):

Code: Alles auswählen

Feb  3 08:28:04 YYYYYY daemon.warn ovpn-client[1542]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

Feb  3 09:20:23 YYYYYY daemon.warn ovpn-client[1550]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

[grosser]

Nicht ganz so schnell bitte, bin noch Neuling auf dem Gebiet.

Also grundsätzlich sind die Configs vom Server erstmal i.O., richtig?

Am Client müssten eventuell Anpassungen vorgenommen werden, richtig?

[mat6937]

Am Client müssten eventuell Anpassungen vorgenommen werden, richtig?

Ja, wobei meine Lösung/Anpassung nichts (direkt) mit der Konfiguration des VPN-Clienten zu tun hat, sondern lediglich aus einem geeigneten cronjob besteht, der alle 5 Minuten einen tcp-syn-flag-Ping durch den VPN-Tunnel zu einem entsprechend (d. h. auch auf tunx) lauschenden TCP-Port des VPN-Server, macht.

Dieser Ping hat zur Folge, dass der VPN-Client neu gestartet wird (siehe die PID des VPN-Clienten vorher und nachher) und die Verbindung zwischen VPN-Server und VPN-Client wieder brauchbar ist. Ohne diesen Neustart des VPN-Clienten, funktioniert nach einem Neustart (oder ähnlich) des VPN-Servers, hier die VPN-Verbindung auch nicht mehr. Evtl. ist das auch OK so bzw. ein beabsichtigtes "Sicherheits-Merkmal" des VPN-Clienten/-Server.

[grosser]

Also der VPN Server steht bei mir hier und läuft ja auf dem Debian Jessie, Zertifikat etc. damit erstellt.

Nach einem gesteuertem Unterbrechung der Internetverbindung war der Client wieder weg,

[mat6937]

Nach einem gesteuertem Unterbrechung der Internetverbindung war der Client wieder weg,

Hast Du die Internetverbindung des VPN-Servers oder die des VPN-Clienten unterbrochen?

Wenn die des VPN-Servers, dann ist das m. E. gleichwertig mit meinem Test (d. h. reboot beim Server).

[MSfree]

Also der VPN Server steht bei mir hier und läuft ja auf dem Debian Jessie, Zertifikat etc. damit erstellt.

Nach einem gesteuertem Unterbrechung der Internetverbindung war der Client wieder weg,

Ich denke, du solltest keepalive nicht nur in der Server-Konfiguration sondern auch in der Client-Konfiguration setzen.

Ausserdem wäre eventuell resolv-retry infinite in der Client-Konfiguration hilfreich. Wenn nämlich die Serverseite zwangsunterbrochen wird, bekommt der eine neue IP-Adresse, die der Client bei erneutem Verbindungsversuch auch erneut beim DNS abfragen muß. Läßt du die Option weg, wird nur beim ersten Start des Client die Serverseite per DNS-Lookup aufgelöst.

[mat6937]

Ausserdem wäre eventuell resolv-retry infinite in der Client-Konfiguration hilfreich. Wenn nämlich die Serverseite zwangsunterbrochen wird, bekommt der eine neue IP-Adresse, die der Client bei erneutem Verbindungsversuch auch erneut beim DNS abfragen muß. Läßt du die Option weg, wird nur beim ersten Start des Client die Serverseite per DNS-Lookup aufgelöst.

BTW: Mein VPN-Server hat eine statische/feste öffentliche IPv4-Adresse (d. h. es muss keine Namensauflösung gemacht werden).

EDIT:

Lt. manpage ist es per default schon so:

By default, --resolv-retry infinite is enabled.

[grosser]

Die Internetverbindung vom Server wurder getrennt.

Folgende Einstellungen sind im Client vorgenommen

Code: Alles auswählen

dev tun
client
proto udp
remote xxxxxxxxxxxxxxxx.xx 4624
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
comp-lzo
verb 3
keepalive 10 120

Okay, und das bedeutet für mich was? Sorry das ich so blöd Frage

[mat6937]

Die Internetverbindung vom Server wurder getrennt

OK, also gleichwertig. Versuch mal mit einem reboot/Neustart des VPN-Clienten und wenn das funktioniert, dann mit einem cronjob auf dem VPN-Client.

[grosser]

OK, also gleichwertig. Versuch mal mit einem reboot/Neustart des VPN-Clienten und wenn das funktioniert, dann mit einem cronjob auf dem VPN-Client.

Genau das hab ich bereits probiert, sobald der Client einen reboot/Neustart durchführt wird die Verbindung wieder aufgebaut.

Zu dem Cronjob, da muss ich erstmal schauen wie ich das auf dem Client umsetzen kann. Wie gesagt, das ist ein Receiver der mit einem openvpn Plugin ausgestattet ist.

[mat6937]

... der Client einen reboot/Neustart durchführt wird die Verbindung wieder aufgebaut.

Hier solltest Du aber unterscheiden, zwischen Client als Gerät/Receiver und Client als VPN-Client (Programm).

[MSfree]

Die Internetverbindung vom Server wurder getrennt

OK, also gleichwertig. Versuch mal mit einem reboot/Neustart des VPN-Clienten und wenn das funktioniert, dann mit einem cronjob auf dem VPN-Client.

Vielleicht hilft es auch, in die [service]-Abteilung von /lib/systemd/system/openvpn@.service
Restart=always
einzufügen.

Danach mußt du noch den openvpn Service mit systemctl neu laden bzw. rebooten.

[mat6937]

Vielleicht hilft es auch, in die [service]-Abteilung von /lib/systemd/system/openvpn@.service
Restart=always
einzufügen.

Nein, das würde nur dann helfen wenn der VPN-Client die Netzwerkverbindung verliert, was aber nicht der Fall ist.

Das mit dem cronjob (oder gleichwertig) ist ja auch nur ein workaround und simuliert die Nutzung der VPN-Clienten. Man könnte genau so gut den VPN-Tunnel richtig/sinnvoll nutzen, dann kommt die Verbindung (durch ein reboot des VPN-Clienten) auch zustande bzw. kann genutzt werden.

Das Problem hier ist, dass man sich z. B. vom VPN-Server oder aus seinem (W)LAN durch den Tunnel zum VPN-Client oder in sein (W)LAN verbinden will, und das geht nicht weil das den VPN-Client nicht zu einem reboot bewegt/veranlasst.

[MSfree]

Nein, das würde nur dann helfen wenn der VPN-Client die Netzwerkverbindung verliert, was aber nicht der Fall ist.

Restart=always bewirkt, soweit ich das verstanden habe, daß der Service neu gestartet wird, sobald er sich per exit oder Absturz beendet hat.

Das mit dem cronjob (oder gleichwertig)

Warum willst du den Service per Cron überwachen und ggfls. starten, wenn systemd die Beendigung des Dienstes sowieso als erster erfährt? Nur, daß der systemd den dann auch sofort neu starten könnte.

[mat6937]

Nein, das würde nur dann helfen wenn der VPN-Client die Netzwerkverbindung verliert, was aber nicht der Fall ist.

Restart=always bewirkt, soweit ich das verstanden habe, daß der Service neu gestartet wird, sobald er sich per exit oder Absturz beendet hat.

Und genau das ist hier nicht der Fall. Der VPN-Client ist nicht abgestürzt und hat sich auch nicht beendet (nur weil der VPN-Server rebootet). Er lauscht schön brav an seinem UDP-Port.

Das mit dem cronjob (oder gleichwertig)

Warum willst du den Service per Cron überwachen und ggfls. starten, wenn systemd die Beendigung des Dienstes sowieso als erster erfährt? Nur, daß der systemd den dann auch sofort neu starten könnte.

systemd kann nichts erfahren, weil der Dienst nicht beendet wird (siehe oben).

EDIT:

Nicht cron startet den VPN-Client. Das mach der VPN-Client von sich aus, wenn durch den Tunnel eine TCP-Verbindung (hier nur als tcp-ping) hergestellt werden soll.

[grosser]

Also nach meinen bisherigen Test scheint am Server alles soweit zu funktionieren.
Auch nach einem Server Neustart wird ja der Dienst ordnungsgemäß gestartet.

EDIT:
Hab jetzt nochmal den Server neu gestartet, ohne die Inetverbindung zu trennen. Der Client verbindet sich jetzt automatisch.
Nun könnte ich es noch mal mit einer gesteuerten Trennung der Internetverbindung versuchen.

Wobei ich ja jetzt davon ausgehe das mit dem Reboot des Servers keine neue IP vom Provider gekommen ist.

[mat6937]

Auch nach einem Server Neustart wird ja der Dienst ordnungsgemäß gestartet.

Mit "der Dienst" meinst Du den VPN-Clienten? Hast Du dein Problem reproduzieren können und feststellen können, ob ein reboot des VPN-Clienten (nicht das Gerät rebooten) hilft?

[grosser]

Also folgendes:

Der VPN Dienst auf dem Server wird nach einem Neustart des gesamten Servers ordnungsgemäß gestartet und ausgeführt.

Der VPN Dienst auf dem Client wird nach einem Neustart des Clients ebenfalls ordnungsgemäß gestartet und ausgeführt.

Das Problem ist einfach sobald der Server durch die Zwangstrennung vom Provider eine neue IP bekommt, dann kommt der Client nicht mehr klar damit und verbindet sich nur
nach einem Neustart wieder mit dem Server.

Es ist eine dyndns auf der Fritzbox eingerichtet, die ebenfalls ordnungsgemäß funktioniert.

[mat6937]

Das Problem ist einfach sobald der Server durch die Zwangstrennung vom Provider eine neue IP bekommt, dann kommt der Client nicht mehr klar damit und verbindet sich nur
nach einem Neustart wieder mit dem Server.

Es ist eine dyndns auf der Fritzbox eingerichtet, die ebenfalls ordnungsgemäß funktioniert.

Schön, ... jetzt sind wir genau wieder dort wo wir nach deinem 1. Beitrag (dieses Threads) waren.

[grosser]

puh.....

ich hatte auch mal die beide Einträge ergänzt

connect-retry xx
connect-retry-max xx

Aber dann hat sich das Plugin auf dem Client nicht mehr starten lassen, es stand als Hinweis ich soll die config prüfen.

EDIT:
Also das Plugin auf dem Receiver kommt mit dem Befehl nicht klar. Wenn ich die Zeilen rausnehme dann wird openvpn auf dem Receiver gestartet