VPN kobler til på nytt under kjøring: radioskifte eller IP-skifte?

Anropet brytes når du kjører forbi utkanten av byen, og VPN-ikonet forsvinner i samme øyeblikk. Det er fristende å føre det som «basestasjonsskifte drepte tunnelen». To forskjellige ting skjedde, og bare én av dem handler om basestasjoner. En radiooverlevering kan la IP-adressen, standardruten og sesjonen være helt intakt, mens en ekte adresseendring bryter enhver tunnel som ikke kan flytte seg med den. Den nyttige øvelsen er å sammenligne hvordan klienter håndterer det andre tilfellet, fordi det forteller deg om du ser en designet atferd eller en feil.

Et basestasjonsskifte er ikke nødvendigvis en adresseendring

Mobilnett holder pakkesesjonen i live gjennom overleveringer så lenge operatørens mobilitetsanker forblir det samme. Radiolenken skifter, tunnelen merker det ikke, og ingen gjenoppkobling bør dukke opp i noen logg. Dette er det vanlige tilfellet for bevegelse innenfor en by.

Det som endrer adressen, er en flytting mellom ankere, et skifte fra Wi-Fi til mobilnett eller en gjenoppbygging av tunnelen på operatørsiden etter et langt avbrudd. Disse hendelsene erstatter kildeadressen pakkene dine bærer, og en VPN-peer ser en peer som har flyttet seg.

Den praktiske konsekvensen er at bevegelse ikke er bevis. En enhet som har kjørt førti kilometer, kan ha beholdt én adresse hele veien, og en enhet som står stille, kan ha skiftet adresse to ganger fordi nettet bestemte det. Å registrere hendelsen er den eneste måten å skille dem på.

To design: flytt tunnelen eller bygg den opp igjen

Klienter er forskjellige i hvor mye de bryr seg om at den ytre kilden er endret. Noen binder tunnelen til adressen den ble bygget på og krever full gjenoppbygging. Andre autentiserer hver pakke uavhengig og oppdaterer bare hvor de sender svarene.

Den øverste raden forklarer mange forvirrende rapporter. WireGuard har ingen sesjon å bryte: hver pakke bærer peerens indeks og autentiseres, så en gyldig pakke som kommer fra en ny adresse, er per definisjon fra den peeren, og det registrerte endepunktet følger den. En klient som viser «tilkoblet» uavbrutt gjennom en kjøretur, snakker sant.

Den nederste raden er heller ikke en feil. Å bygge opp sesjonen igjen kjører autentiseringen på nytt mot gjeldende adresse, som er nøyaktig det du vil når den gamle adressen nå kan tilhøre noen andre.

Observer hendelsen i stedet for bevegelsen

På Android rapporterer tilkoblingssubsystemet nettverksendringer som hendelser, og det er dem du bør korrelere med klientens atferd. Dumpen er omfattende, men de relevante delene er standardnettverket og adressen dets:

adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40

På serversiden finnes en direkte måling for roamingtilfellet. WireGuard lagrer det sist autentiserte endepunktet per peer, så en adresseendring vises som en endret verdi i stedet for en gjenoppkobling:

sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakes

Sammenlign endepunktet før og etter kjøreturen. Hvis adressen og porten er uendret, har tunnelen aldri trengt å gjøre noe, og gjenoppkoblingen kom fra et annet sted, vanligvis applikasjonen. Hvis endepunktet endret seg mens håndtrykkets tidsstempel holdt seg nær det normale nøkkelbytteintervallet, flyttet tunnelen seg i stedet for å starte på nytt.

En omstart ser annerledes ut: håndtrykkets tidsstempel nullstilles til øyeblikket for gjenoppkoblingen, og klienten logger en initialiseringssekvens i stedet for en stille fortsettelse.

Når gjenoppkoblingen er riktig atferd

Å behandle hver gjenoppkobling som en feil fører til konfigurasjoner som holder døde sesjoner i live. En peer hvis adresse endret seg fordi nettet tildelte den på nytt, bør ikke fortsette å motta trafikk for den gamle tilordningen, og en klient som fortsetter i stillhet, kan ende med å sende i et svart hull mens ikonet forblir grønt.

Sammenlign de to feilene fra brukerens perspektiv. En gjenoppkobling koster noen sekunder og en ny autentisering. En utdatert tunnel koster en applikasjon som henger uten feil, noe som er mye vanskeligere å forklare og mye mer sannsynlig å bli rapportert som «internett er ødelagt».

Det skjuler seg også et spørsmål om prinsipper under. I gapet mellom å miste én vei og etablere en annen, faller noen klienter tilbake til å sende trafikk direkte. Å forhindre det er en egen kontroll fra automatisk gjenoppretting, og en klient kan være god på det ene og dårlig på det andre. Bestem hva du trenger før du justerer noen av dem.

Skriv ned den observerte sekvensen

En nyttig rapport navngir hendelseskilden: en endring av standardnettverket med en ny adresse, et skifte fra Wi-Fi til mobilnett eller en overlevering helt uten adresseendring. Deretter sier den hva klienten gjorde, med tidsstempelet fra serversiden i stedet for fra hukommelsen.

Hvis tunnelen flyttet seg, si det og noter den nye endepunktfamilien. Hvis den ble gjenoppbygd, noter om autentiseringen lyktes på første forsøk og hvor lenge gapet varte. Disse tre fakta skiller et sunt mobildesign fra en klient som kaster seg mellom nettverk.

Og unngå uttrykket «basestasjonsskifte» med mindre enhetsloggen faktisk bekrefter det. Androids dokumentasjon om tilkobling beskriver tilbakeringingene som skiller tilgjengelighet fra en endring av standardnettverket, og det skillet er det rapporten din trenger. Alt annet er en historie om å kjøre bil.