VPN sa znovu pripája počas jazdy: zmena rádia alebo zmena IP?
Odovzdanie medzi vežami môže nechať IP cestu nedotknutú. Porovnajte klientov, ktorí tunel presúvajú, s tými, ktorí ho stavajú znova, a čítajte sieťovú udalosť, nie jazdu.
Hovor spadne, keď prechádzate okrajom mesta, a ikona VPN zmizne v tom istom okamihu. Láka zapísať to ako „zmena veže zabila tunel“. Stali sa dve rôzne veci a iba jedna z nich sa týka veží. Prestup rádia môže nechať vašu IP adresu, predvolenú trasu a reláciu úplne nedotknuté, zatiaľ čo skutočná zmena adresy preruší každý tunel, ktorý sa s ňou nedokáže presunúť. Porovnať, ako klienti zvládajú druhý prípad, je užitočné cvičenie, pretože vám povie, či vidíte zamýšľané správanie alebo chybu.
Zmena veže nemusí byť zmenou adresy
Mobilné siete udržiavajú paketovú reláciu pri odovzdaniach živú, kým zostáva rovnaký mobilný ukotvovací bod operátora. Rádiové spojenie sa mení, tunel si to nevšimne a v žiadnom logu by sa nemalo objaviť opätovné pripojenie. To je bežný prípad pohybu vnútri mesta.
Adresu mení presun medzi ukotvovacími bodmi, prepnutie z Wi-Fi na mobilnú sieť alebo obnovenie tunela na strane operátora po dlhej pauze. Tieto udalosti nahrádzajú zdrojovú adresu, ktorú nesú vaše pakety, a náprotivok VPN vidí náprotivok, ktorý sa presunul.
Praktickým dôsledkom je, že pohyb nie je dôkaz. Zariadenie, ktoré prešlo štyridsať kilometrov, mohlo celú cestu udržať jednu adresu, a zariadenie, ktoré stojí na mieste, mohlo dvakrát zmeniť adresu, pretože sa tak rozhodla sieť. Zaznamenanie udalosti je jediný spôsob, ako ich rozlíšiť.
Dve riešenia: presunúť tunel alebo ho postaviť znova
Klienti sa líšia v tom, ako veľmi im vadí, že sa zmenil vonkajší zdroj. Niektorí viažu tunel na adresu, na ktorej bol postavený, a vyžadujú úplné obnovenie. Iní overujú každý paket nezávisle a len aktualizujú, kam posielajú odpovede.
| 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 |
Horný riadok vysvetľuje mnoho mätúcich hlásení. WireGuard nemá žiadnu reláciu, ktorú by bolo možné prerušiť: každý paket nesie index náprotivku a je overený, takže platný paket prichádzajúci z novej adresy je podľa definície od tohto náprotivku a zaznamenaný koncový bod ho nasleduje. Klient, ktorý počas jazdy nepretržite zobrazuje „pripojené“, hovorí pravdu.
Spodný riadok tiež nie je chyba. Opätovné zostavenie relácie znova spustí overenie voči aktuálnej adrese, čo je presne to, čo chcete, keď stará adresa už môže patriť niekomu inému.
Sledujte udalosť, nie pohyb
V Androide podsystém konektivity hlási zmeny siete ako udalosti a práve tie by ste mali korelovať so správaním klienta. Výpis je rozsiahly, ale dôležité časti sú predvolená sieť 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 40Na strane servera existuje priame meranie pre prípad roamingu. WireGuard ukladá posledný overený koncový bod pre každý náprotivok, takže zmena adresy sa prejaví ako zmenená hodnota, nie ako opätovné pripojenie:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesPorovnajte koncový bod pred jazdou a po nej. Ak sa adresa a port nezmenili, tunel nemusel nič robiť a opätovné pripojenie prišlo odinakiaľ, zvyčajne z aplikácie. Ak sa koncový bod zmenil, ale časová pečiatka handshake zostala blízko bežnému intervalu obnovy kľúčov, tunel sa presunul, nie reštartoval.
Reštart vyzerá inak: časová pečiatka handshake sa vynuluje na okamih opätovného pripojenia a klient zapíše inicializačnú sekvenciu, nie tiché pokračovanie.
Kedy je opätovné pripojenie správne správanie
Považovať každé opätovné pripojenie za poruchu vedie ku konfiguráciám, ktoré udržiavajú mŕtve relácie nažive. Náprotivok, ktorého adresa sa zmenila, pretože ju sieť pridelila inam, by nemal ďalej dostávať prevádzku pre staré mapovanie, a klient, ktorý potichu pokračuje, môže skončiť odosielaním do čiernej diery, kým ikona zostáva zelená.
Porovnajte obe zlyhania z pohľadu používateľa. Opätovné pripojenie stojí niekoľko sekúnd a nové overenie. Zastaraný tunel stojí aplikáciu, ktorá zamrzne bez chyby, čo sa vysvetľuje oveľa ťažšie a oveľa pravdepodobnejšie sa hlási ako „internet je pokazený“.
Pod tým sa skrýva aj otázka zásad. Počas medzery medzi stratou jednej cesty a nadviazaním druhej niektorí klienti prechádzajú k priamemu odosielaniu prevádzky. Zabrániť tomu je samostatná kontrola od automatického obnovenia a klient môže byť v jednej dobrý a v druhej zlý. Rozhodnite, ktorú potrebujete, skôr než začnete ladiť ktorúkoľvek.
Zapíšte pozorovanú postupnosť
Užitočné hlásenie pomenuje zdroj udalosti: zmenu predvolenej siete s novou adresou, prepnutie z Wi-Fi na mobilnú sieť alebo odovzdanie bez akejkoľvek zmeny adresy. Potom uvedie, čo klient urobil, s časovou pečiatkou zo strany servera, nie z pamäte.
Ak sa tunel presunul, povedzte to a poznamenajte novú rodinu koncových bodov. Ak sa obnovil, poznamenajte, či overenie uspelo na prvý pokus a ako dlho medzera trvala. Tieto tri skutočnosti odlišujú zdravý mobilný návrh od klienta, ktorý prehadzuje medzi sieťami.
A vyhnite sa fráze „zmena veže“, ak to log zariadenia skutočne nepotvrdzuje. Dokumentácia konektivity Androidu opisuje spätné volania, ktoré rozlišujú dostupnosť od zmeny predvolenej siete, a práve ten rozdiel vaše hlásenie potrebuje. Všetko ostatné je príbeh o jazde.