Sigurnosni prekidač i dalje blokira promet nakon prekida VPN-a

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

Sigurnosni prekidač je stanje jezgre, a ne postavka

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

Linuxov ekvivalent je pravilo odbacivanja ili odbijanja na izlaznom putu, katkad pravilo prosljeđivanja, katkad promijenjeno pravilo lanca. Ta pravila nadživljavaju proces koji ih je dodao jer su stanje jezgre: ubijte klijent, srušite ga ili prekinite napajanje, a jezgra nastavlja odbacivati pakete i ništa ne preostaje da to poništi. Paket trajnosti dodaje drugi sloj stalnosti tako što snima trenutni skup pravila i vraća ga pri podizanju, pa sljedeći početak započinje s već instaliranom blokadom.

Pročitajte WFP stanje prije nego išta izbrišete

Windows dolazi s alatima koji su vam potrebni. Pokrenite povišeni prompt i ispišite stanje platforme; ispis se sprema kao wfpstate.xml u radnom direktoriju.

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

U XML-u potražite ime otišlog dobavljača, radnju Block i sloj. Filtri na preusmjeravanju veze i prijenosu oni su koji kvare običan promet; filtar na sloju primanja obično nije vaš uzrok. Ako Base Filtering Engine uopće ne radi, tražite drugdje jer ništa drugo ne može provesti te filtre.

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

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

Kada su ugrađeni profili uključeni i nijedno pravilo ne odgovara prometu koji ne uspijeva, blokada dolazi od trećeg dobavljača, a ne od Windows vatrozida. Ta razlika odlučuje kojim ćete se alatom koristiti za popravak.

Čitajte Linuxova pravila u sintaksi kojom ćete brisati

iptables -S ispisuje pravila u istom obliku u kojem se dodaju, što izlaz čini izravno iskoristivim za brisanje. iptables -L -v -n dodaje brojače paketa, a ti brojači govore odgovara li pravilo doista vašim neuspjelim zahtjevima ili samo stoji u lancu.

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

Čitajte pravila lanaca, ne samo pravila: -P OUTPUT DROP blokira promet čak i kad nijedno pravilo ne odgovara. Pregledajte IPv6 odvojeno jer klijent koji instalira obje obitelji može ostaviti blokadu IPv6 na mjestu nakon što pravila IPv4 nestanu, a simptom tada ovisi o tome koju obitelj aplikacija preferira. Gdje se rabi nftables, pokrenite i nft list ruleset; dva alata supostoje kroz sloj kompatibilnosti i 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 instalacijsku datoteku i rabite popravak ili deinstalaciju ili pokrenite alat za čišćenje ako ga dobavljač objavljuje. Zaostale usluge i zakazani zadaci uobičajeni 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 posljednje su sredstvo. Nalaze se pod HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, po jedna vrijednost za svaki filtar s ključem GUID. Najprije izvezite ključ, zabilježite GUID-ove koje uklanjate, brišite samo vrijednosti koje pripadaju otišlom klijentu, zatim ponovno pokrenite sustav da motor obnovi svoje stanje. Ne brišite cijeli ključ i ne onemogućujte Base Filtering Engine: Windows vatrozid 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 ispisuje iptables -S i zamijenite -A s -D. Brisanje jednoga pravila koje ste prepoznali bolje je od pražnjenja lanca jer ostavlja vaše vlastito pravilo netaknutim.

sudo iptables -D OUTPUT -p udp -j REJECT

Ako odbacivanje boravi u lancu koji je definirao korisnik, najprije izbrišite skok u taj lanac, a zatim uklonite lanac pomoću -X. Postavljanje pravila lanca na ACCEPT dok su pravila odbacivanja još prisutna pomaže samo paketima koji uopće dođu do odluke o pravilu. Pražnjenje svih tablica posljednje je sredstvo: uklanja i pravila koja ste dodali iz drugih razloga, a uz uključen ufw ostavlja uslugu u uvjerenju da posjeduje lance koji više ne postoje.

Pronađite vlasnika koji ga vraća

Nakon neposrednog popravka potražite sve što bi moglo obnoviti stanje. U Linuxu provjerite je li jedinica trajnosti omogućena, ima li klijent postavku obnove vatrozida pri prijavi i postoji li spremljena datoteka pravila pod /etc. U Windowsu ponovno provjerite stavke pokretanja, usluge i zakazane zadatke, zatim ponovno pokrenite sustav i pročitajte stanje istim naredbama kao prije.

Ako se blokada vrati, brisanje nije bilo rješenje; vlasnik jest. Zabilježite koji klijent ili usluga ga instalira i onemogućite značajku ondje, umjesto da se s njom borite na sloju vatrozida nakon svakog prekida.

Provjerite stvarnim prometom, ne jednim pingom

Testirajte pretragu imena, TCP vezu i novu sesiju preglednika, zatim ponovno pokrenite sustav i ponovite iste tri provjere. Ping koji radi dok HTTPS ne uspijeva upućuje na filtar prijenosnog sloja, a ne na mrežu, a blokada koja se vraća samo nakon ponovnog pokretanja upućuje na vlasnika kojega 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 ponovnog pokretanja i da obično pregledavanje radi bez pokrenutog VPN procesa. Stranica priručnika iptables(8) sadrži točnu sintaksu brisanja i pravila ako skriptirate čišćenje.