VPN se med vožnjo znova poveže: menjava radijske celice ali IP-ja?
Predaja med stolpi lahko pusti pot IP nedotaknjeno. Primerjajte odjemalce, ki tunel premaknejo, s tistimi, ki ga zgradijo znova, in berite omrežni dogodek, ne vožnje.
Klic se prekine, ko se peljete mimo roba mesta, in ikona VPN izgine v istem trenutku. Vabljivo je to zabeležiti kot »menjava stolpa je ubila tunel«. Zgodili sta se dve različni stvari in le ena od njiju zadeva stolpe. Predaja radia lahko pusti vaš naslov IP, privzeto pot in sejo popolnoma nedotaknjene, medtem ko bo resnična sprememba naslova prekinila vsak tunel, ki se ne more premakniti z njo. Koristna vaja je primerjati, kako odjemalci obravnavajo drugi primer, ker vam pove, ali vidite zasnovano vedenje ali hrošča.
Menjava stolpa ni nujno sprememba naslova
Mobilna omrežja ohranjajo paketno sejo med predajami, dokler sidro mobilnosti operaterja ostane isto. Radijska povezava se spremeni, tunel tega ne opazi in v nobenem dnevniku se ne bi smelo pojaviti ponovno povezovanje. To je običajen primer za gibanje znotraj mesta.
Naslov spremeni premik med sidri, preklop z Wi-Fi na mobilno omrežje ali ponovna vzpostavitev tunela na strani operaterja po dolgem premoru. Ti dogodki nadomestijo izvorni naslov, ki ga nosijo vaši paketi, in partner VPN vidi partnerja, ki se je premaknil.
Praktična posledica je, da gibanje ni dokaz. Naprava, ki je prevozila štirideset kilometrov, je morda ves čas ohranila en naslov, naprava, ki miruje, pa je morda dvakrat zamenjala naslov, ker se je tako odločilo omrežje. Zapis dogodka je edini način, da ju ločite.
Dve zasnovi: premakni tunel ali ga zgradi znova
Odjemalci se razlikujejo po tem, koliko jim je mar, da se je zunanji vir spremenil. Nekateri vežejo tunel na naslov, na katerem je bil zgrajen, in zahtevajo popolno ponovno vzpostavitev. Drugi preverjajo vsak paket neodvisno in le posodobijo, kam pošiljajo 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 |
Zgornja vrstica pojasnjuje veliko zmedenih poročil. WireGuard nima seje, ki bi jo bilo mogoče prekiniti: vsak paket nosi indeks partnerja in je overjen, zato je veljaven paket, ki prispe z novega naslova, po definiciji od tega partnerja, in zabeležena končna točka mu sledi. Odjemalec, ki med vožnjo neprekinjeno prikazuje »povezano«, govori resnico.
Tudi spodnja vrstica ni napaka. Ponovna vzpostavitev seje znova izvede preverjanje glede na trenutni naslov, kar je točno tisto, kar želite, ko lahko stari naslov zdaj pripada nekomu drugemu.
Opazujte dogodek, ne gibanja
V Androidu podsistem povezljivosti sporoča spremembe omrežja kot dogodke, in prav te morate povezati z vedenjem odjemalca. Izpis je obsežen, a pomembna dela sta privzeto omrežje in njegov naslov:
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 strežniški strani je neposredna meritev za primer gostovanja. WireGuard shrani zadnjo overjeno končno točko za vsakega partnerja, zato se sprememba naslova pokaže kot spremenjena vrednost in ne kot ponovno povezovanje:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakes
Primerjajte končno točko pred vožnjo in po njej. Če se naslov in vrata nista spremenila, tunelu ni bilo treba storiti ničesar in ponovno povezovanje je prišlo od drugod, običajno od aplikacije. Če se je končna točka spremenila, medtem ko je časovni žig rokovanja ostal blizu običajnemu intervalu obnove ključa, se je tunel premaknil, ne pa znova zagnal.
Ponovni zagon je videti drugače: časovni žig rokovanja se ponastavi na trenutek ponovnega povezovanja, odjemalec pa zapiše zaporedje inicializacije namesto tihega nadaljevanja.
Kdaj je ponovno povezovanje pravilno vedenje
Če vsako ponovno povezovanje obravnavate kot napako, pridete do konfiguracij, ki ohranjajo mrtve seje žive. Partner, katerega naslov se je spremenil, ker ga je omrežje prerazporedilo, ne bi smel še naprej prejemati prometa za staro preslikavo, odjemalec, ki tiho nadaljuje, pa lahko konča s pošiljanjem v črno luknjo, medtem ko ikona ostane zelena.
Primerjajte obe okvari z vidika uporabnika. Ponovno povezovanje stane nekaj sekund in novo preverjanje. Zastarel tunel stane aplikacijo, ki se obesi brez napake, kar je veliko težje razložiti in veliko verjetneje prijavljeno kot »internet je pokvarjen«.
Pod tem se skriva tudi vprašanje politike. V vrzeli med izgubo ene poti in vzpostavitvijo druge nekateri odjemalci preidejo nazaj na neposredno pošiljanje prometa. Preprečevanje tega je ločen nadzor od samodejnega obnavljanja in odjemalec je lahko dober pri enem in slab pri drugem. Odločite se, kaj potrebujete, preden nastavite katero koli od tega.
Zapišite opaženo zaporedje
Koristno poročilo poimenuje vir dogodka: spremembo privzetega omrežja z novim naslovom, preklop z Wi-Fi na mobilno omrežje ali predajo brez kakršne koli spremembe naslova. Nato navede, kaj je storil odjemalec, s časovnim žigom s strežniške strani in ne iz spomina.
Če se je tunel premaknil, povejte to in zabeležite novo družino končnih točk. Če je bil znova vzpostavljen, zabeležite, ali je preverjanje uspelo v prvem poskusu in kako dolgo je vrzel trajala. Ta tri dejstva ločijo zdravo mobilno zasnovo od odjemalca, ki se premetava med omrežji.
In izogibajte se izrazu »menjava stolpa«, razen če dnevnik naprave to res potrdi. Dokumentacija Android o povezljivosti opisuje povratne klice, ki ločijo razpoložljivost od spremembe privzetega omrežja, in prav ta razlika je tisto, kar vaše poročilo potrebuje. Vse ostalo je zgodba o vožnji.