VPN se znovu připojuje za jízdy: změna rádia, nebo změna IP?

Hovor spadne, když projíždíte okrajem města, a ikona VPN zmizí ve stejný okamžik. Láká zapsat to jako „změna věže mobilní sítě zabila tunel“. Staly se dvě různé věci a jen jedna z nich se týká věží. Předání rádia může nechat vaši IP adresu, výchozí trasu a relaci zcela nedotčené, zatímco skutečná změna adresy přeruší každý tunel, který se s ní nedokáže přesunout. Porovnat, jak klienti zvládají druhý případ, je užitečné cvičení, protože vám řekne, zda vidíte zamýšlené chování, nebo chybu.

Změna věže nemusí být změnou adresy

Mobilní sítě udržují paketovou relaci při předáních živou, dokud zůstává stejný mobilní ukotvovací bod operátora. Rádiové spojení se mění, tunel si toho nevšimne a v žádném logu by se nemělo objevit opětovné připojení. To je běžný případ pohybu uvnitř města.

Adresu mění přesun mezi ukotvovacími body, přepnutí z Wi-Fi na mobilní síť nebo obnovení tunelu na straně operátora po dlouhé pauze. Tyto události nahrazují zdrojovou adresu, kterou nesou vaše pakety, a protějšek VPN vidí protějšek, který se přesunul.

Praktickým důsledkem je, že pohyb není důkaz. Zařízení, které ujelo čtyřicet kilometrů, mohlo celou cestu udržet jednu adresu, a zařízení, které stojí na místě, mohlo dvakrát změnit adresu, protože se tak rozhodla síť. Zaznamenání události je jediný způsob, jak tyto případy rozlišit.

Dva přístupy: přesunout tunel, nebo ho postavit znovu

Klienti se liší v tom, jak moc jim vadí, že se vnější zdroj změnil. Někteří vážou tunel na adresu, na které byl postaven, a vyžadují úplné obnovení. Jiní ověřují každý paket nezávisle a jen aktualizují, kam posílají odpovědi.

Horní řádek vysvětluje mnoho matoucích hlášení. WireGuard nemá žádnou relaci, kterou by šlo přerušit: každý paket nese index protějšku a je ověřen, takže platný paket přicházející z nové adresy je podle definice od tohoto protějšku a zaznamenaný koncový bod ho následuje. Klient, který během jízdy nepřetržitě ukazuje „připojeno“, říká pravdu.

Spodní řádek také není vada. Opětovné sestavení relace znovu spustí ověření proti aktuální adrese, což je přesně to, co chcete, když stará adresa už může patřit někomu jinému.

Sledujte událost, ne pohyb

V Androidu hlásí subsystém konektivity změny sítě jako události a právě ty byste měli korelovat s chováním klienta. Výpis je obsáhlý, ale podstatné části jsou výchozí síť a její adresa:

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

Na straně serveru existuje přímé měření pro případ roamingu. WireGuard ukládá poslední ověřený koncový bod pro každý protějšek, takže změna adresy se projeví jako změněná hodnota, nikoli jako opětovné připojení:

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

Porovnejte koncový bod před jízdou a po ní. Pokud se adresa a port nezměnily, tunel nemusel nic dělat a opětovné připojení přišlo odjinud, obvykle z aplikace. Pokud se koncový bod změnil, ale časové razítko handshake zůstalo blízko běžnému intervalu obnovy klíčů, tunel se přesunul, nikoli restartoval.

Restart vypadá jinak: časové razítko handshake se vynuluje na okamžik opětovného připojení a klient zapíše inicializační sekvenci, nikoli tiché pokračování.

Kdy je opětovné připojení správné chování

Považovat každé opětovné připojení za závadu vede ke konfiguracím, které udržují mrtvé relace naživu. Protějšek, jehož adresa se změnila, protože ji síť přidělila jinam, by neměl dál dostávat provoz pro staré mapování, a klient, který tiše pokračuje, může posílat data do černé díry, zatímco ikona zůstává zelená.

Porovnejte obě selhání z pohledu uživatele. Opětovné připojení stojí několik sekund a nové ověření. Zastaralý tunel stojí aplikaci, která zamrzne bez chyby, což se vysvětluje mnohem obtížněji a mnohem pravděpodobněji se hlásí jako „internet je rozbitý“.

Pod tím se skrývá i otázka zásad. Během mezery mezi ztrátou jedné cesty a navázáním druhé někteří klienti přecházejí k přímému odesílání provozu. Zabránit tomu je samostatná kontrola od automatického obnovení a klient může být v jedné dobrý a v druhé špatný. Rozhodněte, kterou potřebujete, než začnete ladit kteroukoli.

Zapište pozorovanou posloupnost

Užitečné hlášení pojmenuje zdroj události: změnu výchozí sítě s novou adresou, přepnutí z Wi-Fi na mobilní síť nebo předání bez jakékoli změny adresy. Poté uvede, co klient udělal, s časovým razítkem ze strany serveru, nikoli z paměti.

Pokud se tunel přesunul, řekněte to a poznamenejte novou rodinu koncových bodů. Pokud se obnovil, poznamenejte, zda ověření uspělo na první pokus a jak dlouho mezera trvala. Tyto tři skutečnosti odlišují zdravý mobilní návrh od klienta, který přeskakuje mezi sítěmi.

A vyhněte se frázi „změna věže“, pokud to log zařízení skutečně neprokáže. Dokumentace konektivity Androidu popisuje zpětná volání, která rozlišují dostupnost od změny výchozí sítě, a právě tento rozdíl vaše hlášení potřebuje. Vše ostatní je příběh o jízdě.