Ein Tunnel, der alle fünfzehn Minuten oder jede Stunde zur selben Minute stirbt, sagt Ihnen, dass ein Timer abgelaufen ist, und nicht, dass das Netz instabil ist. Der sinnvolle Schritt ist, das Intervall zu notieren und es mit den vier Timern zu vergleichen, die dieses Muster erzeugen. Zeitlimits vor diesem Vergleich zu ändern verschiebt den Fehler meist, ohne ihn zu erklären, was das nächste Vorkommen schwerer lesbar macht als das erste. Die Messung kostet zehn Minuten und ersetzt eine Woche Raten.

Machen Sie aus dem Intervall eine Zahl

Sammeln Sie fünf oder sechs Vorkommen und berechnen Sie den Abstand dazwischen, nicht den Abstand vom Tagesbeginn. Ein Abbruch um 09:12, 10:12 und 11:12 ist eine Stundengrenze; ein Abbruch um 09:12, 09:27 und 09:42 sind fünfzehn Minuten seit der letzten erfolgreichen Verbindung. Runden Sie das Ergebnis auf den plausibelsten Timer, nicht auf die nächste Minute.

Notieren Sie zwei Zeitpunkte pro Ereignis: wann sich der Verkehr zuletzt bewegt hat und wann der Client die Trennung gemeldet hat. Sie unterscheiden sich, wenn ein Tunnel still stirbt und der Client es erst beim nächsten Senden bemerkt, und genau dieser Unterschied trennt einen Idle-Timeout von einem harten Fehler. Ein Client, der spät bemerkt, bläht das Idle-Fenster auf, das Sie messen.

Prüfen Sie, ob die Wiederverbindung automatisch erfolgt. Ein Client, der sich binnen Sekunden wieder verbindet, hält das Intervall im Protokoll sichtbar und aus dem Nutzerbericht heraus, weshalb diese Fehler oft als gelegentlich statt periodisch beschrieben werden. Er verbirgt das Ereignis auch vor der Person, die das Notebook benutzt.

Vier Timer, die gleich aussehen

Fast jeder wiederkehrende Tunnelabbruch stammt von einem dieser: eine Protokoll-Rekey, ein ablaufendes Idle-Mapping, ein DHCP- oder Schnittstellenereignis oder eine Kontorichtlinie. Sie unterscheiden sich darin, ob Verkehr floss und was das Protokoll an der Grenze sagt.

Die folgenden Signaturen lohnen sich zu lernen, weil sie Sie drei Erklärungen anhand einer einzigen Protokollzeile verwerfen lassen:

TimerTypical triggerWhat the log shows at the boundary
Protocol rekeyTraffic present, fixed intervalNegotiation lines, sometimes a failure
NAT or firewall idleNo traffic for minutesSilence, then a timeout on send
DHCP lease or link changeHalf the lease, or a radio eventAddress or interface churn
Account session limitWall-clock hours since loginClean disconnect, server-side reason

Die erste Zeile ist ein Sicherheitsmechanismus, der seine Arbeit tut, und die zweite eine Zwischenbox, die Zustand vergisst. Sie zu verwechseln führt entweder dazu, die Rekey zu schwächen, oder dazu, einer Firewall-Regel nachzujagen, die nie beteiligt war.

Beschäftigt gegen untätig sagt Ihnen, welche Hälfte

Führen Sie einen kontrollierten Vergleich mit durchgehendem Verkehr durch, etwa einen langen Stream zu einem Host innerhalb des Tunnels, und beobachten Sie, ob sich das Intervall ändert. Verschwindet der Abbruch, während Daten fließen, ist der Timer idle-basiert.

Übersteht er durchgehenden Verkehr, gehört der Auslöser zur Rekey, Lease oder Richtlinie. Dieser eine Test entfernt die Hälfte der Kandidaten in etwa einer Stunde Beobachtung, und er kostet nichts außer Aufmerksamkeit.

Halten Sie das Zugangsnetz während des Tests unverändert. Der Wechsel zwischen Wi-Fi und Ethernet mitten im Vergleich bringt genau das Schnittstellenereignis ein, das Sie von einem Timer unterscheiden wollen.

Gleichen Sie die Protokollzeile mit der Grenze ab

Lesen Sie die Client- und Serverprotokolle um den aufgezeichneten Zeitpunkt, nicht die ganze Datei. Eine Rekey zeigt Aushandlung; ein Idle-Ablauf zeigt nichts bis zum nächsten Paket; eine Lease-Änderung zeigt Adressarbeit; ein Richtlinienlimit zeigt meist eine saubere administrative Trennung.

Diese Befehle holen das relevante Fenster aus jeder Quelle:

grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg show

Wenn die drei Quellen beim Zeitstempel übereinstimmen, kennen Sie den Besitzer des Timers. Wenn nur das Client-Protokoll etwas enthält, beendet wahrscheinlich nicht der Server die Sitzung.

Reparieren Sie die Stufe, nicht das Symbol

Jeder Besitzer hat eine unterstützte Reparatur. Ein Rekey-Fehler braucht kompatible Vorschläge an beiden Enden. Ein Idle-Ablauf braucht ein Keepalive oder eine kürzere Idle-Erwartung, soweit es der Pfad zulässt. Ein Lease-Ereignis braucht eine Korrektur der Schnittstellen- oder Energieeinstellungen. Ein Kontolimit ist eine Richtlinienentscheidung, kein Fehler.

Rekey oder Authentifizierung abzuschalten, damit das Symbol grün bleibt, tauscht einen sichtbaren Abbruch gegen eine unsichtbare Schwäche und lässt Sie nicht sagen, wann der Tunnel zuletzt frische Schlüssel ausgehandelt hat. Testen Sie danach die ursprüngliche Dauer erneut und behalten Sie die Zeitstempel, damit das nächste Ereignis mit diesem verglichen werden kann, statt von vorn zu beginnen.

Ähnliche Artikel