WireGuard scheitert nach Leerlauf: Prüfen Sie zuerst die Richtung

Vier Fragen stehen vor jeder Einstellungsänderung: Funktioniert dieselbe Ressource, während der Client aktiv ist, wie lange dauerte die Leerlaufphase, schlief das Gerät oder wechselte es das Netz, und tritt der Fehler nur bei Verkehr auf, den die Gegenseite beginnt. Die Antworten trennen ein abgelaufenes NAT-Mapping von einem schlafenden Funkmodul und von einer veralteten Anwendung. Sie sagen auch, ob ein Keepalive überhaupt relevant ist. Beginnen Sie mit der Richtung, denn sie kostet einen Befehl und schließt die Hälfte der möglichen Ursachen aus.

Welche Richtung scheitert?

Eine neue ausgehende Anfrage des Clients und Verkehr, der nach einer Ruhephase zu ihm eintrifft, beanspruchen zustandsbehaftete Geräte unterschiedlich. Ausgehende Pakete bauen beim Verlassen ein Mapping neu auf, während eingehende Pakete darauf angewiesen sind, dass das alte Mapping überlebt hat. Diese Asymmetrie ist der ganze Test. Kann der Client nach außen gelangen, kommt aber nichts herein, ist das Mapping wahrscheinlich abgelaufen; funktioniert keines von beiden, ist der Tunnel oder der Netzzugang des Clients weg.

Notieren Sie, wie lange die Ruhephase dauerte und ob das Gerät schlief oder in der Zwischenzeit in ein anderes Netz wechselte. Diese beiden Tatsachen ändern die Diagnose, bevor es eine Einstellung tut.

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Führen Sie die drei Befehle vor und nach der Ruhephase aus, denn jeder beantwortet einen anderen Teil der Frage. Ein Handshake-Zeitstempel, der sich nicht bewegt hat, sagt, dass die Peers aufgehört haben zu reden, während ein Endpunkt, der sich geändert hat sagt, dass das Mapping sich verschoben statt gestorben ist. Die Übertragungszähler zeigen, ob überhaupt etwas angekommen ist, und das ist der Unterschied zwischen einem veralteten Mapping und einer stummen Anwendung. Schreiben Sie die Zahlen an beiden Punkten auf, denn der Vergleich ist der Beweis.

Schlaf, Funkmodul und Anwendungszustand

Auf einem Telefon oder Laptop kann ein schlafendes Gerät den Netzzugang völlig verloren haben, und ein Keepalive kann weder ein ausgeschaltetes Funkmodul wiederherstellen noch ein Captive Portal abschließen, das nicht erfüllt wurde. Mobile Plattformen setzen Hintergrundarbeit per Richtlinie aus, ob periodischer Verkehr weiterläuft, hängt also von der Plattform und davon ab, was die App mit ihr ausgehandelt hat. Eine zwischengespeicherte Verbindung ist der dritte Fall und der irreführendste, weil die Rückkehr des Tunnels nicht dasselbe ist wie die erneute Verbindung der Anwendung mit ihm.

Öffnen Sie die Anwendung nach der Leerlaufphase neu, statt dem Tab zu vertrauen, der offen geblieben ist. Gelingt eine frische Anfrage dort, wo die alte Sitzung scheiterte, war der Tunnel nie das Problem.

Was ein Keepalive tatsächlich tut

PersistentKeepalive sendet regelmäßig ein authentifiziertes leeres Paket an einen Peer, was ausreicht, um ein NAT-Mapping zwischen Peers am Leben zu halten und den Endpunkt der Gegenseite aktuell zu halten, wie der WireGuard-Schnellstart beschreibt. Es repariert weder ein schlafendes Funkmodul noch eine verlorene Route oder eine Anwendung, die nie erneut versucht. Wählen Sie das Intervall über die unterstützten Client-Einstellungen und aktivieren Sie nicht überall einen aggressiven Wert, nur weil eine Statusanzeige still wird.

Die meisten Leerlaufphasen sind keine Fehler. Ein Tunnel, der sich nach fünf Minuten Stille wieder verbindet, verhält sich korrekt, und das Problem ist nur der Fall, in dem etwas von der Gegenseite hätte ankommen sollen.

Warten Sie das Intervall ab, das früher scheiterte

Nehmen Sie eine unterstützte Änderung vor und lassen Sie dann dieselbe Leerlaufphase verstreichen, bevor Sie die Ressource erneut testen. Warten gehört zum Test und ist keine Formalität. Sofortiger Erfolg nach einer Wiederverbindung sagt nichts über ein Langzeit-Leerlaufsymptom aus, denn die Wiederverbindung ist genau das Ereignis, das den Zustand zurücksetzt. Tritt das Problem auch bei aktiver Nutzung auf, kehren Sie zu Handshake- und Datenpfadprüfungen zurück, statt weiteren periodischen Verkehr hinzuzufügen.

Behalten Sie eine Änderung pro Test bei und notieren Sie die verwendete Leerlaufdauer. Ohne das driftet jeder spätere Vergleich, und niemand kann sagen, welche Änderung zählte. Halten Sie die vier Fakten zusammen fest: Richtung, Dauer, Schlafzustand und Verhalten der Anwendung.