Wie lange soll OpenConnect eine ausgefallene VPN-Verbindung weiter versuchen?

--reconnect-timeout beantwortet eine eng umrissene Frage: Nachdem der Tunnel ausgefallen ist, wie lange versucht dieser Client-Prozess es weiter, bevor er aufgibt und sich beendet. Die OpenConnect-Handbuchseite führt diese Option mit einem dokumentierten Standardwert von 300 Sekunden für Wiederholungen an, die auf einen verlorenen Link oder einen Peer folgen, der nicht mehr antwortet, und die Zahl ist eine Frist für einen laufenden Client, kein Beweis, dass die VPN erreichbar bleibt. Sie ist auch keine Richtlinie, um den Prozess am Leben zu halten, und genau dort beginnt der größte Teil der Verwirrung.

Die Verwirrung wächst, sobald eine zweite Mechanik obenauf sitzt. Ein Supervisor, der den Client neu startet, ein Prüfer, der das Gateway anpingt, und das eingebaute Wiederholungsfenster können alle auf einen Fehler reagieren, und der Vorfall liefert dann drei Zeitlinien, die niemand zusammenbringen kann.

Was das Reconnect-Fenster tatsächlich begrenzt

Stellen Sie sich vor, das Zugangsnetz verschwindet für ein paar Sekunden. Der Client sieht den Link ausfallen oder hört auf, Antworten des toten Peers zu empfangen, und beginnt, die Sitzung neu aufzubauen, während er so viel Zustand hält, wie er kann. Die Wiederholungen laufen weiter, bis das Gateway wieder akzeptiert oder das Fenster abläuft, und ein abgelaufenes Fenster endet in einem Exit ungleich null. Dieser Exit, nicht der Timeout-Wert, ist der Punkt, an dem die Eigentümerschaft am Lebenszyklus an denjenigen übergeht, der den Prozess überwacht.

Das Fenster sagt nichts darüber, wie oft eine Prüfung läuft, und es kann die Authentifizierung nicht verlängern. Wenn das Gateway die Sitzung widerrufen hat oder das Konto jetzt einen frischen zweiten Faktor verlangt, macht längeres Warten die alte Sitzung nicht wieder gültig. Eine Wiederholung gelingt nur, wenn der Pfad zurückkehrt, das Gateway die Sitzung weiterhin erkennt und die verlangten Anmeldedaten nutzbar bleiben, lesen Sie die Zahl also als Frist und nicht als Lebendigkeitsintervall.

Das Fenster regelt auch nicht, was Anwendungen währenddessen tun. Je nach Plattform und je nachdem, wie weit der Fehler gekommen ist, kann der Client neu verbinden, während die Routen noch installiert sind, oder nachdem sie entfernt wurden. Deshalb hängt eine mitten im Ausfall gestellte Anfrage meist bis zum Timeout, statt schnell zu scheitern.

Supervisor-Neustarts und Client-Wiederholungen sind zwei Schichten

Lassen Sie den laufenden Client sein eigenes Fenster aufbrauchen und den Dienstmanager auf den Exit reagieren. Ein Client im Vordergrund unter systemd mit einer Neustartrichtlinie ergibt genau diese Aufteilung: Wiederholungen für einen begrenzten Zeitraum, dann eine einzige Neustartentscheidung. Das Ergebnis ist eine einzige Zeitlinie, die Sie im Nachhinein noch rekonstruieren können.

Ein Client im Hintergrund plus ein unabhängiger Prüfer, der eine weitere Kopie startet, wenn er keine Schnittstelle sieht, ist das Muster, das schiefgeht. Dann konkurrieren beide Prozesse um denselben Geräteknoten, dieselben Routen und dieselben Resolver-Einstellungen. Wenn Sie wirklich einen Daemon wollen, setzen Sie die Option auf die Kommandozeile, mit der der Client tatsächlich startet:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Zwei Details in dieser Zeile wiegen schwer. --background löst den Prozess ab, sodass die pid-Datei das einzige verlässliche Handle darauf wird, und das Timeout wird nur verbraucht, solange derselbe Prozess lebt; ein Supervisor, der ihn tötet, lässt kein Budget zum Weitermachen übrig.

Beabsichtigte Trennungen brauchen ihr eigenes Signal. Eine geplante Pause und ein echter Ausfall sehen für einen naiven Beobachter gleich aus, beide lesen sich als „nicht verbunden“. Treiben Sie die Pause über die Stop-Operation des Supervisors oder eine Markierung, die der Wrapper versteht, damit ein absichtliches Anhalten keinen Neustart auslöst, den niemand wollte.

Die Übergabe nicht gegen die Wiederholungsschleife antreten lassen

Eine unbeaufsichtigte Wiederherstellung hängt von Anmeldedaten ab, die sich ohne anwesende Person erneuern. Ein Schlüsselbund, der sich nur in einer interaktiven Desktop-Sitzung entsperrt, oder ein Token, das immer einen eingetippten Code braucht, lässt den Client auf der Authentifizierungsstufe stranden, sobald der Pfad zurück ist. Klären Sie diesen Ablauf, bevor Sie das Fenster verlängern, denn ein längeres Fenster gibt nur derselben blockierten Abfrage mehr Zeit zu scheitern.

Die Serverprüfung sollte nicht gelockert werden, um Abfragen zu verringern. Gerade die Pinning- oder Trust-Anchor-Prüfung, die das Gateway validiert, macht eine automatische Wiederverbindung sicher, und sie abzuschalten, um eine Zertifikatsfrage zu vermeiden, tauscht eine sichtbare Unterbrechung gegen eine unsichtbare. Behalten Sie die geprüfte Identität und reparieren Sie stattdessen die Abfrage; ein Client, der bereit ist, sich mit jedem Gateway zu verbinden, ist schlechter als einer, der anhält und wartet.

Die Anwesenheit einer Schnittstelle ist ebenfalls kein Gesundheitssignal. Ein Tunnelgerät kann existieren, obwohl dahinter eine tote Sitzung liegt, und ein Starterprozess kann ganz ohne Tunnel existieren. Keine dieser Beobachtungen hält einer echten Anfrage stand. Gesundheit muss aus dem kommen, was der Nutzer braucht, etwa eine Anfrage, die durch den Tunnel zu einem bekannten internen Dienst geht.

Was während und nach einem Ausfall zu prüfen ist

Führen Sie vier Ereignisse als getrennte Tests aus: eine Unterbrechung kürzer als das Fenster, ein Ausfall länger als es, einen Authentifizierungsfehler und ein absichtliches Anhalten. Jedes sollte in einem anderen, vorhersagbaren Zustand enden, und die Grenze zwischen den ersten beiden ist der ganze Grund für die Wahl eines Werts.

Halten Sie die Prüfungen nach außen gerichtet, denn die Prozesstabelle beweist für sich genommen sehr wenig. Beobachten Sie, ob die pid während der kurzen Unterbrechung stabil bleibt, und bestätigen Sie dann nach der langen, dass sie weg und einmal ersetzt ist:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Bestätigen Sie während der kurzen Unterbrechung, dass der Client wirklich erneut versucht hat, statt früh zu beenden, und dass Routen und Resolver-Einträge ohne Duplikate zurückkamen. Für den längeren Ausfall bestätigen Sie einen sauberen Exit und genau einen Neustart danach. Für den Authentifizierungsfehler bestätigen Sie, dass der Client nicht gegen ein Gateway dreht, das ihn weiter ablehnen wird. Ergänzen Sie eine Prüfung, dass die pid zu einem einzigen Wert zurückkehrt, statt sich anzusammeln.

Für das absichtliche Anhalten sollte die Health-URL unerreichbar bleiben und der Prozess unten bleiben. Schließen Sie dann die Schleife von der Anwendungsseite: Dieselbe Anfrage muss scheitern, solange der Tunnel fehlt, und muss nach seiner Rückkehr gelingen, und zwar von der Quelladresse, die Ihre Richtlinie erwartet. Ein grünes Tunnel-Symbol ist kein Beleg, eine abgeschlossene Anfrage schon.