De ce un kill switch taie traficul când schimbi serverul
De ce un kill switch blochează traficul în timpul unei schimbări de server, ce face clientul în acel interval și cum distingi o pauză normală de un blocaj blocat.
Alegi un server care pare mai aproape, apeși conectare, iar browserul nu mai încarcă înainte ca tunelul nou să fie sus. Pictograma trece într-o stare de conectare și rămâne acolo până când fiecare filă expiră. Acea pauză este de obicei kill switch-ul care lucrează conform proiectării: traficul este blocat cât timp clientul nu are un tunel prin care să-l trimită. Dacă pauza este acceptabilă depinde de ce face clientul în acele secunde și de dacă blocajul este ridicat când spune că este.
Ce face clientul între două servere
Schimbarea punctului final înseamnă mai mulți pași, nu un singur comutator. Clientul demontează tunelul curent, își actualizează regulile de blocare, rezolvă și ajunge la noul punct final în afara tunelului, apoi instalează noile rute și ridică blocajul. Golul pe care îl simți se află între primul și ultimul pas.
Ordinea contează aici mai mult decât viteza. Dacă regulile de blocare intră în vigoare înainte de excepția pentru noul punct final, clientul nu poate finaliza strângerea de mână și rămâne pe conectare până la un timeout. Dacă excepția este o copie a adresei serverului vechi, noua strângere de mână arată ca orice alt pachet de ieșire și este aruncată. Ambele cazuri arată la fel din browser, și de aceea o schimbare care se recuperează după șase secunde și una care nu se recuperează niciodată pot avea aceeași cauză.
Noul punct final are nevoie de o gaură în blocaj
Pentru a construi tunelul, clientul trebuie să trimită pachete la adresa și portul noului server prin interfața fizică, de exemplu UDP 51820 pentru un profil WireGuard tipic sau 1194 și 443 pentru OpenVPN, orice ar specifica propriul profil. Acel trafic nu este în interiorul tunelului care urmează să fie creat, așa că un blocaj pentru întregul dispozitiv îl înghite, dacă nu există o regulă de permisiune potrivită.
Profilurile bazate pe nume de gazdă adaugă o a doua cerință: căutarea în sine. Dacă clientul rezolvă punctul final înainte ca blocajul să se ridice, poate folosi o adresă din cache, dar când profilul rotește adresele sau intrarea din cache devine veche, strângerea de mână merge spre o adresă pe care regula de permisiune nu o acoperă. IPv6 face acest lucru vizibil, pentru că un punct final cu stivă dublă poate publica atât o înregistrare A, cât și una AAAA, iar o regulă de permisiune care acoperă doar adresa v4 lasă clientul să reîncerce împotriva unei adrese v6 blocate.
Numele opțiunilor și valorile implicite diferă în funcție de client și versiune, așa că citește lista documentată pentru al tău în loc să ghicești din capturi de ecran. Referința de setări OpenVPN Connect de la openvpn.net/connect-docs/app-settings-windows este un exemplu de felul în care un client își descrie opțiunile de blocare și de tunel divizat.
Fail-closed este o mașină de stări, nu un comutator
Majoritatea clienților exprimă blocajul ca politică de firewall în trei stări: tunel sus, cu traficul trecând prin tunel și fără blocaj; tunel jos, cu blocajul activ; și tranziție, cu blocajul activ plus excepții temporare pentru punctul final. Exact în a treia stare trăiesc erorile, pentru că trebuie să se schimbe de două ori în câteva secunde, iar neputința de a ieși din ea arată exact ca un blocaj permanent.
Mecanismul diferă în funcție de platformă, și eșecul la fel. Filtrele Windows Filtering Platform au ponderi, așa că un filtru de blocare care îți depășește permisiunea continuă să arunce pachete chiar dacă permisiunea există, iar filtrele lăsate în urmă de un proces de client omorât pot ține mașina offline după ce aplicația a dispărut. Clienții macOS scriu de obicei reguli pf într-un anchor, unde ordinea regulilor și deciziile rapide stabilesc care regulă se aplică. Clienții Linux gestionează de obicei un lanț nftables sau iptables cu politică drop și permisiuni explicite pentru punctul final, interfața tunelului și loopback. VPN-ul mereu activ din Android cu opțiunea de a bloca conexiunile fără VPN este cel mai strict din grup, pentru că sistemul de operare aplică blocajul pentru întregul dispozitiv, nu pentru fiecare aplicație.
WireGuard merită o notă proprie, pentru că AllowedIPs este un selector de rutare, nu un blocant. El decide ce destinații intră în tunel; nu face nimic pentru a împiedica un pachet fără tunel să iasă prin Wi-Fi. Într-o configurație doar cu WireGuard și fără regulă de firewall, kill switch-ul este de fapt absența unei rute, iar după o strângere de mână aruncată poate ieși un pachet real prin interfața fizică.
Măsoară golul în loc să te uiți la pictogramă
Urmărește pachetele, nu becul de stare. Pe Linux pornește un ping lent către o adresă publică într-un terminal și capturează portul de transport al tunelului pe interfața fizică în altul:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Schimbă serverul în client în timp ce ambele rulează. Trei lucruri contează: cât timp se opresc ping-urile, dacă captura arată strângerea de mână ajungând la noul punct final și dacă traficul revine înainte sau după ce starea clientului trece în conectat. Dacă golul din ping se termină primul, fie blocajul a fost ridicat prea devreme, fie tunelul este sus înainte ca indicatorul să recunoască. Dacă golul se termină mai târziu, indicatorul este prea optimist.
Pe Windows, netsh wfp show state scrie o instantanee în care poți căuta filtre de blocare încă prezente în timp ce clientul susține că este deconectat. Pe macOS, sudo pfctl -sr listează regulile încărcate și ordinea lor. Asociază oricare instantanee cu logul propriu al clientului; cronologia din pingul tău îți spune dacă blocajul s-a terminat târziu sau niciodată.
Întuneric normal versus blocaj blocat
O parte din întrerupere este chiar scopul funcției, așa că fă triaj înainte de a schimba orice setare:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Dacă ajungi în al doilea sau al cincilea rând, nu dezactiva kill switch-ul pentru test, pentru că asta transformă o eroare de rutare într-o scurgere. Repornește serviciul clientului, sau repornește mașina acolo unde filtrele supraviețuiesc omorârii unui proces, apoi vezi dacă blocajul se curăță. Dacă se curăță, vina este în curățarea din timpul schimbării, nu în blocajul în sine.
Înainte de următoarea schimbare, confirmă patru lucruri: permisiunea pentru punctul final acoperă fiecare familie de adrese pe care o rezolvă profilul tău, logul clientului arată tranziția finalizată, testul tău de ping măsoară golul și nu pictograma, iar închiderea clientului readuce conectivitatea normală. Un kill switch care ține în timpul schimbării și eliberează după aceea își face treaba. Unul care eliberează devreme, sau niciodată, merită depanat.