Kill switch u aplikaciji nasuprot kill switchu na firewallu: šta svaki blokira

Kill switch na listi funkcija ne govori gotovo ništa o tome šta se dešava kada tunel padne. Jedna implementacija zatvara odabrane procese, druga instalira filtere paketa na granici operativnog sistema, a treća jednostavno pokušava ponovo se spojiti. Razlika se vidi u sekundama nakon kvara, ne na ekranu postavki. Prođite ove provjere po redu i zaustavite se na prvoj na koju ne možete iskreno odgovoriti, jer tu vaša stvarna pokrivenost prestaje.

Prvo imenujte mehanizam provođenja

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

Filtriranje paketa je funkcija operativnog sistema. Odbija saobraćaj koji ne slijedi dozvoljenu putanju, što je jače obećanje, ali samo u okviru onoga što pravilo zaista pokriva. Porodica adresa, interfejs, izuzete aplikacije i izuzeci odlučuju o tome, a ne oznaka u klijentu.

Preživljava li blokada klijenta?

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

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

Potražite standardne rupe

IPv6 je prva. Pravilo napisano za IPv4 adrese ostavlja IPv6 saobraćaj netaknutim, a mnogi klijenti pišu samo v4 polovinu. Druga je interfejs: USB tethering, drugi Wi-Fi adapter i mobilni modem možda nisu uključeni u pravilo ograničeno na primarnu vezu. Izuzete aplikacije i izuzeci za lokalnu mrežu su treći.

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

DNS je uobičajeno curenje

Blokiranje TCP-a dok UDP 53 ostaje otvoren daje vam vrlo uvjerljiv kill switch koji još odgovara na svaki upit za ime hosta. Isto važi kada se DNS preda resolveru na drugom interfejsu ili kada klijent blokira samo v4, a resolver je dostupan preko v6.

Sa spuštenim tunelom, razriješite jedno poznato ime i pogledajte vraća li se odgovor. Ako se vraća, saobraćaj nije potpuno blokiran, ma šta ikona statusa govorila.

Testirajte tranziciju, ne prekidač

Isključivanje VPN-a iz njegovog menija je uredno zatvaranje, a uredan slučaj svaka implementacija dobro rješava. Tranzicija koja je važna je gruba: ubijte proces tunela, izvucite mrežu, pustite server da prestane odgovarati. Zatim pokrenite zahtjev i gledajte da li ne uspijeva ili tiho koristi fizičku vezu.

Rezultat s jednog laptopa ne prenosi se na telefon ili ruter. Različiti API-ji platformi, različiti defaulti, a na Androidu je razlika oštra: always-on sa blokiranjem umjesto klijenta provodi sistem, pa radi i kada klijent ne radi. Android VPN smjernice opisuju tu podjelu.

Sačuvajte put natrag

Blokiranje na nivou sistema ima suprotan način kvara. Filteri koji prežive klijenta mogu ostaviti mašinu potpuno bez mreže nakon deinstalacije, što je poziv podršci bez očiglednog uzroka. Prije uključivanja bilo kojeg kill switcha koji piše pravila platforme, zabilježite kako se uklanja, i držite put popravke od dobavljača tamo gdje ga možete naći.

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