VPN nach dem Standby tot: Tunnel verloren oder veraltete App?

Der Deckel geht auf, das WLAN-Symbol ist wieder da, und die VPN zeigt sich weiterhin als verbunden. Die erste interne Seite hängt dann, bis sie in eine Zeitüberschreitung läuft, und ein neuer Tab tut dasselbe. Drei verschiedene Dinge können dieses Bild erzeugen, und sie brauchen drei verschiedene Reparaturen: ein Tunnel, der den Standby nicht überlebt hat, ein Profil, das niemand zum Reaktivieren aufgefordert hat, oder eine Anwendung, die noch eine Sitzung hält, die vor Stunden gestorben ist. Sie zu vergleichen ist schneller als irgendetwas neu zu installieren.

Drei Dinge können nach dem Aufwachen defekt sein

Der erste Kandidat ist der Tunnel selbst. Die Schnittstelle kann mit einer Adresse weiter existieren, während die Peer-Zuordnung weg ist, deshalb ist eine Kontrollleuchte kein Beweis für einen funktionierenden Pfad. Ein Handshake, der älter als der Standby ist, ist der Hinweis, und ein Befehl genügt, um ihn zu sehen.

Der zweite ist die Aktivierung. Viele Clients verbinden sich von selbst wieder; manche nicht, und ein Profil, das niemand zum Zurückkommen auffordert, bleibt einfach da und sieht konfiguriert aus. Dieses Versagen ist absichtlich still, weil nichts einen Fehler gemeldet hat.

Der dritte ist die Anwendung. Ein Browser-Tab, eine SSH-Sitzung oder eine Datenbankverbindung kann einen Netzwerkwechsel als Dateideskriptor überleben, während der Transport darunter tot ist. Eine neue Sitzung funktioniert dann einwandfrei, was Ihnen sagt, dass der Tunnel die ganze Zeit in Ordnung war.

Vergleichen Sie die drei, bevor Sie etwas ändern, denn die Reparaturen überschneiden sich nicht. Einen Client neu zu starten, der nie zum erneuten Start aufgefordert wurde, verschwendet den Beweis, den Sie gebraucht hätten. Notieren Sie, zu welchem Kandidaten das Symptom passt, bevor Sie eine Konfiguration anfassen. Dieser eine Satz entscheidet meist den Rest der Untersuchung.

Erstens: Ist der Tunnel zurückgekommen?

Schauen Sie auf die Schnittstelle und den Peer-Zustand statt auf den Statustext des Clients. Eine Schnittstelle mit Adresse und ohne frischen Handshake ist ein Tunnel, der nur dem Namen nach steht.

ip -brief addr show
wg show
ip route show table all | head -20

Fehlt die Schnittstelle ganz, hat der Tunnel nicht überlebt, und die Frage wird, wer ihn hätte zurückbringen sollen. Ist sie vorhanden, aber der Handshake alt, muss die Peer-Beziehung neu aufgebaut werden, und der Client wartet vielleicht auf Verkehr, der sie auslöst.

Prüfen Sie auch die Routen und die DNS-Konfiguration. Ein Tunnel kann ohne seine Routen zurückkommen, was den verwirrenden Zustand erzeugt, in dem die Schnittstelle steht und interne Namen weiterhin über den falschen Server aufgelöst werden.

Zweitens: Hat irgendetwas ihn zurückgefordert?

Hier zahlt sich der Vergleich aus. Ein OpenVPN-Pluginprofil und eine native WireGuard-Verbindung werden von NetworkManager unterschiedlich behandelt, und die Referenz zu den Verbindungseinstellungen stellt klar, dass connection.autoconnect keine VPN-Profile aktiviert; der Mechanismus, um ein VPN mit einer Verbindung hochzubringen, ist connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Wenn ein manuelles Neuverbinden das Problem jedes Mal behebt, ist das die Signatur einer fehlenden Aktivierung und nicht eines defekten Tunnels. Das Protokoll zeigt normalerweise, wie die Schnittstelle heruntergeht und nichts sie zurückbringt.

Widerstehen Sie dem Drang, sofort einen Standby-Hook hinzuzufügen. Ein Hook, der auslöst, bevor das Netzwerk sich erholt hat, läuft gegen genau den Prozess, dem er helfen will, und macht aus einem reproduzierbaren Problem ein zeitweiliges.

Drittens: Hält die Anwendung alten Zustand?

Öffnen Sie eine völlig neue Sitzung zum selben Ziel, bevor Sie die VPN anfassen. Wenn die neue Sitzung funktioniert und die alte nicht, ist der Tunnel in Ordnung, und die Anwendung hält eine tote Verbindung.

Dies ist die billigste der drei Prüfungen und die am häufigsten ausgelassene, weil das fehlerhafte Fenster direkt auf dem Bildschirm liegt. Schließen Sie es, öffnen Sie es wieder, und notieren Sie, ob das Problem überlebt. Wenn die neue Sitzung funktioniert, beenden Sie die Untersuchung des Tunnels vollständig. Wenn auch sie scheitert, ist die Anwendung ein Symptom und keine Ursache.

Manche Anwendungen erholen sich nach einer Zeitüberschreitung von selbst, deshalb kann es aussehen, als würde sich das Symptom nach ein paar Minuten selbst beheben. Dieses Verhalten weist auf die Anwendung und nicht auf den Tunnel hin, und es lohnt sich, es getrennt zu notieren. Ein Kollege, der sagt, es habe sich einfach selbst repariert, beschreibt dieses Muster und keinen Glücksfall.

Machen Sie den Vergleich reproduzierbar

Halten Sie die Variablen klein: ein Zugangsnetz, eine Standby-Dauer und jedes Mal dieselbe erste Anfrage. Protokollieren Sie dann zwei Ergebnisse: ob manuelles Neuverbinden es repariert und ob ein weiterer Standby den Fehler zurückbringt.

Diese letzte Beobachtung trennt die drei Kandidaten am zuverlässigsten. Eine funktionierende neue Sitzung nach einer gescheiterten alten ist kein Tunnelproblem, und keine Neuinstallation des Clients wird das ändern.

WireGuards dauerhaftes Keepalive gehört in dieses Bild nur als Keepalive für eine NAT-Zuordnung. Es sendet Pakete, um eine Zuordnung offen zu halten; es hindert den Rechner nicht am Standby und kann nicht weiter senden, während der Prozess ausgesetzt ist.

Notieren Sie im Ticket, was Sie gefunden haben: welches der drei Dinge defekt war, was es repariert hat und wie Sie es reproduziert haben. Die nächste Person, die an einem Montag einen Deckel öffnet, wird Ihnen danken, und die Antwort muss nicht von vorn neu entdeckt werden.