Kill switch u programu nasuprot kill switchu na firewallu: šta koji blokira

Kill switch na popisu funkcija ne kaže 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 samo pokušava ponovo da se poveže. Razlika se vidi u sekundama posle kvara, ne na ekranu podešavanja. Prođite ove provere redom i zaustavite se na prvoj na koju ne možete iskreno da odgovorite, jer tu vaša stvarna pokrivenost prestaje.

Prvo imenujte mehanizam sprovođenja

Prekid procesa je funkcija životnog ciklusa programa. Pronalazi odabrane programe posle otkrivenog kvara tunela i zatvara ih. Sve što nije glavni proces preživljava: pomoćne usluge, pozadinska sinhronizacija i svaka aplikacija pokrenuta sekund kasnije imaju sopstveni životni ciklus i sopstveno vreme.

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

Da li blokada nadživljava 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 ostaje posle pada. Pravilo instalirano u skladište platforme može da se ponaša obrnuto: da preživi i klijenta i, povremeno, deinstalaciju.

Zatvorite klijent usred dugog preuzimanja i gledajte da li se prenos 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. Isključene aplikacije i izuzeci za lokalnu mrežu su treći.

Na Windowsu možete čitati instalirana pravila umesto da verujete 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 poređenje sva tri je poenta.

DNS je uobičajeno curenje

Blokiranje TCP-a dok UDP 53 ostaje otvoren daje vam vrlo ubedljiv kill switch koji još uvek 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, razrešite jedno poznato ime i pogledajte da li se odgovor vraća. Ako se vraća, saobraćaj nije potpuno blokiran, šta god ikona statusa govorila.

Testirajte prelaz, ne prekidač

Isključivanje VPN-a iz njegovog menija je uredno zatvaranje, a uredan slučaj svaka implementacija dobro rešava. Prelaz koji je važan je grub: ubijte proces tunela, izvucite mrežu, pustite server da prestane da odgovara. Zatim pokrenite zahtev i gledajte da li ne uspeva ili tiho koristi fizičku vezu.

Rezultat sa jednog laptopa ne prenosi se na telefon ili ruter. Različiti API-ji platforme, različite podrazumevane vrednosti, a na Androidu je razlika oštra: always-on sa blokiranjem sprovodi sistem, a ne klijent, pa radi i kada klijent ne radi. Android VPN smernice opisuju tu podelu.

Sačuvajte put nazad

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

Ako ne možete da odgovorite na provere pada, IPv6, DNS-a i prelaza za svoj klijent, tretirajte ga kao prekidač na nivou aplikacije sa poznatim rupama i planirajte u skladu s tim.