Fastlåst VPN efter omstart av routern: tre saker som förändrades

Routern blir klar med starten, laptopen ansluter igen till samma SSID, och VPN:en står på ansluten utan att något rör sig. Den sparade profilen är intakt. Det som gick ut under den var vägen, och klienten håller fortfarande kvar det tillstånd den byggde för den gamla.

Tre villkor avgör åtgärden. Kontrollera dem i ordning, för de senare är bortkastat arbete om det första redan förklarar stoppet.

Villkor ett: den lokala adressen har ändrats

En omstart kan ge maskinen en annan adress. Då fortsätter en VPN som är konfigurerad med en fast lokal ändpunkt att använda en anslutning som inte längre finns. Samma sak gäller en klient som band sin socket till den gamla adressen. Tunnelgränssnittet kan stå kvar uppe medan varje paket det producerar går till en oanvändbar plats.

Jämför adressen som klienten använder med adressen som gränssnittet har nu. En standardrutt som pekar på en gateway som också har ändrats är samma sorts problem under ett annat namn.

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

Villkor två: den översatta mappningen är borta

Hemmaroutrar översätter utgående flöden, och dessa mappningar lever i minnet. En omstart raderar varenda en av dem. Det är ofarligt för en ny anslutning och ödesdigert för en tunnel som tror att dess befintliga flöde fortfarande är giltigt. Då ser motparten ingenting, så klienten får aldrig ett fel den kan agera på.

Det är här en tunnel utan keepalives stannar tyst i stället för att misslyckas högljutt. WireGuards dokumenterade begränsningar beskriver samma form av fel. Fel ändpunktstillstånd ger förkastade paket i stället för en diagnos.

En beständig keepalive på 25 sekunder är den vanliga lindringen, eftersom den förnyar mappningen innan en tidsgräns för inaktivitet kan löpa ut. Den reparerar inte en mappning som redan är borta. Kombinera keepaliven med återanslutningslogik i stället för att behandla den som en åtgärd.

Villkor tre: den offentliga adressen har ändrats

Om routerns egen externa adress har ändrats, ser allt på andra sidan som filtrerar på källadress nu en annan motpart. Tunneln kan komma upp och servern kan fortfarande kasta trafiken, vilket ser ut som en trasig klient och egentligen är en policy i andra änden.

Anteckna den externa adressen före och efter omstarten. När de två skiljer sig flyttas frågan från klienten till den som underhåller tillåtlistan, och en återställning av inloggningsuppgifterna på laptopen kan inte hjälpa.

Återställ i rätt ordning

Slutför först en eventuell obligatorisk inloggning på captive-portalen och låt sedan klienten återansluta via sitt stödda förfarande i stället för att döda processen. Se om både identitet och datatrafik kommer tillbaka, för det är två olika faser av samma anslutning.

En cachad sida bevisar ingenting, och det gör inte heller en chattapp som återanslöt av sig själv. Testa den ändpunkt du verkligen bryr dig om med en ny begäran. Behåll policyn för direkt trafik under avbrottet, för ett återanslutningsförsök är inte en blockering.

När detta upprepas efter varje omstart betyder anteckningen mer än försöket. Anteckna den lokala adressen, gatewayen, den externa adressen och klienttillståndet före och efter och jämför sedan de två kolumnerna. Det gör ett vagt klagomål till en livscykelbugg som någon kan rätta, och det hindrar att certifikaten byts ut för tredje gången på grund av en mappningstidsgräns.