Přežije nouzový vypínač VPN restart? Jak to ověřit

Restart je nejběžnější způsob, jak lidé testují nouzový vypínač, a je to test, který nejčastěji lže. Zaškrtávací políčko v klientovi je jen předvolba; rozhodující je, zda něco vynucuje blok mezi okamžikem, kdy se zvedne síťový stack, a okamžikem, kdy je tunel skutečně navázán. Ve Windows je tím obvykle filtr ve Windows Filtering Platform, v Linuxu sada pravidel načtená unitem, v macOS kotva pf, v Androidu vlastní příznaky systému pro always-on a uzamčení. Tato uspořádání se při restartu chovají velmi odlišně a jen ta na úrovni platformy jsou na místě dřív, než se kdokoli může přihlásit.

Restart klade tři oddělené otázky

Rozdělte otázku. Zaprvé, existuje zásada na disku ve formě, kterou při startu něco čte? Zadruhé, běží tento čtenář dřív, než může odejít jakýkoli provoz? Zatřetí, pokrývá zásada provoz, na kterém vám záleží, tedy každý proces, obě rodiny adres a DNS. Ano na první a ne na druhou dává přesně tu poruchu, kterou lidé hlásí jako nouzový vypínač, který restart nepřežije: provoz při startu na několik sekund unikne a nikdo si toho nevšimne, dokud se někdo nepodívá.

Držte vrstvy oddělené. Uložená sada pravidel firewallu, služba, která startuje při bootu, a předvolba klienta jsou tři různé objekty se třemi různými životy. Předvolba přežívá restarty, protože je to hodnota v konfiguračním souboru. Pravidla jsou jediné, co blokuje pakety, a mizí spolu s jádrem, které je drželo.

Najděte objekt, který blok obnovuje

V Linuxu žijí pravidla netfilteru v jádře. Nic je při startu nezapisuje zpět, pokud jste to nezařídili: iptables-save plus netfilter-persistent, nftables.service načítá /etc/nftables.conf, nebo systemd unit, který spouští váš vlastní skript. Zkontrolujte, co je povoleno, místo toho, co si pamatujete, že jste nastavili.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Prázdná sada pravidel pár sekund po startu je odpovědí na otázku v titulku. Ve Windows se zeptejte služby klienta, jak startuje, a pak vyexportujte stav filtru platformy, zatímco je tunel dole.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Druhý příkaz zapisuje wfpstate.xml do aktuálního adresáře. Hledejte filtry s akcí blokování, které už existují před připojením klienta. Base Filtering Engine startuje brzy při bootu a obnovuje filtry přidané s trvalým příznakem, proto některé nouzové vypínače blokují provoz dřív, než existuje jakékoli okno klienta, a jiné ne. V macOS sudo pfctl -s info hlásí, zda je pf povolen, sudo pfctl -s rules ukazuje, co je načteno, a VPN klienti obvykle připojují svá pravidla ke kotvě místo k hlavní sadě. Pravidlo, které jmenuje utun3 může po dalším startu ukazovat na jiné rozhraní, protože to číslo se přiděluje za běhu.

Sledujte mezeru mezi nahozením sítě a nahozením tunelu

Nebezpečný interval není celý restart, ale mezera. Rozhraní dostane pronájem a výchozí trasu v jednom okamžiku, služba VPN startuje v jiném a tunel se autentizuje ještě později, někdy až poté, co se uživatel přihlásí a spustí se agent pověření. Pokud se blok aplikuje poslední, všechno v mezeře odejde otevřeně.

Na systemd hostitelích čtěte pořadí, místo abyste ho hádali. Spusťte systemctl cat na unitech VPN a firewallu a hledejte After= nebo Before= vůči network-pre.target a network-online.target. Unit firewallu seřazený za network-online.target prohrává s rozhraním; ten, který je vyžadován a seřazen před network-pre.target vyhrává. Ve Windows jsou ekvivalentní otázky typ spuštění služby a její závislosti, protože služba nastavená na Manual nemůže zablokovat proces při bootu. Pokud váš požadavek zahrnuje provoz před přihlášením, splňuje ho jen uspořádání na úrovni zařízení: tunel zařízení Always On VPN se autentizuje strojovým certifikátem a připojí se dřív, než se uživatel přihlásí, a Microsoft dokumentuje konfiguraci tunelu zařízení odděleně od uživatelského tunelu. Android jde jinou cestou, vynucuje always-on VPN a blokuje připojení bez ní ze systému, ne z procesu aplikace.

Proveďte test a pak porovnejte dvě časové osy

Restartujte s cílem, který nic nestojí, když unikne a snímejte stav během mezery, ne po ní. Nejčistší metoda je sonda při bootu: oneshot unit nebo naplánovaná úloha, která startuje co nejdřív to platforma dovolí, zaznamená výchozí trasu a stav firewallu, zkusí jeden požadavek s krátkým časovým limitem a přidá řádek do místního souboru. Porovnejte tento záznam s časem startu služby VPN z journalctl -b -u nebo systémového logu.

Pak proveďte obvyklý test: tunel nahoře, přerušte spojení, sledujte, zda je přímý provoz blokován, obnovte. Projít druhým a selhat v prvním je normální výsledek a znamená, že vynucení je na straně klienta, uplatní se při připojení klienta, ne při bootu. Na posledním stroji, který jsem auditoval, blok přicházel ze skriptu správce NetworkManageru: přítomný, správný a k ničemu pro sekundy před nahozením rozhraní. Zapište oba výsledky, protože přežití restartu něco znamená jen tehdy, když řeknete, která vrstva přežila a od kterého okamžiku.

Zavřete mezeru, aniž byste si přeřezali cestu zpět

Pokud blok při bootu chybí, posuňte vynucení o vrstvu níž, místo abyste přidali druhé pravidlo klienta. Uložte sadu pravidel a načítejte ji z unitu seřazeného předtím, než je síť použitelná, a ujistěte se, že tento unit nepotřebuje DNS dotaz ani síťové připojení, které má chránit. Rozsah je stejně důležitý jako časování: pravidla odpovídající ID uživatele nebo cgroup nechávají každý systémový démon mimo blok a sada pravidel, která řeší jen IPv4, nechává IPv6 a DNS dostupné.

Nechte si cestu zpět. Stroj, který při bootu zablokuje všechno a pak se nedokáže autentizovat, nemá vůbec síť, a oprava není smazat blok, ale opravit pověření nebo pořadí. Udržujte zdokumentovaný postup místní konzole a úzkou, záměrnou výjimku pro to, co tunel skutečně potřebuje, jako adresu serveru a resolver používaný před existencí tunelu.

Než uspořádání uvěříte, potvrďte čtyři věci v pořadí. Zásada je uložena tam, kde ji boot čte. Ten čtenář běží dřív, než je rozhraní použitelné. Blok pokrývá obě rodiny adres a DNS. VPN se ještě dokáže autentizovat, zatímco je blok aktivní. Když platí všechny čtyři, restart nic nezmění.