Turvalüliti blokeerib liiklust ka pärast VPN-i lahtiühendamist

Tunnel on kadunud, võrguikoon näeb normaalne välja ja midagi ei laadi. Ühendasite VPN-i lahti, desinstallisite selle või taaskäivitasite arvuti, ja blokeering, mis pidi teid katkestuse ajal kaitsma, seisab endiselt. Kliendi aken ei oska seda seletada, sest teid ei blokeeri klient: otsus kirjutati teie nimel kernelisse ja midagi ei jäetud maha, et seda eemaldada. Windowsis asub see olek Windows Filtering Platformis; Linuxis on see reeglistik iptablesis või nftablesis, sageli hetktõmmisega, mis käivitusel uuesti esitatakse. Järgneb järjekord, mida ma kasutan: lugege olek, kustutage kitsaim objekt, mis riket seletab, ja leidke siis kõik, mis seda pidevalt tagasi paneb.

Turvalüliti on kerneli olek, mitte seade

Töölauakliendid rakendavad blokeerimist, lisades filtreid, mis keelavad liikluse väljaspool tunnelit. Windowsis on need WFP-filtrid ühenduse ümbersuunamise ja transpordi kihtidel, ja mõned neist on püsivad: need salvestatakse Base Filtering Engine’i poliitikahoidlasse ja taastatakse masina käivitumisel, enne kui ükski VPN-tarkvara töötab. Kliendid erinevad selle poolest, millal nad koristavad. Mõned eemaldavad filtrid lahtiühendamisel, mõned ainult puhtal väljumisel ja mõned ainult siis, kui turvalüliti esmalt välja lülitada. Desinstallige, kui blokeering on aktiivne, või tapke protsess ja filtrid jäävad.

Linuxi vaste on drop- või reject-reegel väljundteel, mõnikord edastusreegel, mõnikord muudetud ahela poliitika. Need reeglid elavad kauem protsessist, mis need lisas, sest need on kerneli olek: tapke klient, laske sellel kokku joosta või lülitage toide välja, ja kernel jätkab pakettide viskamist, ilma et midagi jääks seda tagasi pöörama. Püsivuspakett lisab teise püsivuse kihi, tehes hetktõmmise praegusest reeglistikust ja taastades selle käivitusel, nii et järgmine algus algab juba paigaldatud blokeeringuga.

Lugege WFP olekut enne, kui midagi kustutate

Windows toob vajalikud tööriistad kaasa. Käivitage kõrgendatud käsuviip ja laske platvormi olek välja; väljavõte salvestub töökataloogi failina wfpstate.xml.

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

Otsige XML-ist lahkunud tarnija nime, Block-toimingut ja kihti. Ühenduse ümbersuunamise ja transpordi filtrid on need, mis tavalise liikluse katki teevad; vastuvõtu-tagasilükkamise kihil olev filter tavaliselt teie põhjus ei ole. Kui Base Filtering Engine üldse ei tööta, otsige mujalt, sest miski muu ei saa neid filtreid jõustada.

Kontrollige ka tavalist tulemüürivaadet, sest enamik inimesi uurib ainult ühte kahest:

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

Kui sisseehitatud profiilid on sees ja ükski reegel ei vasta nurjuvale liiklusele, tuleb blokeering kolmanda osapoole tarnijalt, mitte Windowsi tulemüürilt. See erinevus otsustab, millist tööriista paranduseks kasutate.

Lugege Linuxi reegleid selles süntaksis, millega kustutate

iptables -S trükib reeglid samas vormis, mida kasutatakse nende lisamiseks, mis teeb väljundi kustutamiseks otse taaskasutatavaks. iptables -L -v -n lisab paketilugejad, ja need lugejad ütlevad, kas reegel tõesti vastab teie nurjunud päringutele või lihtsalt seisab ahelas.

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

Lugege ahelate poliitikaid, mitte ainult reegleid: -P OUTPUT DROP blokeerib liiklust ka siis, kui ükski reegel ei vasta. Uurige IPv6 eraldi, sest klient, mis paigaldab mõlemad perekonnad, võib jätta IPv6 blokeeringu paigale pärast seda, kui IPv4 reeglid on kadunud, ja sümptom sõltub siis sellest, millist perekonda rakendus eelistab. Kuhu nftables on kasutusel, käivitage ka nft list ruleset; kaks tööriista eksisteerivad koos ühilduvuskihi kaudu ja üks loend ei pruugi näidata iga reeglit, mis võib paketi maha visata.

Kustutage kitsaim objekt, mis riket seletab

Windowsis on esimene samm endiselt tarnija enda eemaldustee: käivitage paigaldaja uuesti ja kasutage parandust või desinstallimist, või käivitage puhastustööriist, kui tarnija selle avaldab. Üle jäänud teenused ja ajastatud ülesanded on tavalised, ja ülesanne, mis käivitab kliendi sisselogimisel, paigaldab selle filtrid järgmisel käivitusel uuesti. Desinstallimine, mis ebaõnnestub kliendi registrivõtme lugemisel, tähendab tavaliselt, et teenus või ülesanne hoiab seda veel, mitte et register on rikutud.

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

Püsivad filtrid on viimane abinõu. Need asuvad HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter all, üks väärtus iga filtri kohta GUID-võtmega. Eksportige esmalt võti, kirjutage üles GUID-id, mille eemaldate, kustutage ainult lahkunud kliendile kuuluvad väärtused, seejärel taaskäivitage, et mootor oma oleku uuesti üles ehitaks. Ärge kustutage tervet võtit ja ärge lülitage Base Filtering Engine’i välja: Windowsi tulemüür ja Defender sõltuvad sellest ning vahetaksite ühe katkestuse hullema vastu.

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

Linuxis võtke rida, mille iptables -S trükib, ja asendage -A väärtusega -D. Ühe tuvastatud reegli kustutamine on parem kui ahela tühjendamine, sest jätab teie enda poliitika puutumata.

sudo iptables -D OUTPUT -p udp -j REJECT

Kui drop asub kasutaja määratud ahelas, kustutage esmalt hüpe sellesse ahelasse ja eemaldage ahel seejärel -X abil. Ahela poliitika seadmine ACCEPT-iks, kui drop-reeglid on veel alles, aitab ainult pakette, mis üldse poliitikaotsuseni jõuavad. Kõigi tabelite tühjendamine on viimane abinõu: see eemaldab ka reeglid, mille lisasite muudel põhjustel, ja kui ufw on sees, jätab teenuse uskuma, et ta omab ahelaid, mida enam ei ole.

Leidke omanik, kes selle tagasi paneb

Pärast kohest parandust otsige kõike, mis võiks oleku taastada. Linuxis kontrollige, kas püsivusüksus on lubatud, kas kliendil on sisselogimisel tulemüüri taastamise säte ja kas /etc all on salvestatud reeglifail. Windowsis kontrollige uuesti algkäivituskirjeid, teenuseid ja ajastatud ülesandeid, seejärel taaskäivitage ja lugege olekut samade käskudega nagu enne.

Kui blokeering naaseb, ei olnud kustutamine lahendus; omanik oli. Kirjutage üles, milline klient või teenus selle paigaldab, ja lülitage funktsioon seal välja, selle asemel et sellega pärast iga lahtiühendamist tulemüüri kihil võidelda.

Kontrollige päris liiklusega, mitte ühe pingiga

Testige nimeotsingut, TCP-ühendust ja värsket brauseriseanssi, seejärel taaskäivitage ja korrake samu kolme kontrolli. Ping, mis töötab, kui HTTPS ebaõnnestub, osutab transpordikihi filtrile, mitte võrgule, ja blokeering, mis naaseb alles pärast taaskäivitust, osutab omanikule, keda te veel ei leidnud.

Hoidke tõendid alles: eksporditud BFE-võti või enne muudatust talletatud iptables -S väljund. Enne kui nimetate selle parandatuks, kinnitage kiht, millelt objekti eemaldasite, omanik, kes võiks selle uuesti paigaldada, olek pärast ühte puhast taaskäivitust ja see, et tavaline veebilehitsemine töötab ilma töötava VPN-protsessita. Juhendi lehel iptables(8) on täpne kustutamise ja poliitika süntaks, kui skriptite puhastuse.