Neyðarrofinn heldur enn áfram að blokka umferð eftir að VPN-tengingin slitnar

Göngin eru horfin, nettáknið lítur eðlilega út og ekkert hleðst. Þú aftengdir VPN-ið, settir það upp eða endurræstir, og blokkin sem átti að vernda þig þegar tenging féll stendur enn. Biðlaraglugginn getur ekki útskýrt það, því biðlarinn er ekki það sem blokkar þig: ákvörðunin var skrifuð í kjarnann í þínu nafni og ekkert var skilið eftir til að fjarlægja hana. Í Windows býr þetta ástand í Windows Filtering Platform; í Linux er það reglusett í iptables eða nftables, oft með skyndimynd sem er endurspiluð við ræsingu. Eftirfarandi er röðin sem ég nota: lestu ástandið, eyddu þrengsta hlutnum sem útskýrir bilunina og finndu síðan hvað sem heldur áfram að setja hann aftur.

Neyðarrof er kjarnaástand, ekki stilling

Skjáborðsbiðlarar útfæra blokkun með því að bæta við síum sem meina umferð utan ganganna. Í Windows eru það WFP-síur á connect-redirect- og transportlögum, og sumar þeirra eru varanlegar: þær eru skráðar í stefnusafn Base Filtering Engine og endurheimtar þegar vélin ræsist, áður en nokkur VPN-hugbúnaður keyrir. Biðlarar eru mismunandi að því hvenær þeir hreinsa til. Sumir fjarlægja síur við aftengingu, sumir aðeins við hreina lokun og sumir aðeins þegar slökkt er fyrst á neyðarrofnum. Fjarlægðu uppsetninguna meðan blokkin er virk, eða drepðu ferlið, og síurnar verða áfram.

Hliðstæðan í Linux er drop- eða reject-regla í útgangsferlinum, stundum framsendingarregla, stundum breytt keðjustefna. Þessar reglur lifa lengur en ferlið sem bætti þeim við, því þær eru kjarnaástand: drepðu biðlarann, láttu hann hrynja eða rofaðu rafmagnið, og kjarninn heldur áfram að sleppa pakkum án þess að nokkuð sé eftir til að afturkalla það. Varanleikapakki bætir við öðru lagi af varanleika með því að taka skyndimynd af núverandi reglusetti og endurheimta hana við ræsingu, svo næsta ræsing hefst með blokkinni þegar uppsetta.

Lestu WFP-ástandið áður en þú eyðir nokkru

Windows kemur með verkfærin sem þú þarft. Keyrðu stjórnandaskel og dumpaðu stöðu kerfisins; dumpið lendir sem wfpstate.xml í vinnuskránni.

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

Leitaðu í XML-inu að nafni framliðins söluaðila, að Block-aðgerð og að laginu. Síur á connect-redirect og transport eru þær sem brjóta venjulega umferð; sía á receive-accept-lagi er venjulega ekki orsök þín. Ef Base Filtering Engine keyrir alls ekki skaltu leita annars staðar, því ekkert annað getur framfylgt þessum síum.

Krossprófaðu líka venjulega eldveggssýn, því flestir skoða aðeins aðra þeirra:

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

Þegar innbyggðu sniðin eru virk og engin regla passar við umferðina sem bregst kemur blokkin frá þriðja aðila en ekki Windows Firewall. Sá greinarmunur ræður því hvaða verkfæri þú notar við viðgerðina.

Lestu Linux-reglur í þeirri setningu sem þú eyðir með

iptables -S prentar reglur í sama formi og notað var til að bæta þeim við, sem gerir úttakið beint endurnýtanlegt við eyðingu. iptables -L -v -n bætir við pakkatalningum, og þær segja þér hvort regla passar raunverulega við misheppnuðu beiðnirnar þínar eða situr bara í keðjunni.

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

Lestu keðjustefnur, ekki bara reglurnar: -P OUTPUT DROP blokkar umferð jafnvel þótt engin regla passi. Skoðaðu IPv6 sérstaklega, því biðlari sem setur upp báðar fjölskyldur getur skilið IPv6-blokkina eftir þegar IPv4-reglurnar eru horfnar, og einkennin ráðast þá af því hvorri fjölskyldu forritið velur. Þar sem nftables er notað skaltu líka keyra nft list ruleset; verkfærin tvö lifa saman í gegnum samhæfingarlag, og ein lista sýnir ekki endilega hverja reglu sem getur sleppt pakka.

Eyddu þrengsta hlutnum sem útskýrir bilunina

Í Windows er fyrsta skrefið enn fjarlægingarleið söluaðilans: keyrðu uppsetninguna aftur og notaðu repair eða uninstall, eða keyrðu hreinsiverkfærið ef söluaðilinn gefur það út. Afgangsþjónustur og tímaáætluð verk eru algeng, og verk sem ræsir biðlarann við innskráningu setur síurnar aftur upp við næstu ræsingu. Uppsetning sem mistekst við að lesa skráarkerfi biðlarans þýðir venjulega að þjónusta eða verk heldur enn um hana, ekki að skráin sé skemmd.

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

Varanlegar síur eru síðasta úrræðið. Þær búa undir HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, eitt gildi fyrir hverja síu lyklað með GUID. Flyttu lykilinn út fyrst, skráðu GUID-in sem þú fjarlægir, eyddu aðeins gildunum sem tilheyra framliðna biðlaranum og endurræstu svo að vélin endurbyggir ástandið. Ekki eyða öllum lyklinum og ekki slökkva á Base Filtering Engine: Windows Firewall og Defender reiða sig á hann, og þú myndir skipta einni truflun fyrir verri.

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

Í Linux skaltu taka línuna sem iptables -S prentar og skipta -A út fyrir -D. Að eyða einni reglunni sem þú greindir er betra en að tæma keðju, því eigin stefna þín helst ósnortin.

sudo iptables -D OUTPUT -p udp -j REJECT

Ef dropið býr í keðju sem notandinn skilgreindi skaltu fyrst eyða stökkinu í þá keðju og fjarlægja keðjuna síðan með -X. Að setja keðjustefnu á ACCEPT meðan drop-reglur eru enn til staðar hjálpar aðeins pakkum sem ná allt að stefnuákvörðuninni. Að tæma hverja töflu er síðasta úrræðið: það fjarlægir líka reglur sem þú bættir við af öðrum ástæðum, og með ufw virkt lætur það þjónustuna halda að hún eigi keðjur sem eru ekki lengur til.

Finndu eigandann sem setur það aftur

Eftir beinu viðgerðina skaltu leita að því sem myndi endurheimta ástandið. Í Linux skaltu athuga hvort varanleikaeining er virk, hvort biðlarinn er með stillingu til að endurheimta eldvegg við innskráningu og hvort vistuð regluskrá er undir /etc. Í Windows skaltu athuga ræsingarfærslur, þjónustur og tímaáætluð verk aftur, endurræsa og lesa ástandið með sömu skipunum og áður.

Ef blokkin kemur aftur var eyðingin ekki lagfæringin; eigandinn var það. Skráðu hvaða biðlari eða þjónusta setur hana upp og slökktu á eiginleikanum þar, í stað þess að berjast við hann á eldveggslaginu eftir hverja aftengingu.

Staðfestu með raunverulegri umferð, ekki einu pingskoti

Prófaðu nafnauppflettingu, TCP-tengingu og nýja vafralotu, endurræstu og endurtaktu sömu þrjú prófin. Ping sem virkar á meðan HTTPS bregst bendir á síu á transportlagi en ekki á netið, og blokk sem kemur aftur aðeins eftir endurræsinguna bendir á eiganda sem þú hefur ekki fundið enn.

Geymdu sönnunargögnin: útflutta BFE-lykilinn eða iptables -S-úttakið sem tekið var fyrir breytinguna. Áður en þú kallar það lagað skaltu staðfesta lagið sem þú fjarlægðir hlutinn af, eigandann sem gæti sett hann aftur upp, ástandið eftir eina hreina endurræsingu og að venjuleg vafrun virki án þess að VPN-ferli keyri. Handbókarsíða iptables(8) hefur nákvæma eyðingar- og stefnusetningu ef þú skrifar hreinsunina sem skriptu.