Warum Ihr OpenVPN-Client nach einer einzigen Zeitüberschreitung ausfällt

Montagmorgen: Der Tunnel, der am Freitag aufgebaut wurde, ist weg, die Schnittstelle wird noch aufgeführt, und im Journal steht nichts davon, dass es jemand bemerkt hätte. Der Host ist online, das Dashboard ist grün, und was er am Wochenende gesendet hat, ging stattdessen über die physische Schnittstelle hinaus. Hier fehlen zwei unabhängige Entscheidungen: eine darüber, ob der Clientprozess einen vorübergehenden Fehler übersteht, und eine darüber, ob etwas darüber den Prozess nach seinem Ende erneut startet. Behebt man nur eine davon, bleibt die andere Lücke offen.

Gehen Sie davon aus, was die Unit tatsächlich getan hat, nicht davon, was das Monitoring behauptet. systemctl status openvpn-client@office und journalctl -u openvpn-client@office -n 50 zeigen den Beendigungsgrund und die letzte Zeile, die der Client vor seinem Ende geschrieben hat.

Der Prozess endete, bevor es jemand bemerkte

Ein Client, der ohne Fehler verschwindet, wurde meist absichtlich beendet. Das Profil entscheidet über dieses Verhalten, nicht der Dienstmanager: ping-exit beendet den Prozess, sobald der Peer nicht mehr antwortet, während ping-restart den Prozess behält und sich innerhalb seiner neu verbindet. Sitzungslimits und Inaktivitäts-Timer erzeugen von außen dasselbe Bild: kein Tunnel und kein Alarm.

Die beiden Ping-Direktiven können nicht gemeinsam in einem Profil stehen, wählen Sie also eine und dokumentieren Sie die Entscheidung. Prüfen Sie auch den Server, denn sein eigenes ping-exit schließt eine Sitzung unabhängig davon, was der Client angefordert hat, und nur das Server-Log hält fest, wer das veranlasst hat.

Zwischen ping-exit und ping-restart wählen

Wählen Sie ping-restart für einen Laptop oder einen entfernten Standort, der sich selbst heilen soll, und halten Sie ping-exit für Fälle zurück, in denen ein toter Tunnel den Prozess stoppen muss, damit etwas anderes darauf reagieren kann. Die Zahlen sind weniger wichtig als der Zusammenhang: ping 10 mit ping-restart 60 bedeutet zehn Sekunden Stille vor einer Prüfung und sechzig bis zum Neustart, was auf einer verlustbehafteten Mobilfunkverbindung aggressiv und auf einer kabelgebundenen vernünftig ist. Notieren Sie die Begründung neben der Zeile, denn der nächste Leser wird sonst annehmen, die Standardwerte seien Absicht gewesen.

Bestätigen Sie dann, dass wirklich der Prozess beendet wurde. Eine Unit, die aktiv meldet, während der Tunnel tot ist, ist ein anderer Fehler, der weiter unten behandelt wird.

Überwachung, die die Unit tatsächlich neu startet

Auf einem systemd-Host ist die kleinste dauerhafte Änderung eine Drop-in-Datei: Restart=on-failure und RestartSec=10 in /etc/systemd/system/[email protected]/restart.conf. Ein Drop-in wird nur gelesen, wenn systemd seine eigenen Definitionen neu lädt, führen Sie danach also systemctl daemon-reload aus. Prüfen Sie mit systemctl show -p Restart -p ExecMainStatus openvpn-client@office, statt anzunehmen, der Wert sei angekommen. Die Instanz im Dateinamen muss das Profil sein, das die Unit wirklich lädt, eine für office geschriebene Datei bewirkt für openvpn-client@home also nichts.

on-failure ignoriert einen Fall: einen sauberen Ausstieg mit Status null. Manche Abbauwege enden so, lesen Sie daher den aufgezeichneten Status, statt dem Wortlaut einer Manpage zu vertrauen. Wenn Ihr Client mit einer Null aufgibt, brauchen Sie Restart=always, und der Preis dafür ist, dass ein wirklich kaputtes Profil immer wieder zurückkommt, bis das Startratenlimit greift und das Journal vollläuft.

Restart=always greift auch nach einem absichtlichen Stopp. Verwenden Sie systemctl stop für Wartungsarbeiten und maskieren Sie die Unit, wenn sie während der Arbeit unten bleiben muss.

Das Leck erkennen, solange der Tunnel unten ist

Die Überwachung sorgt dafür, dass der Tunnel zurückkommt; sie verhindert nicht, dass Verkehr abfließt, während der Tunnel weg ist. persist-tun behält das Gerät und seine Routen über Neuverbindungen hinweg, was bequem ist und ein Fenster öffnet. Das Gerät überlebt, die Routen zielen weiterhin darauf, und Pakete fließen ungeschützt und unbemerkt ab. Das ist eine Richtlinienentscheidung, kein neutraler Standard.

Wenn ein Host überhaupt keine ungeschützten Pakete aussenden darf, kann das nur die Firewall garantieren. Eine Ausgangsregel, die die Tunnelschnittstelle und die Adresse des VPN-Servers erlaubt und alles andere verwirft, hält auch nach dem Tod des Clients, und nichts in der Konfiguration des Clients kann Verkehr filtern, den der Client nicht trägt.

Testen Sie es, indem Sie den Client absichtlich stoppen. Führen Sie systemctl stop openvpn-client@office aus, dann curl -m 5 https://example.com, was über die physische Verbindung fehlschlagen statt gelingen sollte. Ein Erfolg bedeutet, dass die Firewall-Regel fehlt oder zu freizügig ist.

Verbinden Sie sich neu, bestätigen Sie, dass der Tunnel wieder Verkehr trägt, und fügen Sie die Prüfung erst dann dem Monitoring hinzu. Das Abfragen von ip addr per Cron nach einem tun-Gerät ist die Überwachung, die am häufigsten scheitert, denn mit persist-tun überlebt das Gerät die Sitzung, und die Prüfung meldet Gesundheit, während nichts übertragen wird.