Przełącznik bezpieczeństwa nadal blokuje ruch po rozłączeniu VPN

Tunelu nie ma, ikona sieci wygląda normalnie, a nic się nie ładuje. Rozłączyłeś VPN, odinstalowałeś go albo zrestartowałeś komputer, a blokada, która miała cię chronić podczas zerwania, nadal stoi. Okno klienta tego nie wyjaśni, bo blokuje nie klient: decyzja została zapisana w jądrze w twoim imieniu i nic nie zostało, żeby ją usunąć. W Windows ten stan siedzi w Windows Filtering Platform; w Linuksie to zestaw reguł w iptables lub nftables, często z migawką odtwarzaną przy starcie. Dalej opisuję kolejność, której używam: odczytaj stan, usuń najwęższy obiekt wyjaśniający awarię, a potem znajdź to, co ciągle go przywraca.

Przełącznik bezpieczeństwa to stan jądra, nie ustawienie

Klienty desktopowe realizują blokowanie, dodając filtry, które odmawiają ruchu poza tunelem. W Windows są to filtry WFP na warstwach connect-redirect i transport, a część z nich jest trwała: są zapisywane w magazynie zasad Base Filtering Engine i przywracane przy starcie maszyny, zanim uruchomi się jakiekolwiek oprogramowanie VPN. Klienty różnią się tym, kiedy sprzątają. Jedne usuwają filtry przy rozłączeniu, inne tylko przy czystym zamknięciu, a jeszcze inne tylko wtedy, gdy najpierw wyłączy się przełącznik. Odinstaluj, gdy blokada jest aktywna, albo zabij proces, a filtry zostaną.

Odpowiednikiem w Linuksie jest reguła drop lub reject w ścieżce wyjściowej, czasem reguła forwarding, czasem zmieniona polityka łańcucha. Te reguły żyją dłużej niż proces, który je dodał, bo są stanem jądra: zabij klienta, wywołaj awarię albo odetnij zasilanie, a jądro nadal zrzuca pakiety i nic nie zostaje, żeby to cofnąć. Pakiet trwałości dodaje drugą warstwę trwałości, zapisując migawkę bieżącego zestawu reguł i przywracając ją przy starcie, więc następny start zaczyna się z już zainstalowaną blokadą.

Odczytaj stan WFP, zanim cokolwiek usuniesz

Windows dostarcza potrzebne narzędzia. Uruchom wiersz polecenia z uprawnieniami administratora i zrzuć stan platformy; zrzut pojawi się jako wfpstate.xml w katalogu roboczym.

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

Przeszukaj XML pod kątem nazwy dostawcy, który odszedł, akcji Block i warstwy. Filtry na connect-redirect i transport to te, które psują zwykły ruch; filtr na warstwie receive-accept zwykle nie jest twoją przyczyną. Jeśli Base Filtering Engine w ogóle nie działa, szukaj gdzie indziej, bo nic innego nie egzekwuje tych filtrów.

Sprawdź też zwykły widok zapory, bo większość ludzi ogląda tylko jeden z dwóch:

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

Gdy wbudowane profile są włączone i żadna reguła nie pasuje do ruchu, który zawodzi, blokada pochodzi od dostawcy zewnętrznego, a nie od Windows Firewall. Ta różnica decyduje, którego narzędzia użyjesz do naprawy.

Czytaj reguły Linuksa w składni, którą będziesz usuwać

iptables -S wypisuje reguły w tej samej formie, w jakiej je dodano, więc wynik można bezpośrednio wykorzystać do usunięcia. iptables -L -v -n dodaje liczniki pakietów, a te liczniki mówią, czy reguła faktycznie pasuje do nieudanych żądań, czy tylko siedzi w łańcuchu.

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

Czytaj polityki łańcuchów, nie tylko reguły: -P OUTPUT DROP blokuje ruch nawet wtedy, gdy żadna reguła nie pasuje. Sprawdź IPv6 osobno, bo klient instalujący obie rodziny może zostawić blokadę IPv6 po zniknięciu reguł IPv4, a objaw zależy wtedy od tego, której rodzinie aplikacja daje pierwszeństwo. Tam, gdzie używany jest nftables, uruchom też nft list ruleset; oba narzędzia współistnieją przez warstwę zgodności, a jedna lista niekoniecznie pokazuje każdą regułę, która może zrzucić pakiet.

Usuń najwęższy obiekt wyjaśniający awarię

W Windows pierwszym krokiem jest nadal ścieżka usuwania dostawcy: uruchom ponownie instalator i użyj repair lub uninstall, albo uruchom narzędzie czyszczące, jeśli dostawca je publikuje. Pozostałe usługi i zadania zaplanowane są częste, a zadanie uruchamiające klienta przy logowaniu reinstaluje jego filtry przy następnym starcie. Odinstalowanie, które zawodzi przy odczycie klucza rejestru klienta, zwykle oznacza, że usługa lub zadanie nadal go trzyma, a nie że rejestr jest uszkodzony.

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

Trwałe filtry to ostatnia deska ratunku. Są pod HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, jedna wartość na filtr, kluczowana przez GUID. Najpierw wyeksportuj klucz, zapisz GUID-y, które usuwasz, usuń tylko wartości należące do odeszłego klienta, a potem zrestartuj, żeby silnik odbudował stan. Nie usuwaj całego klucza i nie wyłączaj Base Filtering Engine: Windows Firewall i Defender na nim polegają, a jedną awarię zamieniłbyś na gorszą.

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

W Linuksie weź linię wypisaną przez iptables -S i zamień -A na -D. Usunięcie jednej zidentyfikowanej reguły jest lepsze niż opróżnienie łańcucha, bo twoja własna polityka pozostaje nienaruszona.

sudo iptables -D OUTPUT -p udp -j REJECT

Jeśli drop siedzi w łańcuchu zdefiniowanym przez użytkownika, najpierw usuń skok do tego łańcucha, a potem usuń łańcuch przez -X. Ustawienie polityki łańcucha na ACCEPT, gdy reguły drop nadal istnieją, pomaga tylko pakietom, które w ogóle docierają do decyzji polityki. Opróżnianie wszystkich tabel to ostatnia deska ratunku: usuwa też reguły dodane z innych powodów, a przy włączonym ufw zostawia usługę w przekonaniu, że posiada łańcuchy, których już nie ma.

Znajdź właściciela, który to przywraca

Po doraźnej naprawie poszukaj tego, co przywróciłoby stan. W Linuksie sprawdź, czy jednostka trwałości jest włączona, czy klient ma ustawienie przywracania zapory przy logowaniu i czy pod /etc istnieje zapisany plik reguł. W Windows sprawdź ponownie wpisy startowe, usługi i zadania zaplanowane, a potem zrestartuj i odczytaj stan tymi samymi poleceniami co wcześniej.

Jeśli blokada wraca, usunięcie nie było rozwiązaniem; rozwiązaniem był właściciel. Zapisz, który klient lub usługa ją instaluje, i wyłącz funkcję tam, zamiast walczyć z nią na poziomie zapory po każdym rozłączeniu.

Weryfikuj realnym ruchem, nie jednym pingiem

Przetestuj rozwiązywanie nazw, połączenie TCP i nową sesję przeglądarki, potem zrestartuj i powtórz te same trzy kontrole. Ping, który działa, gdy HTTPS zawodzi, wskazuje na filtr warstwy transport, a nie na sieć, a blokada, która wraca dopiero po restarcie, wskazuje na właściciela, którego jeszcze nie znalazłeś.

Zachowaj dowody: wyeksportowany klucz BFE albo wynik iptables -S przechwycony przed zmianą. Zanim uznasz to za naprawione, potwierdź warstwę, z której usunąłeś obiekt, właściciela, który może go zainstalować ponownie, stan po jednym czystym restarcie i to, że zwykłe przeglądanie działa bez uruchomionego procesu VPN. Strona podręcznika iptables(8) ma dokładną składnię usuwania i polityki, jeśli opiszesz czyszczenie skryptem.