Kill switch u aplikaciji nasuprot kill switchu na vatrozidu: što svaki blokira

Kill switch na popisu značajki ne govori gotovo ništa o tome što se događa kada tunel padne. Jedna implementacija zatvara odabrane procese, druga instalira filtre paketa na granici operacijskog sustava, a treća jednostavno pokušava ponovno se spojiti. Razlika se vidi u sekundama nakon kvara, ne na zaslonu postavki. Prođite ove provjere redom i zaustavite se na prvoj na koju ne možete iskreno odgovoriti, jer tu vaša stvarna pokrivenost prestaje.

Prvo imenujte mehanizam provedbe

Prekid procesa značajka je životnog ciklusa aplikacije. Pronalazi odabrane programe nakon otkrivenog kvara tunela i zatvara ih. Sve što nije glavni proces preživljava: pomoćne usluge, pozadinska sinkronizacija i svaka aplikacija pokrenuta sekundu kasnije imaju vlastiti životni ciklus i vlastito vrijeme.

Filtriranje paketa značajka je operacijskog sustava. Odbija promet koji ne slijedi dopuštenu putanju, što je jače obećanje, ali samo u okviru onoga što pravilo doista pokriva. Obitelj adresa, sučelje, isključene aplikacije i iznimke odlučuju o tome, a ne oznaka u klijentu.

Preživljava li blokada klijenta?

Postavite četiri pitanja ovim redom: što se događa pri padu, pri ručnom izlasku, pri odjavi i pri ponovnom pokretanju. Pravilo koje održava sam klijent obično se uklanja tijekom urednog zatvaranja i često ostane nakon pada. Pravilo instalirano u spremište platforme može se ponašati obrnuto: preživjeti i klijenta i, povremeno, deinstalaciju.

Zatvorite klijent usred dugog preuzimanja i gledajte zaustavlja li se prijenos ili nastavlja.

Potražite uobičajene rupe

IPv6 je prva. Pravilo napisano za IPv4 adrese ostavlja IPv6 promet netaknutim, a mnogi klijenti pišu samo v4 polovicu. Druga je sučelje: USB tethering, drugi Wi-Fi adapter i mobilni modem možda nisu uključeni u pravilo ograničeno na primarnu vezu. Isključene aplikacije i iznimke za lokalnu mrežu su treće.

Na Windowsu možete čitati instalirana pravila umjesto vjerovati prekidaču: Get-NetFirewallRule -DisplayName '*VPN*' i netsh wfp show filters pokazuju što postoji. Na Linuxu iptables -S, ip6tables -S i nft list ruleset pokrivaju uobičajene slučajeve, a usporedba sva tri je poanta.

DNS je uobičajeno curenje

Blokiranje TCP-a dok UDP 53 ostaje otvoren daje vam vrlo uvjerljiv kill switch koji još uvijek odgovara na svaki upit za ime hosta. Isto vrijedi kada se DNS preda razrješivaču na drugom sučelju ili kada klijent blokira samo v4, a razrješivač je dostupan preko v6.

Sa spuštenim tunelom razriješite jedno poznato ime i pogledajte vraća li se odgovor. Ako se vraća, promet nije potpuno blokiran, što god ikona stanja govorila.

Testirajte prijelaz, ne prekidač

Isključivanje VPN-a iz njegova izbornika uredno je zatvaranje, a uredan slučaj svaka implementacija dobro rješava. Prijelaz koji je važan je grub: ubijte proces tunela, izvucite mrežu, pustite poslužitelj da prestane odgovarati. Zatim pokrenite zahtjev i gledajte ne uspijeva li ili tiho koristi fizičku vezu.

Rezultat s jednog prijenosnika ne prenosi se na telefon ili usmjerivač. Različiti API-ji platforme, različite zadane vrijednosti, a na Androidu je razlika oštra: always-on s blokiranjem provodi sustav, a ne klijent, pa radi i kada klijent ne radi. Androidove VPN smjernice opisuju tu podjelu.

Sačuvajte put natrag

Blokiranje na razini sustava ima suprotan način kvara. Filtri koji prežive klijenta mogu ostaviti računalo potpuno bez mreže nakon deinstalacije, što je poziv podršci bez očitog uzroka. Prije uključivanja bilo kojeg kill switcha koji piše pravila platforme, zabilježite kako se uklanja i držite put popravka dobavljača tamo gdje ga možete naći.

Ako ne možete odgovoriti na provjere pada, IPv6, DNS-a i prijelaza za svoj klijent, tretirajte ga kao prekidač na razini aplikacije s poznatim rupama i planirajte u skladu s tim.