Fastlåst VPN etter omstart av rutaren: tre ting som endra seg

Rutaren blir ferdig med oppstarten, den berbare maskinen koplar seg til same SSID igjen, og VPN-en står på tilkopla utan at noko bevegar seg. Den lagra profilen er intakt. Det som gjekk ut under han, var vegen, og klienten held framleis på tilstanden han bygde for den gamle.

Tre vilkår avgjer rettinga. Sjekk dei i rekkjefølgje, for dei seinare er bortkasta arbeid viss den første alt forklarer stoppen.

Vilkår éin: den lokale adressa er endra

Ein omstart kan gje maskinen ei anna adresse. Då held ein VPN som er konfigurert med eit fast lokalt endepunkt, fram med å bruke ei tilkopling som ikkje finst lenger. Det same gjeld ein klient som batt socketen sin til den gamle adressa. Tunngrensesnittet kan bli ståande oppe medan kvar pakke det lagar går til ein ubrukeleg stad.

Samanlikn adressa klienten brukar med adressa grensesnittet har no. Ei standardrute som peikar på ein gateway som også er endra, er same slags problem under eit anna namn.

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

Vilkår to: den omsette mappinga er borte

Heimerutarar omset utgåande straumar, og desse mappingane lever i minnet. Ein omstart slettar kvar einaste av dei. Det er ufarleg for ei ny tilkopling og dødeleg for ein tunnel som trur at den eksisterande straumen hans framleis er gyldig. Då ser motparten ingenting, så klienten får aldri ein feil han kan handle på.

Det er her ein tunnel utan keepalives stoggar stille i staden for å feile høgt. WireGuards dokumenterte avgrensingar skildrar den same feilforma. Feil endepunktstilstand gjev forkasta pakkar i staden for ein diagnose.

Ein vedvarande keepalive på 25 sekund er den vanlege avbøtinga, fordi han fornyar mappinga før ein inaktivitetstidsavbrot kan gå ut. Han reparerer ikkje ei mapping som alt er borte. Kombiner keepaliven med attoppkoplinglogikk i staden for å handsame han som ei retting.

Vilkår tre: den offentlege adressa er endra

Viss den eigne eksterne adressa til rutaren er endra, ser alt på den andre sida som filtrerer etter kjeldeadresse, no ein annan motpart. Tunnelen kan kome opp og tenaren kan framleis kaste trafikken, noko som ser ut som ein defekt klient og eigentleg er ein policy i den andre enden.

Noter den eksterne adressa før og etter omstarten. Når dei to er ulike, flyttar spørsmålet seg frå klienten til den som vedlikeheld tillaten-lista, og nullstilling av påloggingsinformasjon på den berbare maskinen kan ikkje hjelpe.

Gjenopprett i rett rekkjefølgje

Fullfør først ein eventuell påkravd captive-portal-innlogging, og la deretter klienten kopie til på nytt gjennom prosedyren han støttar, i staden for å drepe prosessen. Sjå om både identitet og datatrafikk kjem tilbake, for det er to ulike stadium av same tilkopling.

Ei bufra side beviser ingenting, og det gjer heller ikkje ein chat-app som kopla til på nytt av seg sjølv. Test endepunktet du faktisk bryr deg om, med ein ny førespurnad. Hald policyen for direkte trafikk i kraft under avbrotet, for eit attoppkoplingsforsøk er ikkje ei blokkering.

Når dette gjentek seg etter kvar omstart, tyder registreringa meir enn forsøket. Noter den lokale adressa, gatewayen, den eksterne adressa og klienttilstanden før og etter, og samanlikn deretter dei to kolonnane. Det gjer ei vag klage om til ein livssyklusfeil nokon kan rette, og det hindrar at sertifikata blir bytte ut for tredje gong på grunn av ein mapping-tidsavbrot.