Warum stirbt OpenVPN, nachdem das Notebook aufgewacht ist?

Der Ruhezustand kann die OpenVPN-Sitzung beenden und tun0 zurücklassen. Prüfen Sie den Tunnel und starten Sie dann die Unit über einen systemd-Sleep-Hook neu, nicht das Gerät.

Versetzen Sie die Maschine in den Ruhezustand, wecken Sie sie wieder und prüfen Sie dann drei Dinge in dieser Reihenfolge, bevor Sie irgendeine Konfiguration anfassen: ob tun0 noch existiert, ob die Route zu einer internen Adresse ihn noch wählt und ob der Server diesen Peer noch führt. Ein Gerät, das den Schlaf überlebt, während die Route woanders hinzeigt, ist ein Überbleibsel, kein Tunnel. Wenn die Route stimmt und der Verkehr trotzdem stirbt, liegt der Fehler über dem Tunnel, und ein Neustart des Clients ändert daran nichts. Einen Neustart zu automatisieren ist erst sinnvoll, nachdem ein manueller Test gezeigt hat, welchen dieser drei Fälle Sie haben.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Reproduzieren Sie das Aufwachen, bevor Sie es automatisieren

Der Ruhezustand beendet die verschlüsselte Sitzung öfter, als er das Gerät entfernt. Der UDP-Fluss, der den Tunnel am Leben hielt, stoppt, der Server kann den Peer verwerfen, und der Client bemerkt es entweder und verbindet sich neu oder behält eine Schnittstelle ohne alles dahinter. Eine reine Schnittstellenprüfung beweist wenig, weil ein veraltetes Gerät genauso aussieht wie ein funktionierendes bis Pakete darüber laufen müssen. Führen Sie die Routenabfrage plus eine echte Anfrage durch den Tunnel aus und lesen Sie dann das Journal um den Moment des Aufwachens.

Kommt der Client von selbst zurück, schafft ein Hook zusätzliche Unruhe statt Zuverlässigkeit. Erholt er sich nie, ist Automatisierung die ehrliche Lösung.

Wo ein systemd-Sleep-Hook tatsächlich liegt

Viele ältere Anleitungen zeigen auf /etc/pm/sleep.d, ein Verzeichnis, das pm-utils gehört und von einem systemd-basierten Suspend nie befragt wird. systemd liest Hooks aus /usr/lib/systemd/system-sleep/ und /etc/systemd/system-sleep/, übergibt zuerst die Phase und danach die Operation, sodass pre und post die einzigen Werte sind, auf die ein Hook verzweigt. Legen Sie die lokale Kopie unter /etc ab, statt eine mitgelieferte Datei zu bearbeiten, und bedenken Sie, dass das Skript mitten im Übergang als root läuft, also schnell zurückkehren muss.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart berührt eine Unit nur, wenn sie bereits aktiv ist, sodass ein Tunnel, den Sie absichtlich beendet haben, über das Aufwachen hinweg beendet bleibt. --no-block hält den Hook davon ab, zu warten, während der Client verhandelt, was zählt, wenn das Netz noch nicht oben ist. Zusammen bedeuten die beiden Flags einen Hook, der still scheitert, statt die ganze Aufwachsequenz aufzuhalten. Ist die Unit ohnehin gestoppt, passiert überhaupt nichts, und genau das ist dort das gewünschte Ergebnis.

Stellen Sie den Dienst wieder her, lassen Sie tun0 in Ruhe

Nehmen Sie tun0 von Hand herunter, überwacht der Daemon weiter eine Schnittstelle, die er nicht mehr besitzt, und die nächste Zustandsänderung erzeugt verwirrende Fehler. Zielen Sie auf den Dienst oder sein Verbindungsprofil statt auf die Schnittstelle; prüfen Sie zuerst den genauen Unit-Namen, weil Distributionspakete, OpenVPN 3 und NetworkManager jeweils andere wählen. Ein NetworkManager-Profil kommt zurück, wenn diese Verbindung neu durchlaufen wird, also ist die systemd-Unit dort nicht das Ziel. Wie der Mechanismus auch heißt, es sollte dieselbe Aktion sein, die Sie von Hand geprüft haben.

Ein Neustart installiert die Routen neu, die der Client beim Verbinden gesetzt hat. Die meisten Aufwachvorgänge wollen das. Eine Maschine, auf der Sie eigene Pfade ergänzt haben, nicht, also prüfen Sie diese erneut, statt anzunehmen, die Wiederherstellung hätte sie zurückgebracht, und notieren Sie sie dort, wo der nächste Aufwachvorgang sie findet.

Behandeln Sie das Timing, das Sie nicht steuern

WLAN-Assoziation und DHCP werden oft erst fertig, nachdem der Hook gelaufen ist, sodass ein Neustart scheitern kann, während noch kein Weg zum Server existiert. Warten Sie kurz auf diese Adresse, versuchen Sie es einmal erneut und protokollieren Sie das Ergebnis.

Die Namensauflösung ist ein eigenes Rennen, weil der Netzwerk-Stack des Desktops DNS erst wiederherstellen kann, nachdem der Tunnel schon oben ist. Testen Sie Abfragen separat mit resolvectl query internal.example, statt sie aus einer funktionierenden Route abzuleiten. Ein Tunnel, der korrekt routet und nichts auflöst, ist ein DNS-Problem, kein Hook-Problem.

Halten Sie die Entscheidung des Hooks sichtbar, indem Sie Phase, Unit-Namen und Ergebnis ins Journal schreiben. Notieren Sie in den Maschinennotizen, welchen Aufwachtstest Sie ausgeführt haben, damit sich eine funktionierende Wiederherstellung von einer glücklichen unterscheiden lässt. Wählen Sie die am wenigsten störende Aktion, die den Dienst zurückbringt, und lassen Sie einen Client, der sich selbst erholt, das tun. Ein vollständiger Neustart verwirft laufende Sitzungen, was auf einem Notebook, das mehrmals täglich aufwacht, echte Kosten verursacht.

Ähnliche Artikel