Nagre-reconnect ang VPN habang nagmamaneho: palit radio o palit IP?
Ang paglipat sa pagitan ng mga tore ay maaaring mag-iwan ng landas ng IP na buo. Ihambing ang mga kliyenteng gumagalaw sa tunnel sa mga muling nagtatayo nito, at basahin ang kaganapan sa network, hindi ang biyahe.
Naputol ang tawag kapag dumaan ka sa gilid ng bayan, at sabay na nawawala ang icon ng VPN. Nakakaakit itong itala bilang “pinatay ng pagpalit ng tore ang tunnel”. Dalawang magkaibang bagay ang nangyari, at isa lamang sa kanila ang tungkol sa mga tore. Ang paglipat ng radyo ay maaaring mag-iwan sa iyong IP address, default na ruta at sesyon na lubos na buo, samantalang ang tunay na pagbabago ng address ay sisirain ang anumang tunnel na hindi makasabay dito. Ang paghahambing kung paano hinahawakan ng mga kliyente ang pangalawang kaso ay ang kapaki-pakinabang na ehersisyo, dahil sinasabi nito kung dinisenyong pag-uugali o bug ang nakikita mo.
Ang pagpalit ng tore ay hindi laging pagpalit ng address
Pinapanatiling buhay ng mga mobile network ang sesyon ng packet sa mga paglipat hangga't nananatiling pareho ang mobility anchor ng operator. Nagbabago ang radio link, hindi ito napapansin ng tunnel, at walang reconnect ang dapat lumitaw sa anumang log. Ito ang karaniwang kaso para sa paggalaw sa loob ng isang lungsod.
Ang nagbabago sa address ay paglipat sa pagitan ng mga anchor, pagpalit mula Wi-Fi patungong cellular, o muling pagtatatag ng tunnel sa panig ng operator pagkatapos ng mahabang pagitan. Pinapalitan ng mga kaganapang iyon ang source address na bitbit ng iyong mga packet, at nakikita ng peer ng VPN ang peer na gumalaw.
Ang praktikal na kahihinatnan ay hindi ebidensya ang paggalaw. Ang device na naglakbay ng apatnapung kilometro ay maaaring nagpanatili ng isang address sa buong daan, at ang device na nakatigil ay maaaring nagpalit ng address nang dalawang beses dahil ganito ang naging pasya ng network. Ang pagtatala ng kaganapan ang tanging paraan upang makilala ang dalawa.
Dalawang disenyo: ilipat ang tunnel o muling itayo
Nagkakaiba ang mga kliyente sa kung gaano nila pinapahalagahan na nagbago ang panlabas na source. Ang ilan ay nagtatali ng tunnel sa address na pinagbasehan nito at nangangailangan ng kumpletong muling pagtatatag. Ang iba ay hiwalay na nagpapatunay sa bawat packet at ina-update lamang kung saan ipinapadala ang mga tugon.
| 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 |
Ipinaliliwanag ng tuktok na hilera ang maraming nakalilitong ulat. Walang sesyon ang WireGuard na masisira: bitbit ng bawat packet ang index ng peer at pinatutunayan ito, kaya ang wastong packet na dumarating mula sa bagong address ay ayon sa kahulugan mula sa peer na iyon, at sinusundan ito ng naitalang endpoint. Ang kliyenteng tuloy-tuloy na nagpapakita ng “konektado” sa isang biyahe ay nagsasabi ng totoo.
Hindi rin depekto ang ilalim na hilera. Ang muling pagtatayo ng sesyon ay muling nagpapatakbo ng pagpapatunay laban sa kasalukuyang address, na siyang eksaktong gusto mo kapag ang lumang address ay maaaring pagmamay-ari na ng ibang tao.
Pagmasdan ang kaganapan sa halip na ang paggalaw
Sa Android, iniuulat ng subsystem ng konektibidad ang mga pagbabago sa network bilang mga kaganapan, at iyon ang dapat mong iugnay sa pag-uugali ng kliyente. Ang dump ay mahaba, ngunit ang mahahalagang bahagi ay ang default na network at ang address nito:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40Sa panig ng server may direktang pagsukat para sa kaso ng roaming. Iniimbak ng WireGuard ang huling napatunayang endpoint sa bawat peer, kaya lumilitaw ang pagbabago ng address bilang binagong halaga sa halip na reconnect:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesIhambing ang endpoint bago at pagkatapos ng biyahe. Kung hindi nagbago ang address at port, hindi kailangang gumawa ng anuman ang tunnel at ang reconnect ay nagmula sa ibang lugar, karaniwang ang application. Kung nagbago ang endpoint habang nanatiling malapit sa normal na pagitan ng pag-renew ng key ang timestamp ng handshake, gumalaw ang tunnel sa halip na nag-restart.
Iba ang hitsura ng restart: nire-reset ang timestamp ng handshake sa sandali ng reconnect, at nagla-log ang kliyente ng sequence ng initialization sa halip na tahimik na pagpapatuloy.
Kailan ang reconnect ang tamang pag-uugali
Ang ituring na depekto ang bawat reconnect ay humahantong sa mga configuration na nagpapanatiling buhay ng mga patay na sesyon. Ang peer na nagbago ang address dahil muling inilaan ito ng network ay hindi dapat magpatuloy na tumanggap ng trapiko para sa lumang mapping, at ang kliyenteng tahimik na nagpapatuloy ay maaaring mapunta sa pagpapadala sa isang itim na butas habang nananatiling berde ang icon.
Ihambing ang dalawang kabiguan mula sa pananaw ng gumagamit. Ang reconnect ay nagkakahalaga ng ilang segundo at isang pagpapatunay muli. Ang lumang tunnel ay nagkakahalaga ng application na nakabitin nang walang error, na mas mahirap ipaliwanag at mas malamang na iulat bilang “sira ang internet”.
May nakatagong tanong din sa patakaran sa ilalim nito. Sa pagitan ng pagkawala ng isang landas at pagtatatag ng iba, ang ilang kliyente ay bumabalik sa direktang pagpapadala ng trapiko. Ang pagpigil doon ay hiwalay na kontrol mula sa awtomatikong pagbawi, at ang isang kliyente ay maaaring magaling sa isa at mahina sa iba. Magpasya kung alin ang kailangan mo bago i-tune ang alinman sa dalawa.
Isulat ang naobserbahang pagkakasunod-sunod
Pinapangalanan ng kapaki-pakinabang na ulat ang pinagmulan ng kaganapan: pagbabago ng default na network na may bagong address, pagpalit mula Wi-Fi patungong cellular, o paglipat na walang anumang pagbabago ng address. Pagkatapos ay sinasabi nito ang ginawa ng kliyente, kasama ang timestamp mula sa panig ng server sa halip na mula sa memorya.
Kung gumalaw ang tunnel, sabihin ito at itala ang bagong pamilya ng endpoint. Kung muling itinatag, itala kung nagtagumpay ang pagpapatunay sa unang pagtatangka at gaano katagal ang pagitan. Ang tatlong katotohanang iyon ay nagtatangi ng malusog na disenyong mobile mula sa kliyenteng pabalik-balik sa pagitan ng mga network.
At iwasan ang pariralang “pagpalit ng tore” maliban kung tunay na pinatutunayan ito ng log ng device. Inilalarawan ng dokumentasyon ng konektibidad ng Android ang mga callback na nagtatangi ng availability mula sa pagbabago ng default na network, at ang pagkakaibang iyon ang kailangan ng iyong ulat. Ang lahat ng iba pa ay kuwento tungkol sa pagmamaneho.