Fastlåst VPN etter omstart av ruteren: tre ting som endret seg

Ruteren blir ferdig med oppstarten, den bærbare maskinen kobler seg til samme SSID igjen, og VPN-en står på tilkoblet uten at noe beveger seg. Den lagrede profilen er intakt. Det som utløp under den, var veien, og klienten holder fortsatt på tilstanden den bygde for den gamle.

Tre betingelser avgjør rettelsen. Sjekk dem i rekkefølge, for de senere er bortkastet arbeid hvis den første allerede forklarer stoppen.

Betingelse én: den lokale adressen er endret

En omstart kan gi maskinen en annen adresse. Da fortsetter en VPN som er konfigurert med et fast lokalt endepunkt, å bruke en tilkobling som ikke finnes lenger. Det samme gjelder en klient som bandt socketen sin til den gamle adressen. Tunngrensesnittet kan bli stående oppe mens hver pakke den produserer går til et ubrukelig sted.

Sammenlign adressen klienten bruker med adressen grensesnittet har nå. En standardrute som peker på en gateway som også er endret, er samme type problem under et annet navn.

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

Betingelse to: den oversatte mappingen er borte

Hjemmerutere oversetter utgående strømmer, og disse mappingene lever i minnet. En omstart sletter hver eneste av dem. Det er ufarlig for en ny tilkobling og dødelig for en tunnel som tror at den eksisterende strømmen fortsatt er gyldig. Da ser motparten ingenting, så klienten får aldri en feil den kan handle på.

Det er her en tunnel uten keepalives stopper stille i stedet for å feile høyt. WireGuards dokumenterte begrensninger beskriver den samme feilformen. Feil endepunktstilstand gir forkastede pakker i stedet for en diagnose.

En vedvarende keepalive på 25 sekunder er den vanlige avbøtningen, fordi den fornyer mappingen før en inaktivitetstidsavbrudd kan utløpe. Den reparerer ikke en mapping som allerede er borte. Kombiner keepaliven med gjenoppkoblingslogikk i stedet for å behandle den som en rettelse.

Betingelse tre: den offentlige adressen er endret

Hvis ruterens egen eksterne adresse er endret, ser alt på den andre siden som filtrerer etter kildeadresse, nå en annen motpart. Tunnelen kan komme opp og serveren kan fortsatt forkaste trafikken, noe som ser ut som en defekt klient og egentlig er en policy i den andre enden.

Noter den eksterne adressen før og etter omstarten. Når de to er forskjellige, flytter spørsmålet seg fra klienten til den som vedlikeholder tillatt-listen, og nullstilling av påloggingsinformasjon på den bærbare maskinen kan ikke hjelpe.

Gjenopprett i riktig rekkefølge

Fullfør først en eventuell påkrevd captive-portal-innlogging, og la deretter klienten koble til på nytt gjennom prosedyren den støtter, i stedet for å drepe prosessen. Se om både identitet og datatrafikk kommer tilbake, for det er to forskjellige stadier av samme tilkobling.

En bufret side beviser ingenting, og det gjør heller ikke en chat-app som koblet til på nytt av seg selv. Test endepunktet du faktisk bryr deg om, med en ny forespørsel. Hold policyen for direkte trafikk i kraft under avbruddet, for et gjenoppkoblingsforsøk er ikke en blokkering.

Når dette gjentar seg etter hver omstart, betyr registreringen mer enn forsøket. Noter den lokale adressen, gatewayen, den eksterne adressen og klienttilstanden før og etter, og sammenlign deretter de to kolonnene. Det gjør en vag klage om til en livssyklusfeil noen kan rette, og det hindrer at sertifikatene blir byttet ut for tredje gang på grunn av en mapping-tidsavbrudd.