VPN genopretter forbindelsen under kørsel: radioskift eller IP-skift?

Opkaldet falder, når du kører forbi byens udkant, og VPN-ikonet forsvinder i samme øjeblik. Det er fristende at bogføre det som “masterskift dræbte tunnelen”. Der skete to forskellige ting, og kun den ene handler om mastere. En radiooverlevering kan lade din IP-adresse, standardrute og session være helt intakt, mens en egentlig adresseændring bryder enhver tunnel, der ikke kan flytte med. At sammenligne, hvordan klienter håndterer det andet tilfælde, er den nyttige øvelse, fordi den fortæller dig, om du ser en designet adfærd eller en fejl.

Et masterskift er ikke nødvendigvis en adresseændring

Mobilnetværk holder pakkesessionen i live gennem overleveringer, så længe operatørens mobilitetsanker forbliver det samme. Radioleddet skifter, tunnelen bemærker det ikke, og ingen genoprettelse bør optræde i nogen log. Det er det almindelige tilfælde for bevægelse inden for en by.

Det, der ændrer adressen, er en flytning mellem ankre, et skift fra Wi-Fi til mobilnet eller en genetablering af tunnelen på operatørens side efter et langt hul. De hændelser erstatter kildeadressen, som dine pakker bærer, og en VPN-peer ser en peer, der er flyttet.

Den praktiske konsekvens er, at bevægelse ikke er bevis. En enhed, der har kørt fyrre kilometer, kan have beholdt én adresse hele vejen, og en enhed, der står stille, kan have skiftet adresse to gange, fordi netværket besluttede det. At registrere hændelsen er den eneste måde at skelne dem på.

To designs: flyt tunnelen eller genopbyg den

Klienter er forskellige med hensyn til, hvor meget de bryder sig om, at den ydre kilde er ændret. Nogle binder tunnelen til den adresse, den blev bygget på, og kræver en fuld genetablering. Andre autentificerer hver pakke uafhængigt og opdaterer blot, hvor de sender svarene hen.

Den øverste række forklarer mange forvirrende rapporter. WireGuard har ingen session at bryde: hver pakke bærer peerens indeks og autentificeres, så en gyldig pakke, der ankommer fra en ny adresse, er per definition fra den peer, og det registrerede endpoint følger den. En klient, der viser “forbundet” uafbrudt gennem en køretur, taler sandt.

Den nederste række er heller ikke en fejl. At genopbygge sessionen kører autentificeringen igen mod den aktuelle adresse, hvilket er præcis det, du vil have, når den gamle adresse nu kan tilhøre en anden.

Iagttag hændelsen i stedet for bevægelsen

På Android rapporterer forbindelsessubsystemet netværksændringer som hændelser, og det er dem, du bør korrelere med klientens adfærd. Dumpet er omfattende, men de relevante dele er standardnetværket og dets adresse:

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 findes der en direkte måling til roamingtilfældet. WireGuard gemmer det senest autentificerede endpoint for hver peer, så en adresseændring vises som en ændret værdi i stedet for en genoprettelse:

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

Sammenlign endpointet før og efter køreturen. Hvis adresse og port er uændrede, har tunnelen aldrig skullet gøre noget, og genoprettelsen kom fra et andet sted, normalt applikationen. Hvis endpointet ændrede sig, mens håndtrykkets tidsstempel blev tæt på dets normale nøgleskiftsinterval, flyttede tunnelen i stedet for at genstarte.

En genstart ser anderledes ud: håndtrykkets tidsstempel nulstilles til genoprettelsens øjeblik, og klienten logger en initialiseringssekvens i stedet for en stille fortsættelse.

Når genoprettelsen er den rigtige adfærd

At behandle enhver genoprettelse som en fejl fører til konfigurationer, der holder døde sessioner i live. En peer, hvis adresse blev ændret, fordi netværket tildelte den til en anden, bør ikke blive ved med at modtage trafik til den gamle mapping, og en klient, der fortsætter i stilhed, kan ende med at sende i et sort hul, mens ikonet forbliver grønt.

Sammenlign de to fejl fra en brugers synspunkt. En genoprettelse koster et par sekunder og en ny autentificering. En forældet tunnel koster en applikation, der hænger uden fejl, hvilket er meget sværere at forklare og meget mere sandsynligt at få rapporteret som “internettet er i stykker”.

Der gemmer sig også et politikspørgsmål nedenunder. I hullet mellem at miste én vej og etablere en anden falder nogle klienter tilbage til at sende trafik direkte. At forhindre det er en separat kontrol fra automatisk gendannelse, og en klient kan være god til det ene og dårlig til det andet. Beslut, hvilken du har brug for, før du justerer nogen af dem.

Skriv den observerede rækkefølge ned

En nyttig rapport navngiver hændelseskilden: en standardnetværksændring med en ny adresse, et skift fra Wi-Fi til mobilnet eller en overlevering helt uden adresseændring. Derefter angiver den, hvad klienten gjorde, med tidsstemplet fra serversiden i stedet for fra hukommelsen.

Hvis tunnelen flyttede, så sig det, og noter den nye endpointfamilie. Hvis den blev genetableret, noter, om autentificeringen lykkedes i første forsøg, og hvor længe hullet varede. De tre fakta adskiller et sundt mobildesign fra en klient, der skvulper mellem netværk.

Og undgå vendingen “masterskift”, medmindre enhedsloggen faktisk fastslår det. Androids dokumentation om forbindelser beskriver de tilbagekald, der skelner tilgængelighed fra en ændring af standardnetværket, og den skelnen er den, din rapport har brug for. Alt andet er en historie om at køre bil.