Stündlicher OpenVPN-Abbruch: Neuverhandlung oder echte Wiederverbindung?

Sechzig Minuten, oder dreißig, oder hundertzwanzig: ein Abbruch, der auf ein rundes Intervall fällt, ist fast nie das Netzwerk. OpenVPN erneuert die Schlüssel, die den Datenkanal schützen, nach einem Timer, und ein Timer, der kürzer ist als der angenommene, sieht genau wie eine Verbindung aus, die immer wieder ausfällt. Nutzer melden eine kaputte Verbindung, während das Log einen erfolgreichen Schlüsselaustausch meldet. Die Anleitung unten trennt diese Erneuerung von einem echten Neustart, liest den tatsächlich geltenden Wert und ändert ihn erst, nachdem die Kosten auf dem Tisch liegen.

Arbeiten Sie die Schritte der Reihe nach ab, denn der erste entscheidet, ob der Rest der Seite überhaupt auf Sie zutrifft. Springen Sie vor, und Sie verbringen einen Abend damit, einen Timer für einen Fehler zu justieren, der nichts damit zu tun hat.

Unterscheiden Sie einen weichen Reset von einem Neustart

Die Logzeile ist die ganze Diagnose. Eine Neuverhandlung schreibt einen weichen Reset und dann einen frischen Schlüsselaustausch in denselben Tunnel: Die Schnittstelle behält ihre Adresse, Routen werden nicht neu hinzugefügt, und bestehende TCP-Sitzungen überstehen es meist mit einer Pause. Ein echter Neustart reißt die Sitzung ab, baut die Schnittstelle neu auf, vergibt möglicherweise eine andere Client-Adresse und beendet jede langlebige Verbindung. Beide Ereignisse sind normal; nur eines erklärt einen abgebrochenen Anruf.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

Die Versionszeile ist wichtig, weil sich die Logformulierung zwischen Releases verschiebt und eine Meldung, die Sie aus 2.3 kennen, in 2.6 anders formuliert sein kann. Lesen Sie Ihr eigenes Log statt eines Forumsauszugs von jemand anderem. Zitieren Sie die genaue Zeile, wenn Sie um Hilfe bitten, denn eine Paraphrase verliert das Detail, das das Ereignis identifiziert. Wenn die Schnittstellenadresse über das Ereignis hinweg unverändert bleibt und die Sitzungsliste überlebt, sehen Sie eine Erneuerung, und die übrigen Abschnitte gelten.

Lesen Sie den effektiven Timer, nicht Ihre Datei

reneg-sec ist die Anzahl der Sekunden zwischen Neuverhandlungen des Datenkanals, und der Standardwert ist 3600. Jeder Peer trägt seinen eigenen Wert, und der kleinere der beiden löst die Erneuerung tatsächlich aus. Diese eine Regel erklärt die meisten Meldungen: Ein Client-Profil, das eine große Zahl setzt, wird trotzdem stündlich zurückgesetzt, solange der Server den Standard behält.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Lesen Sie auch die effektive Konfiguration des Servers, einschließlich allem, was er pusht, bevor Sie aus der Client-Datei einen Schluss ziehen. Erhöhen Sie dann die Ausführlichkeit und beobachten Sie ein Intervall von Anfang bis Ende: Ebene 3 zeigt die Neuverhandlungszeilen bereits, und die Zeitstempel sagen Ihnen, ob sich das Ereignis alle 3600 Sekunden wiederholt oder stattdessen der Aktivität folgt.

Ändern Sie es dort, wo es tatsächlich gepusht wird

Das kursierende Heilmittel ist eine einzige Zeile im Client-Profil, und etwa die Hälfte der Zeit ist es der falsche Ort. Weil der niedrigere Peer-Wert gewinnt, kann ein Client, der den Timer auf null setzt, trotzdem von einem Server neu verhandelt werden, der sich nicht geändert hat.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

Wo Profile zentral erzeugt werden, bearbeiten Sie die Vorlage statt der ausgerollten Kopie, sonst stellt der nächste Provisionierungslauf den gerade entfernten Wert wieder her. Prüfen Sie, indem Sie zwei Intervalle beobachten, nicht eines: Eine einzelne ruhige Stunde passt auch zu einem Timer, der auf 7200 gesetzt wurde.

Entscheiden Sie auch, was bei einer gemischten Einführung passiert. Wenn Sie die Änderung zuerst auf die Clients ausrollen, bleibt ein Fenster, in dem der Server die Erneuerung noch auslöst; das ist harmlos, aber verwirrend, wenn Sie die Logs auf Bestätigung prüfen. Ändern Sie zuerst die Seite mit dem kleineren Wert, und das Symptom verschwindet an dem Punkt, den Sie erwarten.

Was Sie aufgeben, wenn Sie die Neuverhandlung abschalten

Regelmäßige Neuverhandlung begrenzt, wie lange ein einzelner Satz Datenkanalschlüssel den Verkehr schützt. Den Timer abzuschalten bricht den Tunnel nicht, und auf einem Heimrouter oder einem kleinen Büro-Gateway ist die praktische Exposition bescheiden. Es bleibt ein Tausch, und der Tausch ist es wert, benannt zu werden, bevor Sie ihn eingehen. Was sich ändert, ist, wie lange ein Schlüsselsatz eine Sitzung schützt, nicht ob der Tunnel überhaupt funktioniert.

Der vernünftige Fall fürs Abschalten ist ein Reset, der etwas bricht, das nicht fortgesetzt werden kann: ein Anruf, der abbricht, eine Remotedesktop-Sitzung, die neu aufgebaut werden muss, eine Sicherung, die von vorn beginnt. Wenn die Pause für Nutzer unsichtbar ist, kostet der Standard nichts und bewahrt Ihnen die Schlüsselrotation.

Beheben Sie lieber die Ursache, wenn das Muster es zulässt. Eine Erneuerung, die auf halbem Weg scheitert, während der erste Handshake gelang, deutet auf den Pfad statt auf den Timer: Suchen Sie ein Paketgrößenproblem im größeren Austausch des Steuerkanals, eine zustandsbehaftete Firewall, die den Fluss verwirft, oder einen Vorschlag, der nur beim ersten Versuch gelingt. Jedes davon hinterlässt eine Spur in demselben Log, das Sie gerade gelesen haben. Den Timer abzuschalten verbirgt diesen Beweis.

Wenn das Intervall woanders hinzeigt

Zwei Nachbarn in der Konfiguration erzeugen ähnliche Symptome und unterschiedliche Korrekturen. ping-restart startet den Tunnel neu, wenn für einen konfigurierten Zeitraum nichts ankommt, während ping-exit den Client vollständig herunterfährt. Ein Leerlauf-Abbruch ohne jegliche Neuverhandlung im Log gehört zu diesen oder zu einem NAT-Gerät, dessen UDP-Mapping nach seinem eigenen Zeitplan abgelaufen ist.

Consumer-Router, mobile Hotspots und Carrier-Grade-NAT lassen Leerlauf-UDP-Sitzungen ablaufen, ohne es jemandem zu sagen. Dieser Fehler folgt dem Leerlauf statt der Uhr, und das ist das Kennzeichen: Eine Sitzung, die nach zehn ruhigen Minuten abbricht und eine Stunde gleichmäßigen Verkehrs übersteht, verhandelt nicht neu.

Notieren Sie drei Dinge, bevor Sie ein viertes ändern: das gemessene Intervall, den gefundenen effektiven Wert und den Befehl, der ihn zeigte. Bewegt sich das Intervall, wenn sich der Timer bewegt, ist der Mechanismus identifiziert, und die Korrektur ist eine Entscheidung über den obigen Tausch. Bewegt es sich nicht, stellen Sie die Einstellung zurück und schauen Sie weiter auf Keepalives, NAT-Zustand und Paketverlust.