VPN koplar til på nytt under køyring: radioskifte eller IP-skifte?

Anropet blir brote når du køyrer forbi utkanten av byen, og VPN-ikonet forsvinn i same augneblink. Det er freistande å føre det som «basestasjonsskifte drap tunnelen». To ulike ting skjedde, og berre éin av dei handlar om basestasjonar. Ei radiooverlevering kan la IP-adressa, standardruta og sesjonen vere heilt intakt, medan ei ekte adresseendring bryt kvar tunnel som ikkje kan flytte seg med henne. Den nyttige øvinga er å samanlikne korleis klientar handterer det andre tilfellet, fordi det fortel deg om du ser ei designa åtferd eller ein feil.

Eit basestasjonsskifte er ikkje nødvendigvis ei adresseendring

Mobilnett held pakkesesjonen i live gjennom overleveringer så lenge mobilitetsankeret til operatøren blir det same. Radiolenkja skiftar, tunnelen merkar det ikkje, og inga gjenoppkopling bør dukke opp i nokon logg. Dette er det vanlege tilfellet for rørsle innanfor ein by.

Det som endrar adressa, er ei flytting mellom anker, eit skifte frå Wi-Fi til mobilnett eller ein gjenoppbygging av tunnelen på operatørsida etter eit langt avbrot. Desse hendingane erstattar kjeldeadressa pakkane dine ber, og ein VPN-peer ser ein peer som har flytta seg.

Den praktiske konsekvensen er at rørsle ikkje er prov. Eining som har køyrt førti kilometer, kan ha halde éi adresse heile vegen, og ei eining som står stille, kan ha skifta adresse to gonger fordi nettet bestemte det. Å registrere hendinga er den einaste måten å skilje dei på.

To design: flytt tunnelen eller bygg han opp att

Klientar er ulike i kor mykje dei bryr seg om at den ytre kjelda er endra. Nokre bind tunnelen til adressa han vart bygd på og krev full gjenoppbygging. Andre autentiserer kvar pakke uavhengig og oppdaterer berre kvar dei sender svara.

Den øvste rada forklarer mange forvirrande rapportar. WireGuard har ingen sesjon å bryte: kvar pakke ber indeksen til peeren og blir autentisert, så ein gyldig pakke som kjem frå ei ny adresse, er per definisjon frå den peeren, og det registrerte endepunktet følgjer han. Ein klient som viser «tilkopla» ubroten gjennom ein køyretur, snakkar sant.

Den nedste rada er heller ikkje ein feil. Å byggje opp sesjonen att køyrer autentiseringa på nytt mot gjeldande adresse, som er nøyaktig det du vil når den gamle adressa no kan høyre til nokon andre.

Observer hendinga i staden for rørsla

På Android rapporterer tilkoplingssubsystemet nettverksendringar som hendingar, og det er dei du bør korrelere med åtferda til klienten. Dumpen er omfattande, men dei relevante delane er standardnettverket og adressa 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å serversida finst ei direkte måling for roamingtilfellet. WireGuard lagrar det sist autentiserte endepunktet per peer, så ei adresseendring viser seg som ein endra verdi i staden for ei gjenoppkopling:

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

Samanlikn endepunktet før og etter køyreturen. Viss adressa og porten er uendra, har tunnelen aldri trengt å gjere noko, og gjenoppkoplinga kom frå ein annan stad, vanlegvis applikasjonen. Viss endepunktet endra seg medan tidsstempelet til handtrykket heldt seg nær det normale nøkkelbyteintervallet, flytta tunnelen seg i staden for å starte på nytt.

Ein omstart ser annleis ut: tidsstempelet til handtrykket blir nullstilt til augneblinken for gjenoppkoplinga, og klienten loggar ein initieringssekvens i staden for ei stille fortsetjing.

Når gjenoppkoplinga er rett åtferd

Å handsame kvar gjenoppkopling som ein feil fører til konfigurasjonar som held døde sesjonar i live. Ein peer som fekk adressa endra fordi nettet tildelte henne på nytt, bør ikkje halde fram med å ta imot trafikk for den gamle tilordninga, og ein klient som held fram i stillheit, kan enda med å sende i eit svart hol medan ikonet blir grønt.

Samanlikn dei to feila frå brukaren sitt perspektiv. Ei gjenoppkopling kostar nokre sekund og ei ny autentisering. Ein utdatert tunnel kostar ein applikasjon som heng utan feil, noko som er mykje vanskelegare å forklare og mykje meir sannsynleg å bli rapportert som «internett er øydelagt».

Det skjuler seg òg eit prinsippspørsmål under. I gapet mellom å miste éin veg og å etablere ein annan, fell nokre klientar tilbake til å sende trafikk direkte. Å hindre det er ein eigen kontroll frå automatisk gjenoppretting, og ein klient kan vere god på det eine og dårleg på det andre. Bestem kva du treng før du justerer nokon av dei.

Skriv ned den observerte sekvensen

Ein nyttig rapport namngir kjelda til hendinga: ei endring av standardnettverket med ei ny adresse, eit skifte frå Wi-Fi til mobilnett eller ei overlevering heilt utan adresseendring. Deretter seier han kva klienten gjorde, med tidsstempelet frå serversida i staden for frå minnet.

Viss tunnelen flytta seg, seier det og noterer den nye endepunktfamilien. Viss han vart bygd opp att, noterer om autentiseringa lukkast på første forsøk og kor lenge gapet varte. Desse tre fakta skil eit sunt mobildesign frå ein klient som kastar seg mellom nettverk.

Og unnå uttrykket «basestasjonsskifte» med mindre einingsloggen faktisk stadfester det. Androids dokumentasjon om tilkopling skildrar tilbakeringingane som skil tilgjenge frå ei endring av standardnettverket, og det skillet er det rapporten din treng. Alt anna er ei historie om å køyre bil.