OpenVPN wiederholt nach einem TLS-Fehler ständig den Versuch: So stoppen Sie es
Ein TLS-Fehler wird standardmäßig wiederholt, daher kreist der Client und der erste Fehler scrollt aus dem Blick. tls-exit beendet ihn; prüfen Sie, was ihn neu startet.
Der Client verbindet, scheitert während der TLS-Aushandlung, wartet und versucht denselben Server mit demselben Ergebnis erneut. Unter einem Supervisor, der einen gescheiterten Prozess neu startet, werden diese Versuche zu einer endlosen Schleife im Journal, und die erste Diagnosezeile scrollt aus dem Blick. OpenVPN bringt eine Option mit, die dieses Aushandlungsversagen in einen sichtbaren Abbruch verwandelt statt in einen weiteren Versuch. Sie ist eine Diagnose- und Überwachungseinstellung, keine Reparatur, also kombinieren Sie sie mit einer Richtlinie, die den Prozess tatsächlich unten lässt.
Der Kreislauf, der den ersten Fehler verdeckt
Was Sie sehen, ist ein wiederkehrender Block und kein einzelner Fehler: ein Verbindungsversuch, ein TLS-Fehler, eine Pause und dann dieselbe Abfolge. Jede Wiederholung schiebt die ursprüngliche Zeile weiter nach oben im Journal. Startet die Unit bei einem Fehler neu, kann der Kreislauf stundenlang weiterlaufen, ohne dass jemand die Ursache liest. Das Symptom ist die Schleife, obwohl der zugrunde liegende Defekt ein einzelnes Aushandlungsproblem ist.
Interaktive Sitzungen ertragen das, weil ein vorübergehender Fehler beim nächsten Versuch verschwinden kann. Automatisierte Verbindungen können sich denselben Optimismus nicht leisten: Der Prozess muss anhalten, damit ein Mensch oder ein Monitor den Status sieht.
Bevor Sie etwas ändern, erfassen Sie einen vollständigen Zyklus. Notieren Sie die Gegenstelle, die im Fehler genannte TLS-Stufe und ob der Prozess überhaupt beendet wird.
Die Wiederholungsmechanik hinter der Schleife
Wiederholen ist der Standard, weil mehrere unabhängige Timeouts dieselbe Mechanik teilen. connect-retry legt den Abstand zwischen Verbindungsversuchen fest, connect-retry-max kann begrenzen, wie oft jeder entfernte Eintrag versucht wird, und resolv-retry steuert wiederholte Namensauflösungen. Ein TLS-Aushandlungsfehler erreicht diese Mechanik als Transportereignis, daher plant der Client einen weiteren Versuch ein, statt zu melden. Der Standard hilft bei einer instabilen Verbindung und schadet bei einem Defekt, der nicht heilen kann.
Die Option --tls-exit ändert nur den Aushandlungsfall. Das Handbuch beschreibt sie als Beenden bei fehlgeschlagener TLS-Aushandlung, was enger ist als ein Beenden bei jedem Fehler. Timeouts, Resolver-Fehler und Authentifizierungsabsagen behalten ihr eigenes Verhalten.
Den Client bei einem TLS-Fehler beenden lassen
Setzen Sie tls-exit in das Profil, das der Client tatsächlich lädt, oder übergeben Sie --tls-exit beim Start, und führen Sie ihn einmal im Vordergrund aus. Lesen Sie den Exit-Status sowie die letzte Logzeile, denn auf den Status reagiert ein Supervisor. Ein Exit ungleich null nach einem Aushandlungsfehler ist das beabsichtigte Ergebnis. Wenn der Prozess weiter versucht statt zu enden, steht die Option nicht in dem Profil, das der Client tatsächlich lädt.
Der Supervisor entscheidet, ob dieser Abbruch sichtbar ist. Eine systemd-Unit mit Restart=always oder Restart=on-failure startet den Client erneut, also läuft die Schleife weiter und die Option scheint nichts zu bewirken. Prüfen Sie die Richtlinie, bevor Sie dem Client die Schuld geben:
systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager
Restart=no lässt den Prozess unten, und Restart=on-failure startet auch nach einem Status ungleich null neu. Wenn der Fehler sichtbar sein soll, der Dienst sich aber von unabhängigen Abstürzen erholen soll, setzen Sie Restart=on-failure und begrenzen Sie mit StartLimitBurst und StartLimitIntervalSec den Neustartsturm. Lesen Sie dann den Status der Unit, um den letzten Exit-Code zu bestätigen: systemctl status meldet ihn, und das Journal behält den ersten Fehler über den Neustarts.
Schreiben Sie die Entscheidung in die Unit oder in die Profilnotizen. Ein Profil, das bei einem TLS-Fehler beendet, wirkt für die nächste Person wie ein Unfall, wenn der Grund nicht festgehalten ist. Geben Sie an, welche Fehler den Prozess stoppen und welche wiederholt werden sollen.
Mit einem Wegwerf-Endpunkt beweisen
Um das Verhalten zu sehen, bevor Sie ihm trauen, kopieren Sie das Profil und richten die Kopie auf einen Endpunkt, der eine TCP-Verbindung annimmt, aber nie OpenVPN spricht. Ein Listener, der antwortet und dann schweigt, genügt. Mit tls-exit sollte der Client enden, wenn der Handshake scheitert; ohne die Option sollte dasselbe Profil weiter kreisen. Verwenden Sie die Kopie, nie das funktionierende Profil.
Vergleichen Sie die beiden Läufe nach Exit-Status und nach der ersten Fehlerzeile, nicht danach, wie lange jeder dauerte. Der Status sagt, ob die Option ausgelöst wurde, und die erste Zeile sagt, welche Stufe fehlschlug.
Entfernen Sie das Testprofil, wenn Sie fertig sind. Eine Kopie mit einem bewusst falschen Endpunkt ist eine Falle für jeden, der später jedes Profil im Verzeichnis startet.
Stufen, die diese Option nie erreicht
Eine abgelehnte Authentifizierung ist eine spätere Stufe. Wenn der Server das Konto prüft und ablehnt, ist TLS bereits ausgehandelt, also greift tls-exit nicht. Die Wiederholungseinstellungen für die Authentifizierung sind die nächste Stelle, und der Grund des Servers zählt mehr als die letzte Zeile des Clients. Ein falsches Passwort und ein fehlendes Zertifikat können clientseitig ähnliche Meldungen erzeugen.
Eine fehlende Route, ein falscher Resolver oder ein nicht erreichbares Gateway liegen ebenfalls außerhalb der Option, weil sie keine Aushandlungsfehler sind. Stiller Paketverlust ist der am wenigsten offensichtliche Fall: Je nachdem, wie weit der Austausch kam, kann der Client einen Aushandlungsfehler melden oder einfach in einen Timeout laufen.
Halten Sie die Unterscheidung in Ihren Notizen fest. Die Einstellung dient der Diagnose und Überwachung statt der Reparatur, daher behebt sie eine Cipher-Abweichung, ein Zertifikatsproblem oder einen falschen Port nicht. Beheben Sie zuerst die Ursache der gescheiterten Aushandlung und entscheiden Sie dann, ob ein sofortiges Beenden noch zur Bereitstellung passt.