Prežije núdzový vypínač VPN reštart? Ako to overiť

Reštart je najbežnejší spôsob, akým ľudia testujú núdzový vypínač, a je to test, ktorý najčastejšie klame. Zaškrtávacie políčko v klientovi je len predvoľba; rozhodujúce je, či niečo vynucuje blokovanie medzi okamihom, keď sa zdvihne sieťový zásobník, a okamihom, keď je tunel skutočne nadviazaný. Vo Windows je tým niečím zvyčajne filter vo Windows Filtering Platform, v Linuxe sada pravidiel načítaná jednotkou, v macOS kotva pf, v Androide vlastné príznaky systému pre always-on a uzamknutie. Tieto usporiadania sa pri reštarte správajú veľmi odlišne a len tie na úrovni platformy sú na mieste skôr, než sa ktokoľvek môže prihlásiť.

Reštart kladie tri oddelené otázky

Rozdeľte otázku. Po prvé, existuje zásada na disku vo forme, ktorú pri štarte niečo číta? Po druhé, beží ten čitateľ skôr, než môže odísť akákoľvek premávka? Po tretie, pokrýva zásada premávku, na ktorej vám záleží, teda každý proces, obe rodiny adries a DNS. Áno na prvé a nie na druhé vytvárajú presne tú poruchu, ktorú ľudia hlásia ako núdzový vypínač, ktorý reštart neprežije: premávka pri štarte na niekoľko sekúnd unikne a nikto si to nevšimne, kým sa niekto nepozrie.

Držte vrstvy oddelene. Uložená sada pravidiel firewallu, služba, ktorá sa spúšťa pri boote, a predvoľba klienta sú tri rôzne objekty s tromi rôznymi životmi. Predvoľba prežíva reštarty, pretože je to hodnota v konfiguračnom súbore. Pravidlá sú jediné, čo blokuje pakety, a zmiznú spolu s jadrom, ktoré ich držalo.

Nájdite objekt, ktorý obnovuje blokovanie

V Linuxe žijú pravidlá netfilteru v jadre. Nič ich pri štarte nezapisuje späť, ak ste to nezariadili: iptables-save plus netfilter-persistent, nftables.service načítava /etc/nftables.conf, alebo systemd jednotka, ktorá spúšťa váš vlastný skript. Skontrolujte, čo je povolené, namiesto toho, čo si pamätáte, že ste nastavili.

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

Prázdna sada pravidiel pár sekúnd po štarte je odpoveďou na otázku z titulku. Vo Windows sa opýtajte služby klienta, ako sa spúšťa, a potom vyexportujte stav filtra platformy, kým je tunel dole.

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

Druhý príkaz zapisuje wfpstate.xml do aktuálneho adresára. Hľadajte filtre s akciou blokovania, ktoré už existujú pred pripojením klienta. Base Filtering Engine štartuje skoro pri boote a obnovuje filtre pridané s trvalým príznakom, preto niektoré núdzové vypínače blokujú premávku skôr, než existuje akékoľvek okno klienta, a iné nie. V macOS sudo pfctl -s info hlási, či je pf povolený, sudo pfctl -s rules ukazuje, čo je načítané, a VPN klienti zvyčajne pripájajú svoje pravidlá ku kotve namiesto k hlavnej sade. Pravidlo, ktoré menuje utun3, môže po ďalšom štarte ukazovať na iné rozhranie, pretože to číslo sa prideľuje za behu.

Sledujte medzeru medzi zdvihnutím siete a zdvihnutím tunela

Nebezpečný interval nie je celý reštart, je to medzera. Rozhranie dostane lízing a predvolenú trasu v jednom okamihu, služba VPN štartuje v inom a tunel sa autentizuje ešte neskôr, niekedy až po tom, čo sa používateľ prihlási a spustí sa agent poverení. Ak sa blokovanie použije posledné, všetko v medzere odíde otvorene.

Na systemd hostiteľoch čítajte poradie, namiesto aby ste ho hádali. Spustite systemctl cat na jednotkách VPN a firewallu a hľadajte After= alebo Before= voči network-pre.target a network-online.target. Jednotka firewallu zoradená po network-online.target prehráva s rozhraním; tá, ktorú vyžaduje a ktorá je zoradená pred network-pre.target, vyhráva. Vo Windows sú ekvivalentnými otázkami typ spustenia služby a jej závislosti, pretože služba nastavená na Manual nemôže zablokovať proces pri boote. Ak vaša požiadavka zahŕňa premávku pred prihlásením, splní ju len usporiadanie na úrovni zariadenia: tunel zariadenia Always On VPN sa autentizuje strojovým certifikátom a pripojí sa skôr, než sa používateľ prihlási, a Microsoft dokumentuje konfiguráciu tunela zariadenia oddelene od používateľského tunela. Android ide inou cestou, vynucuje always-on VPN a blokuje pripojenia bez neho zo systému, nie z procesu aplikácie.

Vykonajte test a potom porovnajte dve časové osi

Reštartujte s cieľom, ktorý nič nestojí, ak unikne, a zachyťte stav počas medzery, nie po nej. Najčistejšou metódou je sonda pri štarte: oneshot jednotka alebo naplánovaná úloha, ktorá štartuje čo najskôr to platforma dovolí, zaznamená predvolenú trasu a stav firewallu, pokúsi sa o jednu požiadavku s krátkym časovým limitom a pridá riadok do lokálneho súboru. Porovnajte tento záznam s časom štartu služby VPN z journalctl -b -u alebo zo systémového logu.

Potom vykonajte obvyklý test: tunel hore, prerušte pripojenie, sledujte, či je priama premávka blokovaná, obnovte. Prejsť druhým a zlyhať v prvom je normálny výsledok a znamená, že vynucovanie je na strane klienta, uplatňuje sa pri pripojení klienta, nie pri boote. Na poslednom stroji, ktorý som auditoval, blokovanie prichádzalo zo skriptu správcu NetworkManageru: prítomné a správne a zbytočné pre sekundy pred zdvihnutím rozhrania. Zapíšte oba výsledky, pretože prežitie reštartu niečo znamená len vtedy, keď poviete, ktorá vrstva prežila a od ktorého okamihu.

Zatvorte medzeru bez toho, aby ste si prerezali cestu späť

Ak blokovanie pri boote chýba, posuňte vynucovanie o vrstvu nižšie namiesto pridania druhého pravidla klienta. Uložte sadu pravidiel a načítajte ju z jednotky zoradenej skôr, než je sieť použiteľná, a uistite sa, že táto jednotka nepotrebuje DNS dopyt ani sieťové pripojenie, ktoré má chrániť. Rozsah je rovnako dôležitý ako časovanie: pravidlá zodpovedajúce ID používateľa alebo cgroup nechávajú každého systémového démona mimo blokovania, a sada pravidiel, ktorá spracúva len IPv4, necháva IPv6 a DNS dostupné.

Nechajte si cestu späť. Stroj, ktorý pri boote zablokuje všetko a potom sa nedokáže autentizovať, nemá vôbec sieť, a oprava nie je vymazať blokovanie, ale opraviť poverenie alebo poradie. Udržujte zdokumentovaný postup pre lokálnu konzolu a úzku, zámernú výnimku pre to, čo tunel skutočne potrebuje, ako adresa servera a resolver používaný pred existenciou tunela.

Skôr než tejto zostave uveríte, potvrďte štyri veci v poradí. Zásada je uložená tam, kde ju boot číta. Ten čitateľ beží skôr, než je rozhranie použiteľné. Blokovanie pokrýva obe rodiny adries a DNS. VPN sa ešte dokáže autentizovať, kým je blokovanie aktívne. Keď platia všetky štyri, reštart nič nezmení.