VPN-ul se reconectează în timpul condusului: schimbare de radio sau de IP?

Apelul cade când treci pe lângă marginea orașului, iar pictograma VPN dispare în același moment. E tentant să notezi asta ca „schimbarea de turn a omorât tunelul”. S-au întâmplat două lucruri diferite, și doar unul dintre ele ține de turnuri. Un transfer radio poate lăsa adresa IP, ruta implicită și sesiunea complet intacte, în timp ce o schimbare reală de adresă va rupe orice tunel care nu se poate muta odată cu ea. Exercițiul util este să compari cum tratează clienții al doilea caz, pentru că îți spune dacă vezi un comportament proiectat sau un defect.

O schimbare de turn nu este neapărat o schimbare de adresă

Rețelele mobile mențin sesiunea de pachete în viață pe parcursul transferurilor atât timp cât ancora de mobilitate a operatorului rămâne aceeași. Legătura radio se schimbă, tunelul nu observă și nicio reconectare nu ar trebui să apară în vreun jurnal. Acesta este cazul obișnuit pentru deplasarea în interiorul unui oraș.

Ceea ce schimbă adresa este o mutare între ancore, o trecere de la Wi-Fi la celular sau o restabilire a tunelului de partea operatorului după o pauză lungă. Acele evenimente înlocuiesc adresa sursă pe care o poartă pachetele tale, iar un partener VPN vede un partener care s-a mutat.

Consecința practică este că deplasarea nu este o dovadă. Un dispozitiv care a parcurs patruzeci de kilometri poate să fi păstrat o singură adresă tot drumul, iar un dispozitiv nemișcat poate să fi schimbat adresa de două ori pentru că așa a decis rețeaua. Înregistrarea evenimentului este singura cale de a le distinge.

Două proiecte: mută tunelul sau reconstruiește-l

Clienții diferă prin cât de mult le pasă că sursa exterioară s-a schimbat. Unii leagă tunelul de adresa pe care a fost construit și cer o restabilire completă. Alții autentifică fiecare pachet independent și doar actualizează unde trimit răspunsurile.

Rândul de sus explică multe rapoarte confuze. WireGuard nu are nicio sesiune de rupt: fiecare pachet poartă indexul partenerului și este autentificat, așa că un pachet valid care sosește de la o adresă nouă este prin definiție de la acel partener, iar punctul final înregistrat îl urmează. Un client care arată „conectat” continuu pe parcursul unui drum spune adevărul.

Nici rândul de jos nu este un defect. Reconstruirea sesiunii rulează din nou autentificarea față de adresa curentă, ceea ce este exact ce vrei când adresa veche poate aparține acum altcuiva.

Observați evenimentul în locul deplasării

Pe Android, subsistemul de conectivitate raportează schimbările de rețea ca evenimente, iar pe acelea ar trebui să le corelezi cu comportamentul clientului. Descărcarea este voluminoasă, dar părțile relevante sunt rețeaua implicită și adresa ei:

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

Pe partea de server există o măsurătoare directă pentru cazul de roaming. WireGuard păstrează ultimul punct final autentificat pentru fiecare partener, așa că o schimbare de adresă apare ca o valoare modificată, nu ca o reconectare:

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

Comparați punctul final înainte și după drum. Dacă adresa și portul sunt neschimbate, tunelul nu a trebuit să facă nimic, iar reconectarea a venit de altundeva, de obicei de la aplicație. Dacă punctul final s-a schimbat în timp ce marcajul de timp al strângerii de mână a rămas aproape de intervalul normal de reînnoire a cheii, tunelul s-a mutat în loc să repornească.

O repornire arată altfel: marcajul de timp al strângerii de mână se resetează la momentul reconectării, iar clientul înregistrează o secvență de inițializare în loc de o continuare tăcută.

Când reconectarea este comportamentul corect

Tratarea fiecărei reconectări ca o defecțiune duce la configurații care țin sesiunile moarte în viață. Un partener a cărui adresă s-a schimbat pentru că rețeaua a realocat-o nu ar trebui să continue să primească trafic pentru maparea veche, iar un client care continuă în tăcere poate ajunge să trimită într-o gaură neagră în timp ce pictograma rămâne verde.

Comparați cele două defecțiuni din perspectiva utilizatorului. O reconectare costă câteva secunde și o reautentificare. Un tunel învechit costă o aplicație care se blochează fără eroare, ceea ce este mult mai greu de explicat și mult mai probabil să fie raportat ca „internetul e stricat”.

Sub asta se ascunde și o întrebare de politică. În intervalul dintre pierderea unei căi și stabilirea alteia, unii clienți revin la trimiterea traficului direct. Prevenirea acestui lucru este un control separat de recuperarea automată, iar un client poate fi bun la unul și slab la celălalt. Decide de ce ai nevoie înainte de a regla vreunul.

Notați secvența observată

Un raport util numește sursa evenimentului: o schimbare a rețelei implicite cu o adresă nouă, o trecere de la Wi-Fi la celular sau un transfer fără nicio schimbare de adresă. Apoi spune ce a făcut clientul, cu marcajul de timp de pe partea serverului în loc de memorie.

Dacă tunelul s-a mutat, spuneți-o și notați noua familie de puncte finale. Dacă a fost restabilit, notați dacă autentificarea a reușit la prima încercare și cât a durat intervalul. Aceste trei fapte disting un proiect mobil sănătos de un client care se zbate între rețele.

Și evitați expresia „schimbare de turn” dacă jurnalul dispozitivului nu o stabilește cu adevărat. Documentația Android despre conectivitate descrie apelurile inverse care disting disponibilitatea de o schimbare a rețelei implicite, iar acea distincție este cea de care are nevoie raportul tău. Tot restul este o poveste despre condus.