Thirrja ndërpritet kur kaloni buzë qytetit, dhe ikona e VPN-së zhduket në të njëjtin moment. Është joshëse ta shënosh si “ndryshimi i kullës vrau tunelin”. Ndodhën dy gjëra të ndryshme, dhe vetëm njëra prej tyre ka të bëjë me kullat. Një dorëzim radio mund ta lërë adresën tuaj IP, rrugën e paracaktuar dhe sesionin plotësisht të paprekur, ndërsa një ndryshim i vërtetë adrese do të thyejë çdo tunel që nuk mund të lëvizë me të. Ushtrimi i dobishëm është të krahasosh si klientët e trajtojnë atë rastin e dytë, sepse të tregon nëse po shihni sjellje të projektuara apo një gabim.

Një ndryshim kulle nuk është domosdoshmërisht ndryshim adrese

Rrjetet mobile e mbajnë sesionin e paketave gjallë gjatë dorëzimeve për sa kohë ankorimi i lëvizshmërisë së operatorit mbetet i njëjtë. Lidhja radio ndryshon, tuneli nuk e vëren, dhe asnjë rilidhje nuk duhet të shfaqet në asnjë regjistër. Ky është rasti i zakonshëm për lëvizjen brenda një qyteti.

Ajo që e ndryshon adresën është një zhvendosje mes ankorimeve, një kalim nga Wi-Fi në celular, ose një rivendosje e tunelit nga ana e operatorit pas një pauze të gjatë. Këto ngjarje zëvendësojnë adresën burimore që mbartin paketat tuaja, dhe një palë VPN sheh një palë që është zhvendosur.

Pasoja praktike është se lëvizja nuk është provë. Një pajisje që ka udhëtuar dyzet kilometra mund të ketë mbajtur një adresë të vetme gjithë rrugën, dhe një pajisje që rri palëvizur mund të ketë ndryshuar adresë dy herë sepse ashtu vendosi rrjeta. Regjistrimi i ngjarjes është mënyra e vetme për t’i dalluar ato.

Dy modele: zhvendos tunelin ose rindërtoje

Klientët ndryshojnë në atë se sa u intereson që burimi i jashtëm ka ndryshuar. Disa e lidhin tunelin me adresën mbi të cilën u ndërtua dhe kërkojnë rivendosje të plotë. Të tjerë e vërtetojnë çdo paketë në mënyrë të pavarur dhe thjesht përditësojnë se ku dërgojnë përgjigjet.

MechanismBehaviour after the source changesWhat the user notices
WireGuardEndpoint updated on the next authenticated packetUsually nothing; the tunnel continues
IKEv2 with MOBIKESecurity association moves to the new addressShort pause, no re-authentication
OpenVPN over UDP with floatPeer address may change without a restartMight survive, depending on timing
Client bound to one addressSession dies and is rebuiltA visible reconnect and a new authentication

Rreshti i sipërm shpjegon shumë raporte konfuze. WireGuard nuk ka sesion për të thyer: çdo paketë mbart indeksin e palës dhe vërtetohet, kështu që një paketë e vlefshme që vjen nga një adresë e re është sipas përkufizimit nga ajo palë, dhe pika e fundit e regjistruar e ndjek atë. Një klient që shfaq “i lidhur” pa ndërprerje gjatë një udhëtimi thotë të vërtetën.

Edhe rreshti i poshtëm nuk është defekt. Rindërtimi i sesionit e ekzekuton përsëri vërtetimin ndaj adresës aktuale, që është pikërisht ajo që dëshiron kur adresa e vjetër mund t’i përkasë tani dikujt tjetër.

Vëzhgoni ngjarjen në vend të lëvizjes

Në Android nënsistemi i lidhshmërisë i raporton ndryshimet e rrjetit si ngjarje, dhe ato janë ato që duhet të ndërlidhni me sjelljen e klientit. Shkarkimi është i gjatë, por pjesët përkatëse janë rrjeta e paracaktuar dhe adresa e saj:

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

Në anën e serverit ekziston një matje e drejtpërdrejtë për rastin e roamingut. WireGuard ruan pikën e fundit të vërtetuar për çdo palë, kështu që një ndryshim adrese shfaqet si vlerë e ndryshuar dhe jo si rilidhje:

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

Krahasoni pikën e fundit para dhe pas udhëtimit. Nëse adresa dhe porta nuk kanë ndryshuar, tuneli nuk kishte nevojë të bënte asgjë dhe rilidhja erdhi nga diku tjetër, zakonisht aplikacioni. Nëse pika e fundit ndryshoi ndërsa vula kohore e shtrëngimit të duarve mbeti afër intervalit normal të rinovimit të çelësit, tuneli u zhvendos dhe nuk u rinis.

Një rinisje duket ndryshe: vula kohore e shtrëngimit të duarve rivendoset në momentin e rilidhjes, dhe klienti regjistron një sekuencë inicializimi në vend të një vazhdimësie të qetë.

Kur rilidhja është sjellja e saktë

Trajtimi i çdo rilidhjeje si defekt çon në konfigurime që i mbajnë sesionet e vdekura gjallë. Një palë adresa e së cilës ndryshoi sepse rrjeta e rialokoi nuk duhet të vazhdojë të marrë trafik për hartëzimin e vjetër, dhe një klient që vazhdon në heshtje mund të përfundojë duke dërguar në një vrimë të zezë ndërsa ikona mbetet e gjelbër.

Krahasoni dy dështimet nga këndvështrimi i përdoruesit. Një rilidhje kushton disa sekonda dhe një rivërtetim. Një tunel i vjetruar kushton një aplikacion që ngec pa gabim, gjë që është shumë më e vështirë për t’u shpjeguar dhe shumë më e mundshme të raportohet si “interneti u prish”.

Nën këtë fshihet edhe një pyetje politike. Gjatë hendekut mes humbjes së një rruge dhe vendosjes së një tjetre, disa klientë kthehen në dërgimin e trafikut drejtpërdrejt. Parandalimi i kësaj është një kontroll i veçantë nga rikuperimi automatik, dhe një klient mund të jetë i mirë në njërën dhe i dobët në tjetrën. Vendosni se çfarë ju nevojitet përpara se të rregulloni ndonjërën.

Shkruani sekuencën e vëzhguar

Një raport i dobishëm emërton burimin e ngjarjes: një ndryshim i rrjetës së paracaktuar me adresë të re, një kalim nga Wi-Fi në celular, ose një dorëzim pa asnjë ndryshim adrese. Më pas thotë çfarë bëri klienti, me vulën kohore nga ana e serverit dhe jo nga kujtesa.

Nëse tuneli u zhvendos, thuajeni dhe shënoni familjen e re të pikave fundore. Nëse u rivendos, shënoni nëse vërtetimi pati sukses në përpjekjen e parë dhe sa zgjati hendeku. Këto tre fakte e dallojnë një model celular të shëndetshëm nga një klient që lëkundet mes rrjeteve.

Dhe shmangni shprehjen “ndryshim kulle” nëse regjistri i pajisjes nuk e vërteton vërtet. Dokumentacioni i lidhshmërisë së Android përshkruan kthimet e thirrjeve që dallojnë disponueshmërinë nga një ndryshim i rrjetës së paracaktuar, dhe pikërisht ai dallim është ai që raporti juaj ka nevojë. Çdo gjë tjetër është një histori për vozitjen.

Artikuj të ngjashëm