Nouzový přepínač stále blokuje provoz po odpojení VPN

Tunel je pryč, ikona sítě vypadá normálně a nic se nenačítá. Odpojili jste VPN, odinstalovali ji nebo restartovali počítač a blokace, která vás měla chránit během výpadku, stále stojí. Okno klienta to nevysvětlí, protože vás neblokuje klient: rozhodnutí bylo zapsáno do jádra vaším jménem a nic nezůstalo, co by ho odstranilo. Ve Windows tento stav sídlí ve Windows Filtering Platform; v Linuxu je to sada pravidel v iptables nebo nftables, často se snímkem, který se přehraje při startu. Následuje pořadí, které používám: přečtěte stav, smažte nejužší objekt, který vysvětluje selhání, a pak najděte, co ho pořád vrací.

Nouzový přepínač je stav jádra, ne nastavení

Desktopoví klienti realizují blokování přidáváním filtrů, které odmítají provoz mimo tunel. Ve Windows jde o filtry WFP na vrstvách přesměrování připojení a transportu a některé z nich jsou trvalé: zapisují se do úložiště zásad Base Filtering Engine a obnovují se při startu počítače, dříve než se spustí jakýkoli VPN software. Klienti se liší v tom, kdy uklízejí. Někteří odstraní filtry při odpojení, někteří jen při čistém ukončení a někteří jen tehdy, když se nejprve vypne nouzový přepínač. Odinstalujte, dokud je blokace aktivní, nebo zabijte proces a filtry zůstanou.

Linuxovým ekvivalentem je pravidlo drop nebo reject ve výstupní cestě, někdy pravidlo přesměrování, někdy změněná zásada řetězce. Tato pravidla přežívají proces, který je přidal, protože jsou stavem jádra: zabijte klienta, shodte ho nebo vypněte napájení a jádro dál zahazuje pakety, aniž by zbylo něco, co to vrátí. Balíček pro trvalost přidává druhou vrstvu stálosti tím, že pořídí snímek aktuální sady pravidel a obnoví ho při startu, takže další start začíná s již nainstalovanou blokací.

Přečtěte stav WFP, než cokoli smažete

Windows vám dodá potřebné nástroje. Spusťte zvýšený příkazový řádek a vyexportujte stav platformy; výpis se uloží jako wfpstate.xml do pracovního adresáře.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

Hledejte v XML jméno odešlého dodavatele, akci Block a vrstvu. Filtry na přesměrování připojení a transportu jsou ty, které ničí běžný provoz; filtr na vrstvě přijímání přijetí obvykle není vaše příčina. Pokud Base Filtering Engine vůbec neběží, hledejte jinde, protože nic jiného tyto filtry vynutit nemůže.

Zkontrolujte také běžný pohled brány firewall, protože většina lidí prohlíží jen jeden ze dvou:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Když jsou vestavěné profily zapnuté a selhávajícímu provozu neodpovídá žádné pravidlo, blokace pochází od dodavatele třetí strany, ne od brány firewall Windows. Tento rozdíl rozhoduje, který nástroj použijete k opravě.

Čtěte pravidla Linuxu v syntaxi, kterou budete mazat

iptables -S vypisuje pravidla ve stejném tvaru, v jakém se přidávají, takže je výstup přímo použitelný pro smazání. iptables -L -v -n přidává čítače paketů a ty vám řeknou, zda pravidlo skutečně odpovídá vašim neúspěšným požadavkům, nebo jen leží v řetězci.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Čtěte zásady řetězců, ne jen pravidla: -P OUTPUT DROP blokuje provoz, i když neodpovídá žádné pravidlo. Prozkoumejte IPv6 samostatně, protože klient, který instaluje obě rodiny, může po zmizení pravidel IPv4 nechat blokaci IPv6 na místě, a symptom pak závisí na tom, kterou rodinu aplikace preferuje. Kde se používá nftables, spusťte také nft list ruleset; oba nástroje koexistují přes vrstvu kompatibility a jeden výpis nemusí ukázat každé pravidlo, které může paket zahodit.

Smažte nejužší objekt, který vysvětluje selhání

Ve Windows je prvním krokem stále vlastní cesta odstranění od dodavatele: spusťte znovu instalátor a použijte opravu nebo odinstalaci, nebo spusťte čisticí nástroj, pokud ho dodavatel publikuje. Zbytkové služby a naplánované úlohy jsou běžné a úloha, která spouští klienta při přihlášení, při dalším startu znovu nainstaluje jeho filtry. Odinstalace, která selže při čtení registrového klíče klienta, obvykle znamená, že ho stále drží služba nebo úloha, ne že je registr poškozený.

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Trvalé filtry jsou poslední možnost. Sídlí pod HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, jedna hodnota na filtr s klíčem GUID. Nejprve exportujte klíč, poznamenejte si GUID, které odstraňujete, mažte jen hodnoty patřící odešlému klientovi a pak restartujte, aby engine znovu sestavil svůj stav. Nemažte celý klíč a nevypínejte Base Filtering Engine: brána firewall Windows a Defender na něm závisí a vyměnili byste jeden výpadek za horší.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

V Linuxu vezměte řádek, který vypisuje iptables -S, a nahraďte -A za -D. Smazání jednoho pravidla, které jste identifikovali, je lepší než vyprázdnění řetězce, protože ponechá vaši vlastní zásadu nedotčenou.

sudo iptables -D OUTPUT -p udp -j REJECT

Pokud drop sídlí v uživatelsky definovaném řetězci, nejprve smažte skok do tohoto řetězce a poté řetězec odstraňte pomocí -X. Nastavení zásady řetězce na ACCEPT, zatímco pravidla drop jsou stále přítomna, pomůže jen paketům, které se vůbec dostanou k rozhodnutí o zásadě. Vyprázdnění všech tabulek je poslední možnost: odstraní i pravidla, která jste přidali z jiných důvodů, a při zapnutém ufw nechá službu v domnění, že vlastní řetězce, které už neexistují.

Najděte vlastníka, který to vrací

Po okamžité opravě hledejte cokoli, co by stav obnovilo. V Linuxu zkontrolujte, zda je povolena jednotka trvalosti, zda má klient nastavení obnovy brány firewall při přihlášení a zda pod /etc existuje uložený soubor pravidel. Ve Windows znovu zkontrolujte položky spouštění, služby a naplánované úlohy, pak restartujte a přečtěte stav stejnými příkazy jako předtím.

Pokud se blokace vrátí, smazání nebylo řešením; byl jím vlastník. Poznamenejte si, který klient nebo služba ji instaluje, a funkci tam vypněte, místo abyste s ní po každém odpojení bojovali na vrstvě brány firewall.

Ověřujte skutečným provozem, ne jedním pingem

Otestujte překlad jména, TCP spojení a novou relaci prohlížeče, pak restartujte a zopakujte stejné tři kontroly. Ping, který funguje, zatímco HTTPS selhává, ukazuje na filtr transportní vrstvy, ne na síť, a blokace, která se vrací jen po restartu, ukazuje na vlastníka, kterého jste ještě nenašli.

Uchovávejte důkazy: exportovaný klíč BFE nebo výstup iptables -S zachycený před změnou. Než to označíte za opravené, potvrďte vrstvu, ze které jste objekt odstranili, vlastníka, který by ho mohl znovu nainstalovat, stav po jednom čistém restartu a že běžné prohlížení funguje bez běžícího VPN procesu. Stránka manuálu iptables(8) má přesnou syntaxi mazání a zásad, pokud čištění skriptujete.