Kill switch i dalje blokira promet nakon prekida VPN-a

Tunel je nestao, ikona mreže izgleda normalno, a ništa se ne učitava. Odspojili ste VPN, deinstalirali ga ili ponovno pokrenuli računalo, a blokada koja vas je trebala zaštititi tijekom prekida još stoji. Prozor klijenta to ne može objasniti jer ne blokira klijent: odluka je zapisana u kernel u vaše ime i ništa nije ostavljeno da je ukloni. U Windowsu to stanje stoji u Windows Filtering Platform; u Linuxu je to skup pravila u iptables ili nftables, često sa snimkom koji se ponovno primjenjuje pri podizanju. Slijedi redoslijed koji koristim: pročitajte stanje, izbrišite najuži objekt koji objašnjava kvar, zatim pronađite sve što ga stalno vraća.

Kill switch je stanje kernela, a ne postavka

Desktop klijenti blokadu provode dodavanjem filtara koji odbijaju promet izvan tunela. U Windowsu su to WFP filtri na slojevima connect-redirect i transport, a neki su trajni: upisuju se u spremište pravila Base Filtering Engine i vraćaju pri podizanju računala, prije nego što se pokrene bilo koji VPN softver. Klijenti se razlikuju po tome kada čiste. Neki uklanjaju filtre pri odspajanju, neki samo pri čistom izlasku, a neki samo ako se prvo isključi prekidač. Deinstalirajte dok je blokada aktivna ili ubijte proces i filtri ostaju.

Linux ekvivalent je drop ili reject pravilo na izlaznom putu, ponekad forwarding pravilo, ponekad promijenjena politika lanca. Ta pravila žive dulje od procesa koji ih je dodao jer su stanje kernela: ubijte klijent, srušite ga ili prekinite napajanje, a kernel nastavlja odbacivati pakete i ništa ne ostaje da to poništi. Paket trajnosti dodaje drugi sloj trajnosti tako što snimi trenutni skup pravila i vrati ga pri podizanju, pa sljedeće pokretanje počinje s već instaliranom blokadom.

Pročitajte WFP stanje prije nego što bilo što izbrišete

Windows dolazi s potrebnim alatima. Pokrenite povišeni prompt i ispišite stanje platforme; ispis završi kao wfpstate.xml u radnom direktoriju.

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

U XML-u tražite ime dobavljača koji je otišao, radnju Block i sloj. Filtri na connect-redirect i transport su oni koji lome obični promet; filtar na sloju receive-accept obično nije vaš uzrok. Ako Base Filtering Engine uopće ne radi, tražite drugdje jer ništa drugo ne može provoditi te filtre.

Provjerite i uobičajeni prikaz vatrozida jer većina ljudi pregledava samo jedan od dva:

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

Kad su ugrađeni profili uključeni i nijedno pravilo ne odgovara prometu koji ne uspijeva, blokada dolazi od trećeg pružatelja, a ne od Windows Firewalla. Ta razlika odlučuje koji ćete alat koristiti za popravak.

Čitajte Linux pravila u sintaksi kojom ćete brisati

iptables -S ispisuje pravila u istom obliku u kojem su dodana, pa se izlaz može izravno ponovno upotrijebiti za brisanje. iptables -L -v -n dodaje brojače paketa, a ti brojači govore odgovara li pravilo stvarno vašim neuspjelim zahtjevima ili samo stoji u lancu.

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

Čitajte politike lanaca, ne samo pravila: -P OUTPUT DROP blokira promet i kad nijedno pravilo ne odgovara. Pregledajte IPv6 odvojeno jer klijent koji instalira obje obitelji može ostaviti IPv6 blokadu nakon što IPv4 pravila nestanu, a simptom tada ovisi o tome koju obitelj aplikacija preferira. Gdje se koristi nftables, pokrenite i nft list ruleset; dva alata supostoje kroz sloj kompatibilnosti, a jedan popis ne pokazuje nužno svako pravilo koje može odbaciti paket.

Izbrišite najuži objekt koji objašnjava kvar

U Windowsu je prvi korak još uvijek dobavljačev vlastiti put uklanjanja: ponovno pokrenite instalacijski program i upotrijebite repair ili uninstall, ili pokrenite alat za čišćenje ako ga dobavljač objavljuje. Preostale usluge i zakazani zadaci česti su, a zadatak koji pokreće klijent pri prijavi ponovno instalira njegove filtre pri sljedećem podizanju. Deinstalacija koja ne uspije pri čitanju ključa registra klijenta obično znači da ga usluga ili zadatak još drži, a ne da je registar oštećen.

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

Trajni filtri su posljednje sredstvo. Nalaze se pod HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, jedna vrijednost po filtru s ključem GUID. Najprije izvezite ključ, zapišite GUID-ove koje uklanjate, brišite samo vrijednosti koje pripadaju otišlom klijentu, zatim ponovno pokrenite računalo da motor ponovno izgradi stanje. Ne brišite cijeli ključ i ne onemogućujte Base Filtering Engine: Windows Firewall i Defender ovise o njemu, i zamijenili biste jedan prekid gorim.

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

U Linuxu uzmite redak koji ispiše iptables -S i zamijenite -A s -D. Brisanje jednog pravila koje ste identificirali bolje je od pražnjenja lanca jer vaša vlastita politika ostaje netaknuta.

sudo iptables -D OUTPUT -p udp -j REJECT

Ako drop stoji u korisnički definiranom lancu, najprije izbrišite skok u taj lanac i zatim uklonite lanac s -X. Postavljanje politike lanca na ACCEPT dok drop pravila još postoje pomaže samo paketima koji uopće dođu do odluke o politici. Pražnjenje svih tablica je posljednje sredstvo: uklanja i pravila koja ste dodali iz drugih razloga, a s uključenim ufw ostavlja uslugu uvjerenom da posjeduje lance koji više ne postoje.

Pronađite vlasnika koji to vraća

Nakon neposredne popravke potražite sve što bi vratilo stanje. U Linuxu provjerite je li jedinica trajnosti omogućena, ima li klijent postavku vraćanja vatrozida pri prijavi i postoji li spremljena datoteka pravila pod /etc. U Windowsu ponovno provjerite stavke pokretanja, usluge i zakazane zadatke, zatim ponovno pokrenite računalo i pročitajte stanje istim naredbama kao prije.

Ako se blokada vrati, brisanje nije bilo rješenje; vlasnik je bio. Zapišite koji klijent ili usluga to instalira i onemogućite značajku ondje, umjesto da se s njom borite na razini vatrozida nakon svakog odspajanja.

Provjerite stvarnim prometom, a ne jednim pingom

Testirajte razrješavanje imena, TCP vezu i novu sesiju preglednika, zatim ponovno pokrenite računalo i ponovite iste tri provjere. Ping koji radi dok HTTPS ne uspijeva upućuje na filtar transportnog sloja, a ne na mrežu, a blokada koja se ponovno pojavi samo nakon podizanja upućuje na vlasnika kojeg još niste pronašli.

Sačuvajte dokaze: izvezeni BFE ključ ili izlaz iptables -S zabilježen prije promjene. Prije nego što to nazovete riješenim, potvrdite sloj s kojeg ste uklonili objekt, vlasnika koji bi ga mogao ponovno instalirati, stanje nakon jednog čistog podizanja i da obično pregledavanje radi bez pokrenutog VPN procesa. Stranica priručnika iptables(8) ima točnu sintaksu brisanja i politike ako čišćenje pišete kao skriptu.