Kill switch de aplicație versus kill switch de firewall: ce blochează fiecare

Un kill switch într-o listă de funcții nu spune aproape nimic despre ce se întâmplă când tunelul cade. O implementare închide procese selectate, alta instalează filtre de pachete la granița sistemului de operare, iar a treia doar încearcă să se reconecteze. Diferența apare în secundele de după o defecțiune, nu pe ecranul de setări. Parcurgeți aceste verificări în ordine și opriți-vă la prima la care nu puteți răspunde sincer, pentru că acolo se termină acoperirea reală.

Numiți mai întâi mecanismul de aplicare

Terminarea proceselor este o funcție a ciclului de viață al aplicației. Găsește programele selectate după o defecțiune de tunel detectată și le închide. Tot ce nu este procesul principal supraviețuiește: servicii auxiliare, sincronizare în fundal și orice aplicație pornită o secundă mai târziu au propriul ciclu de viață și propriul moment.

Filtrarea pachetelor este o funcție a sistemului de operare. Refuză traficul care nu urmează calea permisă, ceea ce este o promisiune mai puternică, dar numai în măsura în care regula se potrivește cu adevărat. Familia de adrese, interfața, aplicațiile excluse și excepțiile decid asta, nu eticheta din client.

Blocarea supraviețuiește clientului?

Puneți patru întrebări în această ordine: ce se întâmplă la o cădere, la o ieșire manuală, la deconectare și la repornire. O regulă întreținută de clientul însuși este de obicei eliminată la o închidere ordonată și adesea rămâne după o cădere. O regulă instalată în depozitul platformei se poate comporta invers: supraviețuiește atât clientului, cât și uneori dezinstalării.

Închideți clientul la mijlocul unei descărcări lungi și urmăriți dacă transferul se oprește sau continuă.

Căutați găurile standard

IPv6 este prima. O regulă scrisă pentru adrese IPv4 lasă traficul IPv6 neatins, iar mulți clienți scriu doar jumătatea v4. A doua este interfața: tetheringul USB, un al doilea adaptor Wi-Fi și un modem celular pot să nu fie incluse într-o regulă limitată la conexiunea principală. Aplicații excluse și excepțiile pentru rețeaua locală sunt a treia.

Pe Windows puteți citi regulile instalate în loc să aveți încredere în comutator: Get-NetFirewallRule -DisplayName '*VPN*' și netsh wfp show filters arată ambele ce există. Pe Linux, iptables -S, ip6tables -S și nft list ruleset acoperă cazurile obișnuite, iar compararea tuturor trei este esențialul.

DNS este scurgerea obișnuită

Blocarea TCP în timp ce UDP 53 rămâne deschis vă oferă un kill switch foarte convingător care încă răspunde la fiecare interogare de nume de gazdă. Același lucru este valabil când DNS este predat unui resolver de pe altă interfață sau când clientul blochează doar v4 și resolverul este accesibil prin v6.

Cu tunelul căzut, rezolvați un nume cunoscut și vedeți dacă vine un răspuns. Dacă vine, traficul nu este complet blocat, orice ar spune pictograma de stare.

Testați tranziția, nu comutatorul

Oprirea VPN-ului din propriul meniu este o închidere ordonată, iar cazul ordonat este cel pe care fiecare implementare îl tratează bine. Tranziția care contează este cea brutală: ucideți procesul tunelului, scoateți rețeaua, lăsați serverul să nu mai răspundă. Apoi porniți o cerere și urmăriți dacă eșuează sau folosește în tăcere legătura fizică.

Rezultatul de pe un laptop nu se transferă pe un telefon sau un router. API-uri de platformă diferite, valori implicite diferite, iar pe Android diferența este izbitoare: always-on cu blocare este impus de sistem, nu de client, așa că funcționează în continuare când clientul nu o face. Ghidul VPN pentru Android descrie această separare.

Păstrați o cale de întoarcere

Blocarea la nivel de sistem are modul de eșec opus. Filtrele care supraviețuiesc clientului pot lăsa o mașină fără nicio rețea după o dezinstalare, ceea ce este un apel la suport fără cauză evidentă. Înainte de a activa orice kill switch care scrie reguli de platformă, notați cum este eliminat și păstrați calea de reparare a furnizorului unde o puteți găsi.

Dacă nu puteți răspunde verificărilor de cădere, IPv6, DNS și tranziție pentru clientul dvs., tratați-l ca pe un comutator la nivel de aplicație cu găuri cunoscute și planificați în consecință.