Kill switch v aplikaci versus kill switch ve firewallu: co každý blokuje

Kill switch v seznamu funkcí vám neřekne téměř nic o tom, co se stane, když tunel spadne. Jedna implementace zavírá vybrané procesy, druhá instaluje filtry paketů na hranici operačního systému a třetí se prostě snaží znovu připojit. Rozdíl se ukáže v sekundách po selhání, ne na obrazovce nastavení. Projděte tyto kontroly popořadě a zastavte se u první, na kterou nedokážete poctivě odpovědět, protože tam vaše skutečné pokrytí končí.

Nejprve pojmenujte donucovací mechanismus

Ukončování procesů je funkce životního cyklu aplikace. Najde vybrané programy po zjištěném selhání tunelu a zavře je. Všechno, co není hlavní proces, přežívá: pomocné služby, synchronizace na pozadí a každá aplikace spuštěná o sekundu později mají vlastní životní cyklus a vlastní časování.

Filtrování paketů je funkce operačního systému. Odmítá provoz, který nejde povolenou cestou, což je silnější slib, ale jen v rozsahu, který pravidlo skutečně pokrývá. Rozhoduje rodina adres, rozhraní, vyloučené aplikace a výjimky, ne označení v klientovi.

Přežije blokace klienta?

Položte si čtyři otázky v tomto pořadí: co se stane při pádu, při ručním ukončení, při odhlášení a při restartu. Pravidlo, které udržuje sám klient, se obvykle odstraní při řádném vypnutí a často zůstane po pádu. Pravidlo nainstalované do úložiště platformy se může chovat opačně: přežít klienta a občas i odinstalaci.

Ukončete klienta uprostřed dlouhého stahování a sledujte, zda se přenos zastaví, nebo pokračuje.

Hledejte standardní díry

IPv6 je první. Pravidlo napsané pro adresy IPv4 nechává provoz IPv6 nedotčený a mnoho klientů píše jen polovinu v4. Druhé je rozhraní: USB tethering, druhý Wi-Fi adaptér a mobilní modem nemusí být zahrnuty v pravidle omezeném na primární připojení. Vyloučené aplikace a výjimky pro místní síť jsou třetí.

Ve Windows můžete číst nainstalovaná pravidla místo spoléhání na přepínač: Get-NetFirewallRule -DisplayName '*VPN*' a netsh wfp show filters ukazují, co existuje. V Linuxu iptables -S, ip6tables -S a nft list ruleset pokrývají běžné případy a porovnání všech tří je pointa.

DNS je obvyklý únik

Blokování TCP při otevřeném UDP 53 vám dá velmi přesvědčivý kill switch, který stále odpovídá na každý dotaz na název hostitele. Totéž platí, když se DNS předá resolveru na jiném rozhraní, nebo když klient blokuje jen v4 a resolver je dostupný přes v6.

Se spadlým tunelem přeložte jedno známé jméno a podívejte se, zda se vrátí odpověď. Pokud ano, provoz není plně blokován, ať ikona stavu říká cokoli.

Testujte přechod, ne přepínač

Vypnutí VPN z jeho vlastní nabídky je řádné ukončení a řádný případ každá implementace zvládá dobře. Přechod, na kterém záleží, je ten hrubý: zabijte proces tunelu, vytáhněte síť, nechte server přestat odpovídat. Pak spusťte požadavek a sledujte, zda selže, nebo tiše použije fyzické spojení.

Výsledek z jednoho notebooku se nepřenáší na telefon ani router. Jiná API platforem, jiné výchozí hodnoty a na Androidu je rozdíl ostrý: always-on s blokováním vynucuje systém, ne klient, takže funguje dál, když klient ne. Průvodce VPN pro Android popisuje toto rozdělení.

Nechte si cestu zpět

Blokování na úrovni systému má opačný režim selhání. Filtry, které přežijí klienta, mohou po odinstalaci nechat stroj úplně bez sítě, což je hovor na podporu bez zřejmé příčiny. Než zapnete jakýkoli kill switch, který zapisuje pravidla platformy, poznamenejte si, jak se odstraňuje, a mějte cestu k opravě od dodavatele tam, kde ji najdete.

Pokud pro svého klienta nedokážete odpovědět na kontroly pádu, IPv6, DNS a přechodu, berte ho jako přepínač na úrovni aplikace se známými děrami a plánujte podle toho.