Varnostno stikalo še vedno blokira promet po prekinitvi VPN

Tunela ni več, ikona omrežja je videti običajno, nič pa se ne naloži. Odklopili ste VPN, ga odstranili ali znova zagnali, blokada, ki naj bi vas zaščitila ob prekinitvi, pa še stoji. Okno odjemalca tega ne more pojasniti, ker ne blokira odjemalec: odločitev je bila zapisana v jedro v vašem imenu in nič ni ostalo, da bi jo odstranilo. V Windowsu to stanje leži v Windows Filtering Platform; v Linuxu je to nabor pravil v iptables ali nftables, pogosto s posnetkom, ki se ob zagonu znova uporabi. Sledi vrstni red, ki ga uporabljam: preberite stanje, izbrišite najožji objekt, ki pojasnjuje napako, nato poiščite, kar ga vedno znova vrača.

Varnostno stikalo je stanje jedra, ne nastavitev

Namizni odjemalci blokiranje izvajajo z dodajanjem filtrov, ki zavračajo promet zunaj tunela. V Windowsu so to filtri WFP na plasteh connect-redirect in transport, nekateri pa so trajni: zapišejo se v shrambo pravilnikov Base Filtering Engine in obnovijo ob zagonu stroja, preden se zažene kakršna koli VPN programska oprema. Odjemalci se razlikujejo po tem, kdaj čistijo. Nekateri odstranijo filtre ob odklopu, drugi samo ob čistem izhodu, tretji samo, če najprej izklopite stikalo. Odstranite program, medtem ko je blokada aktivna, ali ubijte proces in filtri ostanejo.

Enakovredno v Linuxu je pravilo drop ali reject na izhodni poti, včasih pravilo forwarding, včasih spremenjen pravilnik verige. Ta pravila živijo dlje kot proces, ki jih je dodal, ker so stanje jedra: ubijte odjemalca, povzročite sesutje ali prekinite napajanje in jedro še naprej zavrača pakete, nič pa ne ostane, da bi to preklicalo. Paket trajnosti doda drugo plast trajnosti tako, da posname trenutni nabor pravil in ga obnovi ob zagonu, zato se naslednji zagon začne z že nameščeno blokado.

Preberite stanje WFP, preden karkoli izbrišete

Windows prinaša potrebna orodja. Zaženite povišan ukazni poziv in izvozite stanje platforme; izpis se shrani kot wfpstate.xml v delovni mapi.

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

V XML poiščite ime odhajajočega ponudnika, dejanje Block in plast. Filtri na connect-redirect in transport so tisti, ki lomijo običajen promet; filter na plasti receive-accept običajno ni vaš vzrok. Če Base Filtering Engine sploh ne teče, iščite drugje, ker nič drugega ne more uveljaviti teh filtrov.

Preverite tudi običajen pogled požarnega zidu, saj večina ljudi pregleda le enega od dveh:

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

Ko so vgrajeni profili vklopljeni in nobeno pravilo ne ustreza prometu, ki odpove, blokada prihaja od tretjega ponudnika in ne od Windows Firewall. Ta razlika odloči, katero orodje boste uporabili za popravilo.

Berite pravila Linuxa v sintaksi, s katero boste brisali

iptables -S izpiše pravila v enaki obliki, kot so bila dodana, zato je izpis mogoče neposredno znova uporabiti za brisanje. iptables -L -v -n doda števce paketov, ti števci pa povedo, ali se pravilo res ujema z vašimi neuspešnimi zahtevami ali samo sedi v verigi.

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

Berite pravilnike verig, ne le pravil: -P OUTPUT DROP blokira promet tudi, ko se nobeno pravilo ne ujema. IPv6 pregledajte ločeno, ker lahko odjemalec, ki namesti obe družini, pusti blokado IPv6 na mestu, potem ko pravil IPv4 ni več, in simptom je potem odvisen od tega, kateri družini daje prednost aplikacija. Kjer se uporablja nftables, zaženite tudi nft list ruleset; orodji sobivata prek plasti združljivosti in en seznam ne pokaže nujno vsakega pravila, ki lahko zavrže paket.

Izbrišite najožji objekt, ki pojasnjuje napako

V Windowsu je prvi korak še vedno pot odstranitve pri ponudniku: znova zaženite namestitveni program in uporabite repair ali uninstall, ali zaženite orodje za čiščenje, če ga ponudnik objavi. Preostale storitve in načrtovana opravila so pogosta, opravilo, ki zažene odjemalca ob prijavi, pa ob naslednjem zagonu znova namesti njegove filtre. Odstranitev, ki ne uspe pri branju ključa registra odjemalca, običajno pomeni, da ga še drži storitev ali opravilo, ne da je register poškodovan.

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

Trajni filtri so zadnja možnost. Ležijo pod HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, ena vrednost na filter s ključem GUID. Najprej izvozite ključ, zapišite GUID-e, ki jih odstranjujete, brišite le vrednosti, ki pripadajo odhajajočemu odjemalcu, nato znova zaženite, da motor znova zgradi stanje. Ne brišite celega ključa in ne onemogočite Base Filtering Engine: Windows Firewall in Defender sta odvisna od njega, eno motnjo pa bi zamenjali za slabšo.

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

V Linuxu vzemite vrstico, ki jo izpiše iptables -S, in zamenjajte -A z -D. Brisanje enega pravila, ki ste ga prepoznali, je boljše od praznjenja verige, ker vaš lastni pravilnik ostane nedotaknjen.

sudo iptables -D OUTPUT -p udp -j REJECT

Če drop leži v verigi, ki jo je določil uporabnik, najprej izbrišite skok v to verigo in nato verigo odstranite z -X. Nastavitev pravilnika verige na ACCEPT, medtem ko pravila drop še obstajajo, pomaga le paketom, ki sploh dosežejo odločitev o pravilniku. Praznjenje vseh tabel je zadnja možnost: odstrani tudi pravila, ki ste jih dodali iz drugih razlogov, in ob vklopljenem ufw pusti storitvi prepričanje, da ima verige, ki jih ni več.

Poiščite lastnika, ki to vrača

Po takojšnjem popravilu poiščite, kar bi obnovilo stanje. V Linuxu preverite, ali je enota trajnosti omogočena, ali ima odjemalec nastavitev obnove požarnega zidu ob prijavi in ali pod /etc obstaja shranjena datoteka pravil. V Windowsu znova preverite zagonske vnose, storitve in načrtovana opravila, nato znova zaženite in preberite stanje z istimi ukazi kot prej.

Če se blokada vrne, brisanje ni bilo rešitev; lastnik je bil. Zapišite, kateri odjemalec ali storitev jo namesti, in funkcijo onemogočite tam, namesto da bi se z njo borili na ravni požarnega zidu po vsaki prekinitvi.

Preverite s pravim prometom, ne z enim pingom

Preizkusite razreševanje imena, povezavo TCP in novo sejo brskalnika, nato znova zaženite in ponovite iste tri preveritve. Ping, ki deluje, medtem ko HTTPS odpove, kaže na filter na transportni plasti in ne na omrežje, blokada, ki se vrne šele po ponovnem zagonu, pa kaže na lastnika, ki ga še niste našli.

Shranite dokaze: izvožen ključ BFE ali izpis iptables -S, zajet pred spremembo. Preden to razglasite za popravljeno, potrdite plast, s katere ste odstranili objekt, lastnika, ki bi ga lahko znova namestil, stanje po enem čistem zagonu in da običajno brskanje deluje brez delujočega procesa VPN. Stran priročnika iptables(8) ima natančno sintakso brisanja in pravilnika, če čiščenje napišete kot skript.