VPN se ponovno povezuje tijekom vožnje: promjena radija ili IP-a?
Primopredaja između tornjeva može ostaviti IP put netaknutim. Usporedite klijente koji tunel premještaju s onima koji ga iznova grade i čitajte mrežni događaj, ne vožnju.
Poziv se prekida kad prođete rubom grada, a ikona VPN-a nestaje u istom trenutku. Zavodljivo je to zabilježiti kao „promjena tornja ubila je tunel“. Dogodile su se dvije različite stvari i samo se jedna od njih odnosi na tornjeve. Primopredaja radija može ostaviti vašu IP adresu, zadanu rutu i sesiju potpuno netaknutima, dok će stvarna promjena adrese prekinuti svaki tunel koji se ne može premjestiti s njom. Korisna je vježba usporediti kako klijenti postupaju u tom drugom slučaju, jer vam govori vidite li projektirano ponašanje ili grešku.
Promjena tornja nije nužno promjena adrese
Mobilne mreže drže paketnu sesiju na životu tijekom primopredaja dokle god sidro mobilnosti operatera ostaje isto. Radio veza se mijenja, tunel to ne primjećuje i ni u jednom se zapisu ne bi trebalo pojaviti ponovno povezivanje. To je uobičajen slučaj za kretanje unutar grada.
Adresu mijenja premještanje između sidara, prijelaz s Wi-Fi na mobilnu mrežu ili ponovno uspostavljanje tunela na strani operatera nakon duge pauze. Ti događaji zamjenjuju izvornu adresu koju nose vaši paketi, a peer VPN-a vidi peera koji se premjestio.
Praktična je posljedica da kretanje nije dokaz. Uređaj koji je prešao četrdeset kilometara možda je cijelim putem zadržao jednu adresu, a uređaj koji miruje možda je dvaput promijenio adresu jer je mreža tako odlučila. Bilježenje događaja jedini je način da ih razlikujete.
Dva dizajna: premjesti tunel ili ga iznova izgradi
Klijenti se razlikuju po tome koliko im je važno da se vanjski izvor promijenio. Neki vežu tunel uz adresu na kojoj je izgrađen i zahtijevaju potpunu ponovnu uspostavu. Drugi provjeravaju svaki paket neovisno i samo ažuriraju kamo šalju odgovore.
| 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 |
Gornji redak objašnjava mnoga zbunjujuća izvješća. WireGuard nema sesiju koju bi se moglo prekinuti: svaki paket nosi indeks peera i provjerava se, pa je valjan paket koji dolazi s nove adrese po definiciji od tog peera, a zabilježena završna točka ga slijedi. Klijent koji tijekom vožnje neprekidno prikazuje „povezano“ govori istinu.
Ni donji redak nije greška. Ponovna izgradnja sesije ponovno pokreće provjeru prema trenutačnoj adresi, što je upravo ono što želite kad stara adresa sada može pripadati nekome drugome.
Promatrajte događaj, a ne kretanje
U Androidu podsustav povezivosti izvješćuje promjene mreže kao događaje i upravo njih trebate povezati s ponašanjem klijenta. Ispis je opširan, ali relevantni su dijelovi zadana mreža i njezina 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 strani poslužitelja postoji izravno mjerenje za slučaj roamiga. WireGuard pohranjuje posljednju provjerenu završnu točku za svakog peera, pa se promjena adrese pojavljuje kao promijenjena vrijednost, a ne kao ponovno povezivanje:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesUsporedite završnu točku prije i poslije vožnje. Ako su adresa i port nepromijenjeni, tunel nije morao ništa učiniti i ponovno je povezivanje došlo odnekud drugdje, obično iz aplikacije. Ako se završna točka promijenila, a vremenska oznaka rukovanja ostala je blizu uobičajenog intervala obnove ključa, tunel se premjestio, a nije se ponovno pokrenuo.
Ponovno pokretanje izgleda drukčije: vremenska oznaka rukovanja vraća se na trenutak ponovnog povezivanja, a klijent bilježi slijed inicijalizacije umjesto tihog nastavka.
Kada je ponovno povezivanje ispravno ponašanje
Ako svako ponovno povezivanje tretirate kao kvar, dolazite do konfiguracija koje drže mrtve sesije na životu. Peer čija se adresa promijenila jer ju je mreža preraspodijelila ne bi trebao nastaviti primati promet za staro mapiranje, a klijent koji tiho nastavlja može završiti šaljući u crnu rupu dok ikona ostaje zelena.
Usporedite oba kvara iz korisničke perspektive. Ponovno povezivanje stoji nekoliko sekundi i novu provjeru. Zastario tunel stoji aplikaciju koja se zakoči bez pogreške, što je mnogo teže objasniti i mnogo vjerojatnije prijavljeno kao „internet je pokvaren“.
Ispod se krije i pitanje politike. U praznini između gubitka jednog puta i uspostave drugoga neki klijenti prelaze na izravno slanje prometa. Sprječavanje toga zasebna je kontrola od automatskog oporavka, a klijent može biti dobar u jednome i loš u drugome. Odlučite što vam treba prije nego što podesite bilo što od toga.
Zapišite opaženi slijed
Korisno izvješće imenuje izvor događaja: promjenu zadane mreže s novom adresom, prijelaz s Wi-Fi na mobilnu mrežu ili primopredaju bez ikakve promjene adrese. Zatim navodi što je klijent učinio, s vremenskom oznakom sa strane poslužitelja, a ne iz sjećanja.
Ako se tunel premjestio, recite to i zabilježite novu obitelj završnih točaka. Ako je iznova uspostavljen, zabilježite je li provjera uspjela iz prvog pokušaja i koliko je praznina trajala. Te tri činjenice razlikuju zdrav mobilni dizajn od klijenta koji se prebacuje između mreža.
I izbjegavajte izraz „promjena tornja“ osim ako zapis uređaja to doista potvrđuje. Dokumentacija Androida o povezivosti opisuje povratne pozive koji razlikuju dostupnost od promjene zadane mreže, a upravo je ta razlika ono što vaše izvješće treba. Sve ostalo priča je o vožnji.