VPN återansluter under körning: radiobyte eller IP-byte?
En överlämning mellan master kan lämna IP-vägen intakt. Jämför klienter som flyttar tunneln med dem som bygger upp den igen, och läs nätverkshändelsen, inte färden.
Samtalet bryts när du kör förbi utkanten av staden, och VPN-ikonen försvinner i samma ögonblick. Det är frestande att bokföra det som ”mastbytet dödade tunneln”. Två olika saker hände, och bara en av dem handlar om master. En radioöverlämning kan lämna din IP-adress, standardrutten och sessionen helt intakta, medan en verklig adressändring bryter varje tunnel som inte kan flytta med den. Det nyttiga är att jämföra hur klienter hanterar det andra fallet, för det säger om du ser ett designat beteende eller en bugg.
Ett mastbyte är inte nödvändigtvis en adressändring
Mobilnät håller paketsessionen vid liv genom överlämningar så länge operatörens mobilitetsankare förblir detsamma. Radiolänken byts, tunneln märker det inte, och ingen återanslutning bör synas i någon logg. Detta är det vanliga fallet för rörelse inom en stad.
Det som ändrar adressen är en flytt mellan ankare, ett byte från Wi-Fi till mobilnät eller en återuppbyggnad av tunneln på operatörens sida efter ett långt avbrott. Dessa händelser ersätter källadressen som dina paket bär, och en VPN-peer ser en peer som har flyttat.
Den praktiska konsekvensen är att rörelse inte är bevis. En enhet som kört fyrtio kilometer kan ha behållit en adress hela vägen, och en enhet som står stilla kan ha bytt adress två gånger eftersom nätet bestämde det. Att registrera händelsen är det enda sättet att skilja dem åt.
Två designer: flytta tunneln eller bygg om den
Klienter skiljer sig i hur mycket de bryr sig om att den yttre källan ändrats. Vissa binder tunneln till adressen den byggdes på och kräver en fullständig återuppbyggnad. Andra autentiserar varje paket oberoende och uppdaterar bara vart de skickar svaren.
| Mechanism | Behaviour after the source changes | What the user notices |
|---|---|---|
| WireGuard | Endpoint updated on the next authenticated packet | Usually nothing; the tunnel continues |
| IKEv2 with MOBIKE | Security association moves to the new address | Short pause, no re-authentication |
| OpenVPN over UDP with float | Peer address may change without a restart | Might survive, depending on timing |
| Client bound to one address | Session dies and is rebuilt | A visible reconnect and a new authentication |
Den översta raden förklarar många förvirrande rapporter. WireGuard har ingen session att bryta: varje paket bär peerns index och autentiseras, så ett giltigt paket som anländer från en ny adress är per definition från den peeren, och den registrerade slutpunkten följer den. En klient som visar ”ansluten” oavbrutet under en körning talar sanning.
Den nedersta raden är inte heller en defekt. Att bygga upp sessionen igen kör autentiseringen på nytt mot den aktuella adressen, vilket är precis vad du vill när den gamla adressen nu kan tillhöra någon annan.
Observera händelsen i stället för rörelsen
På Android rapporterar anslutningssubsystemet nätverksändringar som händelser, och det är dem du bör korrelera med klientens beteende. Dumpen är omfattande, men de relevanta delarna är standardnätverket och dess adress:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40På serversidan finns en direkt mätning för roamingfallet. WireGuard lagrar den senast autentiserade slutpunkten per peer, så en adressändring visas som ett ändrat värde i stället för som en återanslutning:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesJämför slutpunkten före och efter körningen. Om adressen och porten är oförändrade behövde tunneln aldrig göra något, och återanslutningen kom någon annanstans ifrån, oftast applikationen. Om slutpunkten ändrades medan handskakningens tidsstämpel höll sig nära sitt normala nyckelbytesintervall flyttade tunneln sig i stället för att starta om.
En omstart ser annorlunda ut: handskakningens tidsstämpel nollställs till ögonblicket för återanslutningen, och klienten loggar en initieringssekvens i stället för en tyst fortsättning.
När återanslutningen är rätt beteende
Att behandla varje återanslutning som ett fel leder till konfigurationer som håller döda sessioner vid liv. En peer vars adress ändrades eftersom nätet tilldelade den på nytt bör inte fortsätta ta emot trafik för den gamla mappningen, och en klient som fortsätter i tysthet kan sluta skicka i ett svart hål medan ikonen förblir grön.
Jämför de två felen ur användarens perspektiv. En återanslutning kostar några sekunder och en ny autentisering. En inaktuell tunnel kostar en applikation som hänger sig utan fel, vilket är mycket svårare att förklara och mycket mer sannolikt att rapporteras som ”internet är trasigt”.
Under det döljer sig också en principfråga. I gapet mellan att förlora en väg och att etablera en annan faller vissa klienter tillbaka på att skicka trafik direkt. Att förhindra det är en separat kontroll från automatisk återställning, och en klient kan vara bra på det ena och dålig på det andra. Bestäm vad du behöver innan du justerar någon av dem.
Skriv ned den observerade sekvensen
En användbar rapport namnger händelsens källa: en ändring av standardnätverket med en ny adress, ett byte från Wi-Fi till mobilnät eller en överlämning helt utan adressändring. Sedan anger den vad klienten gjorde, med tidsstämpeln från serversidan i stället för från minnet.
Om tunneln flyttade sig, säg det och notera den nya slutpunktsfamiljen. Om den byggdes upp igen, notera om autentiseringen lyckades på första försöket och hur länge gapet varade. Dessa tre fakta skiljer en sund mobildesign från en klient som kastar sig mellan nätverk.
Och undvik uttrycket ”mastbyte” om inte enhetsloggen faktiskt styrker det. Androids dokumentation om anslutning beskriver återanropen som skiljer tillgänglighet från en ändring av standardnätverket, och den skillnaden är den din rapport behöver. Allt annat är en historia om att köra bil.