systemd stoppt den VPN-Dienst: Type= zum Client passend machen

Units können korrekt aussehen, systemctl start kann Erfolg melden, und zehn Sekunden später steht der Dienst inaktiv. Oder er startet alle halbe Minute neu, bis das Startlimit ihn stoppt. Keines der beiden Verhalten ist ein Netzwerkfehler: Die Unit beschreibt eine Prozesslebensdauer, die nicht zu dem passt, was der Client tatsächlich tut. Der Client kann forken und sich beenden oder die Sitzung konfigurieren und sofort beenden.

Warum die Unit Sekunden nach einem erfolgreichen Start inaktiv wird

systemd leitet den Zustand aus dem Prozess ab, den es gestartet hat, daher ist Type= eine Behauptung über diesen Prozess und keine Dokumentation. Mit Type=simple gilt die Unit als aktiv, solange der Befehl läuft, und wird inaktiv, wenn er zurückkehrt. Ein Client, der die Verbindung an einen Helfer übergibt und sich beendet, wirkt deshalb wie ein Absturz, selbst wenn der Tunnel steht. Das Journal zeigt dann ein Start-Stopp-Muster, das sich wie ein fehlerhaftes Binary liest.

Lesen Sie den Unit-Typ neben dem Verhalten des Clients, bevor Sie die Netzwerkkonfiguration anfassen.

Wählen Sie den Typ, der zum Client passt

Zwei Muster decken die meisten Vendor-CLIs ab: ein Befehl, der eine Sitzung konfiguriert und sich beendet, und ein Befehl, der vor der Rückkehr einen Helfer forkt. Jedes verlangt eine andere Unit-Form.

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot mit RemainAfterExit=true hält die Unit aktiv, nachdem der Befehl zurückkehrt, was zum Konfigurieren-und-Beenden-Muster passt, und der Stoppbefehl gibt dem Dienst ein sauberes Herunterfahren. Ein forkender Client behält dieselbe Form, braucht aber Type=forking, damit systemd dem Kind folgt. Setzen Sie Restart=on-failure, RestartSec=30 und ein endliches StartLimitBurst, damit ein Ausfall des Anbieters nicht zu einer Neustartschleife wird, die den Fehler begräbt.

Lassen Sie einen überwachten Client niemals dämonisieren

Supervisoren außerhalb von systemd stoßen an dieselbe Wand. Ein runit-Run-Skript, das einen dämonisierten Client startet, kehrt sofort zum Supervisor zurück, der die Rückkehr als Absturz liest und eine weitere Kopie startet. Jeder Supervisor erwartet, den Vordergrundprozess zu besitzen, so wie sshd -D vorne bleibt. Entfernen Sie das Dämon-Flag bei überwachten Befehlen und lassen Sie den Supervisor die Hintergrundarbeit machen. Wrapper-Skripte, die zurückkehren, bevor der Tunnel existiert, verursachen dieselbe Verwirrung.

Ein Prozess, der sich selbst ablöst, ist für alles unsichtbar, was ihn eigentlich beobachten sollte.

Die Sitzung endet und nimmt den Tunnel mit

Eine Desktop-Sitzung besitzt den Client, den sie startet. Beenden Sie die Anmeldung, und der Sitzungsbus verschwindet und nimmt den Tunnel mit, was erklärt, warum die Verbindung eines grafischen Clients oft abbricht, wenn das letzte Fenster schließt. Server sollten eine System-Unit oder ein NetworkManager-Profil verwenden, das von selbst hochkommt. Eine Benutzer-Unit ist nur sinnvoll, wenn der Tunnel mit der Anmeldung enden soll, also binden Sie sie an das Ziel der grafischen Sitzung und sagen Sie das in ihrer Beschreibung.

Der Dienstbenutzer ist die andere Hälfte desselben Problems. Ein Schlüssel, der root gehört und Modus 0600 hat, ist für eine Unit unter einem anderen Konto unlesbar, egal was sudo in Ihrer Shell erreicht hat.

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

Ordnen Sie Abhängige erst ein, wenn die Adresse existiert

Wenn ein Daemon an eine Tunneladresse bindet, die noch nicht existiert, beendet er sich mit Cannot assign requested address. Die Reparatur ist eine ausdrückliche Reihenfolge, keine Wiederholungsschleife.

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

After= ordnet die Jobs, während Requires= an der Geräte-Unit den Abhängigen an die Existenz der Schnittstelle bindet, was stärker ist, als nur auf das Netzwerkziel zu warten. Laden Sie den Manager nach dem Bearbeiten neu und starten Sie den abhängigen Dienst neu, und lesen Sie dann dessen Journal, statt anzunehmen, die Reihenfolge habe gegriffen. Schicken Sie die Ausgabe des Clients mit StandardOutput=journal oder einer Log-Option ins Journal, denn ein überwachter Client, der in eine Datei schreibt, die niemand öffnet, sieht genauso aus wie einer, der nie gestartet ist.

Starten Sie dann einmal neu und bestätigen Sie, dass die Unit aktiv ist, nachdem das Tunnelgerät erscheint. Eine Reparatur, die nur mit systemctl start geprüft wurde, hat die Startreihenfolge nicht getestet, die sie beheben sollte.