Warum ein Azure-OpenVPN-Tunnel etwa alle sechzig Sekunden abbricht

Der Tunnel schließt seinen Handshake ab, überträgt etwa eine Minute lang Datenverkehr und verbindet sich dann neu. Diese Abfolge schließt den üblichen Verdächtigen aus, denn eine Firewall, die den Port blockiert, hätte den Handshake verhindert und nicht die Sitzung. Was du hast, ist ein Streit über die Lebendigkeit: Eine Seite entschied, die andere sei still geworden, und baute einen funktionierenden Tunnel ab. Die Logzeile sagt, welche Seite, und sie bestimmt die Lösung.

Lies diese Zeile, bevor du irgendeinen Timer anfasst.

Der Mythos: Etwas auf dem Pfad blockiert den Tunnel

Wäre ein Port blockiert, würde die Verbindung am Anfang scheitern und scheiternd bleiben. Ein wiederkehrender Zyklus bedeutet, dass Kontrollmeldungen fließen, Sitzungen aufgebaut werden und etwas später im Gespräch immer wieder abläuft. Blockieren erzeugt Stille, und das hier erzeugt einen Rhythmus.

Der Rhythmus ist der nützliche Hinweis. Timer erzeugen ihn; Paketverlust selten.

Lies den Trennungsgrund vor dem Timer

OpenVPN benennt seinen Grund, und jeder Name zeigt auf ein anderes Subsystem. Session invalidated: KEEPALIVE_TIMEOUT ist ein ablaufender Timer, vergleiche also die Werte für ping und ping-restart an beiden Enden. AUTH_FAILED sind Anmeldedaten oder der Zertifikatsstatus, und keine Timeränderung hilft. Ein TLS-Fehler bedeutet, dass die Gegenstellen die Keepalive-Phase gar nicht erreicht haben.

Notiere die Verbindungszeit, die Trennungszeit und ob das Intervall sekundengenau stabil ist. Diese eine Messung trennt einen konfigurierten Zeitplan von einem Zufall.

Ein stabiles Intervall ist ein Timer. Ein driftendes ist eher ein Pfadproblem oder eine verschobene Sitzung.

Zwei Keepalive-Timer, die sich nie einig wurden

Aus dem Portal exportierte Profile tragen manchmal noch Zeilen wie keepalive oder ping-restart, die aus einer Community-Server-Vorlage kopiert wurden. Das Gateway betreibt seine eigene Erkennung toter Gegenstellen und setzt seine eigenen Erwartungen durch, und die beiden Zeitpläne müssen nicht übereinstimmen. Wenn sie sich widersprechen, startet der Client nach einem Zeitplan neu, dem das Gateway nie zugestimmt hat.

Die beiden Werte sind nicht dieselbe Steuerung. ping ist, wie oft der Client ein Echo sendet, und ping-restart ist, wie lange er wartet, ohne etwas zu hören, bevor er den Tunnel abbaut. Ein Profil mit kurzem ping-restart und ein Gateway, das langsam antwortet, starten in jeder stillen Phase neu, was genau die Form eines Ein-Minuten-Zyklus ist.

Die kleinste Änderung auf Clientseite besteht darin, die Timer auf der obersten Ebene des Profils zu neutralisieren, außerhalb jedes Inline-Blocks:

keepalive 0 0

Speichern, Profil neu laden, neu verbinden. Eine Sitzung, die bereits im Speicher liegt, behält die alten Werte, weshalb die Bearbeitung manchmal so aussieht, als hätte sie nichts bewirkt.

Der Zertifikatsname kann sich unter dir verschieben

Die Azure-Zertifikatsauthentifizierung hängt davon ab, dass der Client dem Namen vertraut, den das Gateway heute präsentiert. Eine verify-x509-name-Zeile in einem älteren Download kann einen Namen festnageln, den ein Neuaufbau des Gateways oder eine Zertifikatserneuerung inzwischen geändert hat, und die Abweichung zeigt sich als Wiederverbindungsschleife statt als klarer Fehler. Das Löschen der Zeile stellt die Konnektivität wieder her, was sie zu einer brauchbaren Diagnose und einer schlechten dauerhaften Lösung macht, weil sie auch die Prüfung entfernt. Sobald der Tunnel hält, stelle die Zeile mit dem Namen wieder her, den das Gateway tatsächlich präsentiert.

Teste eine zweite Clientgeneration auf derselben Maschine, bevor du das Gateway bearbeitest. Wenn ein Client schleift und der andere hält, ist das Profil nicht das Problem.

Was zu ändern ist, und in welcher Reihenfolge

Prüfe als Nächstes auf eine verschobene Sitzung. Zwei Geräte, die ein Zertifikat teilen, können sich gegenseitig verdrängen, und das Ergebnis wirkt periodisch, weil beide Seiten sich weiter neu verbinden. Vergleiche die Point-to-Site-Sitzungsdatensätze für dieselbe Identität, die immer wieder auftaucht.

Teste dann den Leerlaufpfad, indem du mehrere Minuten lang kontinuierlichen Datenverkehr laufen lässt. Wenn die Abbrüche aufhören, während Verkehr fließt, gehört der entscheidende Timer zu einem NAT-Gerät oder Lastverteiler auf dem Pfad und nicht zu OpenVPN.

Erst nach diesen vier Tests sollten Gateway-Einstellungen geändert werden.