Vastgelopen VPN na een herstart van de router: drie dingen die veranderden

De router is klaar met opstarten, de laptop voegt zich weer bij dezelfde SSID, en de VPN blijft op verbonden staan zonder dat er iets beweegt. Het opgeslagen profiel is intact. Wat eronder verliep, was het pad, en de client houdt nog de status vast die hij voor de oude had opgebouwd.

Drie voorwaarden bepalen de oplossing. Controleer ze in volgorde, want de latere zijn verspilde moeite als de eerste de stilstand al verklaart.

Voorwaarde één: het lokale adres is veranderd

Een herstart kan de machine een ander adres geven. Een VPN die met een vast lokaal eindpunt is geconfigureerd, blijft dan een verbinding gebruiken die niet meer bestaat. Hetzelfde geldt voor een client die zijn socket aan het oude adres had gebonden. De tunnelinterface kan overeind blijven terwijl elk pakket dat hij produceert naar een nutteloze plek gaat.

Vergelijk het adres dat de client gebruikt met het adres dat de interface nu heeft. Een standaardroute die naar een gateway wijst die ook is veranderd, is hetzelfde soort probleem onder een andere naam.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Voorwaarde twee: de vertaalde mapping is weg

Thuisrouters vertalen uitgaande stromen, en die mappings leven in het geheugen. Een herstart wist ze allemaal. Dat is onschadelijk voor een nieuwe verbinding en fataal voor een tunnel die gelooft dat zijn bestaande stroom nog geldig is. Dan ziet de tegenpartij niets, zodat de client nooit een fout krijgt waarop hij kan handelen.

Hier blijft een tunnel zonder keepalives stil hangen in plaats van luid te falen. WireGuards gedocumenteerde beperkingen beschrijven dezelfde vorm van falen. Een verkeerde eindpuntstatus levert weggegooide pakketten op in plaats van een diagnose.

Een blijvende keepalive van 25 seconden is de gebruikelijke verzachting, omdat hij de mapping vernieuwt voordat een idle-timeout kan verlopen. Hij repareert geen mapping die al weg is. Koppel de keepalive aan herverbindingslogica in plaats van hem als oplossing te behandelen.

Voorwaarde drie: het openbare adres is veranderd

Als het eigen externe adres van de router is veranderd, ziet alles aan de andere kant dat op bronadres filtert nu een andere tegenpartij. De tunnel kan omhoog komen en de server kan het verkeer alsnog weggooien, wat op een kapotte client lijkt en in werkelijkheid beleid aan de andere kant is.

Noteer het externe adres voor en na de herstart. Als die twee verschillen, verschuift de vraag van de client naar wie de allowlist beheert, en het resetten van inloggegevens op de laptop kan niet helpen.

Herstel in de juiste volgorde

Rond eerst een vereiste captive-portal-aanmelding af, en laat de client daarna opnieuw verbinden via zijn ondersteunde procedure in plaats van het proces te doden. Kijk of zowel identiteit als dataverkeer terugkomt, want dat zijn twee verschillende fasen van dezelfde verbinding.

Een gecachte pagina bewijst niets, en een chatapp die zichzelf opnieuw heeft verbonden ook niet. Test het eindpunt dat je echt belangrijk vindt met een nieuw verzoek. Houd het beleid voor direct verkeer van kracht tijdens de onderbreking, want een herverbindingspoging is geen blokkade.

Als dit na elke herstart terugkomt, telt de registratie meer dan de nieuwe poging. Noteer het lokale adres, de gateway, het externe adres en de clientstatus voor en na, en vergelijk dan de twee kolommen. Dat maakt van een vage klacht een lifecycle-bug die iemand kan oplossen, en het voorkomt dat de certificaten voor de derde keer worden vervangen door een mapping-timeout.