Always-on VPN sau kill switch: ce ai activat de fapt?

Always-on și kill switch stau la două rânduri distanță pe același ecran de setări, așa că oamenii le citesc ca două nume pentru o singură funcție. Nu sunt. Always-on este o politică de reconectare: pornește tunelul la boot, readu-l după un crash sau o schimbare de rețea și tot încearcă atât timp cât eșuează. Kill switch-ul este o politică de trafic: numește pachetele care mai pot ieși din mașină cât timp tunelul e jos. Poți activa primul fără al doilea, iar pe majoritatea platformelor rezultatul implicit lasă totuși trafic să iasă în acel interval.

Verificarea 1: blocarea este un comutator propriu?

Pe Android 10 și versiunile mai noi, un profil VPN salvat deschide două comutatoare independente în spatele pictogramei de angrenaj: Always-on VPN și Block connections without VPN. Doar al doilea este kill switch. Cu doar always-on, tunelul chiar revine după o cădere, iar orice aplicație aflată la mijlocul unei cereri poate ajunge la rețea prin Wi-Fi sau date mobile până când se întâmplă asta.

Dispozitivele administrate păstrează aceeași separare în API-ul de politici. setAlwaysOnVpnPackage() primește numele pachetului și un flag lockdownEnabled; un administrator care setează pachetul și lasă flagul pe false a construit un tunel persistent, nu un dispozitiv închis. Formularea din consolă rareori face diferența vizibilă.

Citește starea de pe dispozitiv, nu din consolă: adb shell settings get global always_on_vpn_app și adb shell settings get global always_on_vpn_lockdown. Dacă primul returnează null, niciun pachet nu este impus la nivel de platformă; dacă al doilea returnează 0, platforma nu blochează nimic. Ghidul VPN pentru Android le descrie ca capacități separate, nu ca un singur mod.

Verificarea 2: ce strat deține blocarea?

Etichetele stau în client, iar blocările de obicei în firewall, de aceea același cuvânt înseamnă altceva pe fiecare platformă. Rândurile de mai jos sunt cele care merită confirmate înainte să te bazezi pe vreuna dintre ele.

Windows este cel mai clar exemplu de etichetă care nu blochează. Acolo Always On descrie persistența tunelului: un tunel de dispozitiv pentru autentificarea mașinii și un tunel de utilizator pentru contul conectat, configurate prin XML de profil sau Add-VpnConnection. Nimic din acel profil nu oprește un pachet de ieșire când tunelul lipsește, iar filtrarea de ieșire nu e activă implicit, așa că un laptop pe Wi-Fi funcționează în continuare cât timp VPN-ul e jos.

WireGuard se împarte la fel, dar pe client. WireGuard for Windows are opțiunea Block untunneled traffic pentru fiecare tunel, care instalează reguli de filtrare; uneltele Linux nu au un comutator echivalent. wg-quick adaugă o rută pentru fiecare intrare AllowedIPs plus o regulă fwmark, iar wg-quick down le elimină pe amândouă, așa că ruta implicită fizică preia din nou controlul fără ca vreun pachet să se piardă.

Pe platformele Apple, always-on vine ca funcție de profil de administrare pentru dispozitive supravegheate și se exprimă prin reguli on-demand, nu printr-o casetă de bifare. Întrebarea la care trebuie răspuns din payload este dacă un tunel eșuat refuză traficul sau doar cere o altă conexiune. Titlul meniului nu-ți va spune.

Verificarea 3: măsoară golul, nu pictograma

Patru tranziții contează și fiecare eșuează altfel: bootul înainte ca cineva să se conecteze, sleep și revenire, trecerea de la Wi-Fi la date mobile și un crash al clientului care lasă interfața tunelului pe jumătate configurată. O reconectare curată pe una dintre ele nu dovedește nimic despre celelalte trei.

Cel mai ieftin test oprește intenționat tunelul și apoi încearcă să iasă. Cu tunelul jos, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com care returnează 200 înseamnă că politica este fail-open; un timeout sau o conexiune refuzată înseamnă că ceva încă blochează. ip route get 1.1.1.1 numește interfața care ar duce pachetul, ceea ce de obicei spune mai mult decât pictograma din tray, iar systemctl status wg-quick@wg0 arată dacă interfața a fost eliminată curat.

Rulează aceeași verificare într-o a doua fereastră în timp ce rețeaua se schimbă, nu doar după ce se așază. Intervalul dintre cădere și noua încercare este partea care contează, iar rezolvarea numelor este cel mai rapid mod de a observa că traficul a scăpat: dacă resolverul local răspunde cu tunelul jos, blocarea nu este completă.

Verificarea 4: decide excepțiile înainte să blochezi

Două excepții sunt structurale. Clientul trebuie să ajungă la serverul VPN însuși, așa că un set de reguli care aruncă tot împiedică și reconectarea care ar readuce protecția. Nici un portal captive nu poate fi atins printr-un tunel care nu e ridicat, așa că un dispozitiv blocat pe Wi-Fi de hotel are nevoie de o modalitate documentată de a deschide portalul, nu de una improvizată.

O formă minimă, endpointul permis și restul aruncat:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Tratează acel rând al endpointului ca variabilă, nu ca constantă. Furnizorii rotesc adrese, iar o excepție învechită este motivul obișnuit pentru care un kill switch funcțional devine un dispozitiv care nu se mai reconectează. Imprimantele locale, partajările NAS și serviciile de dezvoltare fac parte din aceeași listă scrisă, altfel sunt descoperite câte un tichet de suport.

Verificarea 5: notează ce ai dovedit de fapt

Ține un tabel cu patru coloane și completează-l testând: stare, comportament așteptat, comportament observat, dovadă. Rândurile sunt tranzițiile din verificarea 3 plus o defecțiune deliberată. Un rând pe care nu-l poți completa cu ieșirea unei comenzi este un rând netestat, iar un dispozitiv care trece rândul reconectării și eșuează la rândul bootului este destul de comun încât să merite cele zece minute în plus.

Înainte să declari gata:

• Confirmă că setarea de blocare este separată de cea de reconectare și citește-i valoarea pe dispozitiv.
• Află ce strat aplică blocarea - opțiunea clientului, politica dispozitivului sau firewall-ul - și unde este configurat acel strat.
• Păstrează o comandă de verificare care dovedește blocarea și rulează-o în timpul unei tranziții, nu după.
• Scrie lista excepțiilor, cu endpointul inclus, și notează cine o actualizează.
• Pe hardware administrat, lasă politica impusă în pace; scoaterea blocării schimbă cerința în loc să repare tunelul.