OpenVPN-keepalive oder systemd-Restart: Was stellt die Verbindung wieder her?

Drei verschiedene Dinge können bei einem Tunnel schiefgehen, und sie verlangen drei verschiedene Reaktionen. Der Peer antwortet nicht mehr, der Daemon-Prozess stirbt, oder die Anwendung hinter dem Tunnel bedient nicht mehr. Eine Konfiguration, die bei jedem davon den Dienst neu startet, ist keine sorgfältige Überwachung; sie ist eine grobe Maßnahme, die auf unabhängige Fehler angewandt wird. Ein Vergleich dessen, was jeder Mechanismus tatsächlich beobachten kann, macht die Arbeitsteilung offensichtlich.

Drei Fehler, die wie einer aussehen

Stille des Peers bedeutet, dass die Gegenseite nicht mehr sendet, und OpenVPN kann das selbst erkennen, weil es den Herzschlag besitzt. Prozessende bedeutet, dass der Daemon beendet wurde, was der Dienstmanager bemerkt und OpenVPN nicht. Anwendungsfehler bedeutet, dass der Tunnel in Ordnung ist und etwas dahinter nicht, und keiner der beiden anderen Mechanismen hat eine Möglichkeit, das zu wissen. Jeder braucht eine andere Reaktion, und keiner ist dasselbe wie das Bemerken, dass der Tunnel steht.

Das sind verschiedene Signale aus verschiedenen Schichten, und jedes hat einen Eigentümer, der darauf ohne Raten reagieren kann. Wer sie vermischt, erhält ein System, das auf Symptome neu startet, die es nicht deuten kann.

Schreiben Sie die drei Fälle auf, bevor Sie einen Timer ändern. Die Liste selbst zeigt meist, dass von einem Mechanismus verlangt wird, alle drei abzudecken.

Was keepalive tatsächlich entfaltet

Die Anweisung keepalive ist eine Kurzform, und die Entfaltung hängt vom Modus ab. Auf einem Server wird keepalive 10 60 zu einem lokalen Ping alle zehn Sekunden, einem lokalen Neustart-Timeout von 120 Sekunden und Werten von 10 und 60, die an Clients übergeben werden. Der Timeout des Servers wird absichtlich verdoppelt, damit ein Client die Chance bekommt neu zu starten, bevor der Server aufgibt. Lesen Sie die entfaltete Form in der laufenden Konfiguration, nicht die Kurzform im Profil.

Diese Verdopplung ist der Grund, warum jede Beschreibung falsch ist, die behauptet, beide Seiten starteten nach sechzig Sekunden neu. Sie erklärt auch, warum die beiden Seiten nicht im Takt flattern, wenn ein Pfad schlechter wird.

Der Herzschlag ist OpenVPN-Peer-Verkehr, keine ICMP-Sonde zu einem öffentlichen Host. Eine Antwort beweist nur, dass das ferne Ende des Tunnels lebt. Über die Datenbank oder den Webdienst, den der Nutzer tatsächlich braucht, sagt sie nichts.

Was Restart=on-failure nicht überwacht

Lesen Sie die installierte Unit, bevor Sie eine Überschreibung hinzufügen. Restart=on-failure reagiert auf dokumentierte Prozessfehlerbedingungen, was nicht dasselbe ist wie das Überwachen des Verbindungszustands. Sie greift nicht, weil ein interner Reconnect begonnen hat, und ein sauberes Beenden hat eine andere Semantik als ein Absturz.

Diese Unterscheidung ist wichtig, weil ein interner Neustart denselben Prozess am Leben hält. Die Unit sieht nichts, der Tunnel erholt sich selbst, und das ist das richtige Ergebnis.

Setzen Sie RestartSec und Startgrenzen bewusst, sonst hämmert eine Absturzschleife auf das Gateway und begräbt den eigentlichen Fehler unter Neustartmeldungen. Eine auslösende Neustartgrenze hinterlässt die Unit im Fehlerzustand, was sichtbar ist, eine unbegrenzte Schleife nicht.

ping-restart und ping-exit sind nicht austauschbar

ping-restart löst den internen Neustart von OpenVPN aus und behält den Prozess. ping-exit beendet den Prozess bei derselben Art von Timeout, was die Entscheidung an den Dienstmanager übergibt. Sie schließen sich gegenseitig aus, und die Wahl des zweiten ändert, wer die Wiederherstellung besitzt. Der Unterschied ist, wer entscheidet, es erneut zu versuchen, und wie viel Zustand den Versuch überlebt.

Wenn Sie das Beenden bei Timeout wählen, braucht die Unit eine Neustartrichtlinie und eine Behandlung des Beendigungsstatus, die dazu passen, sonst sieht ein Lebendigkeitsfehler wie ein dauerhaftes Anhalten aus. Persistenzoptionen können Schnittstellen und Routen über einen internen Neustart hinweg bewahren, aber nicht über ein Prozessende hinweg.

Wählen Sie einen Lebenszyklus pro Bereitstellung und schreiben Sie auf, warum. Ein Profil, das beide Anweisungen trägt, ist ein Profil, das sich nicht entschieden hat.

Testen Sie jeden Fehler als eigenen Fall

Simulieren Sie in einem genehmigten Fenster einen stillen Peer, einen getöteten Daemon und eine nicht verfügbare Anwendung, und prüfen Sie dann, welche Wiederherstellung ausgelöst wurde. Ein stiller Peer sollte einen internen Reconnect erzeugen, ein getöteter Prozess einen Unit-Neustart und ein Anwendungsausfall keines von beiden. Wenn zwei Fälle dieselbe Aktion erzeugen, ist die Zuständigkeit noch vermischt.

Wiederholte Wiederherstellung ist auch keine Reparatur. Abgelehnte Anmeldedaten oder zwei Clients, die denselben effektiven Namen teilen, ersetzen einander weiter, und schnellere Timer machen dieses Flattern nur schneller.