Ndërprerësi i sigurisë vazhdon të bllokojë trafikun pas shkëputjes së VPN

Tuneli iku, ikona e rrjetit duket normale dhe asgjë nuk ngarkohet. Shkëputët VPN-në, e çinstaluat ose rindezët, dhe bllokimi që duhej t'ju mbronte gjatë një ndërprerjeje qëndron ende. Dritarja e klientit nuk e shpjegon dot, sepse nuk është klienti ai që ju bllokon: vendimi u shkrua në kernel në emrin tuaj dhe asgjë nuk u la pas për ta hequr. Në Windows ajo gjendje ndodhet në Windows Filtering Platform; në Linux është një grup rregullash në iptables ose nftables, shpesh me një pamje që rizbatohet në nisje. Ajo që vijon është rendi që përdor: lexo gjendjen, fshi objektin më të ngushtë që shpjegon dështimin, pastaj gjej çdo gjë që e kthen vazhdimisht aty.

Një ndërprerës sigurie është gjendje e kernelit, jo një cilësim

Klientët e desktopit e zbatojnë bllokimin duke shtuar filtra që refuzojnë trafikun jashtë tunelit. Në Windows ata janë filtra WFP në shtresat connect-redirect dhe transport, dhe disa janë të përhershëm: regjistrohen në depon e politikave të Base Filtering Engine dhe rikthehen kur makina niset, para se të ekzekutohet çdo softuer VPN. Klientët ndryshojnë në momentin kur pastrojnë. Disa i heqin filtrat në shkëputje, disa vetëm në një dalje të pastër, dhe disa vetëm kur ndërprerësi fiket fillimisht. Çinstalo ndërsa bllokimi është aktiv, ose vrit procesin, dhe filtrat mbeten.

Ekuivalenti në Linux është një rregull drop ose reject në rrugën e daljes, ndonjëherë një rregull forwarding, ndonjëherë një politikë zinxhiri e ndryshuar. Ato rregulla jetojnë më gjatë se procesi që i shtoi, sepse janë gjendje e kernelit: vrit klientin, bëje të rrëzohet ose ndërpreje energjinë, dhe kernel-i vazhdon të hedhë paketa pa mbetur asgjë për ta anuluar. Një paketë këmbënguljeje shton një shtresë të dytë përhershmërie duke marrë një pamje të grupit aktual të rregullave dhe duke e rikthyer në nisje, kështu që nisja tjetër fillon me bllokimin tashmë të instaluar.

Lexoni gjendjen WFP përpara se të fshini çdo gjë

Windows vjen me mjetet që ju nevojiten. Hapni një prompt me privilegje dhe nxirrni gjendjen e platformës; dump-i shfaqet si wfpstate.xml në drejtorinë e punës.

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

Kërkoni në XML emrin e ofruesit që iku, një veprim Block dhe shtresën. Filtrat në connect-redirect dhe transport janë ata që prishin trafikun e zakonshëm; një filtër në një shtresë receive-accept zakonisht nuk është shkaku juaj. Nëse Base Filtering Engine nuk punon fare, kërkoni diku tjetër, sepse asgjë tjetër nuk mund t'i zbatojë ata filtra.

Kontrolloni edhe pamjen e zakonshme të firewall-it, pasi shumica e njerëzve inspektojnë vetëm njërën nga të dyja:

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

Kur profilet e integruara janë të ndezura dhe asnjë rregull nuk përputhet me trafikun që dështon, bllokimi vjen nga një ofrues i palës së tretë dhe jo nga Windows Firewall. Ky dallim vendos cilin mjet do të përdorni për riparimin.

Lexoni rregullat e Linux në sintaksën me të cilën do të fshini

iptables -S i printon rregullat në të njëjtën formë me të cilën u shtuan, kështu që dalja mund të ripërdoret drejtpërdrejt për një fshirje. iptables -L -v -n shton numërues paketash, dhe ata numërues ju tregojnë nëse një rregull po përputhet vërtet me kërkesat tuaja që dështojnë apo thjesht po rri në zinxhir.

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

Lexoni politikat e zinxhirëve, jo vetëm rregullat: -P OUTPUT DROP bllokon trafikun edhe kur asnjë rregull nuk përputhet. Inspektoni IPv6 veçmas, sepse një klient që instalon të dy familjet mund të lërë bllokimin IPv6 në vend pasi rregullat IPv4 të jenë zhdukur, dhe simptoma atëherë varet nga cila familje preferohet nga aplikacioni. Aty ku përdoret nftables, ekzekutoni edhe nft list ruleset; dy mjetet bashkëjetojnë përmes një shtrese përputhshmërie, dhe një listim nuk tregon domosdoshmërisht çdo rregull që mund të hedhë një paketë.

Fshini objektin më të ngushtë që shpjegon dështimin

Në Windows hapi i parë është ende rruga e heqjes së vetë ofruesit: ekzekutoni përsëri instaluesin dhe përdorni repair ose uninstall, ose ekzekutoni mjetin e pastrimit nëse ofruesi e publikon. Shërbimet dhe detyrat e planifikuara të mbetura janë të zakonshme, dhe një detyrë që nis klientin në hyrje riinstalon filtrat e tij në nisjen tjetër. Një çinstalim që dështon duke lexuar çelësin e regjistrit të klientit zakonisht do të thotë që një shërbim ose detyrë ende e mban atë, jo që regjistri është i dëmtuar.

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

Filtrat e përhershëm janë mjeti i fundit. Ata ndodhen nën HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, një vlerë për çdo filtër me çelës GUID. Eksportoni së pari çelësin, shënoni GUID-të që hiqni, fshini vetëm vlerat që i përkasin klientit që iku, pastaj rindizni që motori ta rindërtojë gjendjen. Mos e fshini të gjithë çelësin dhe mos e çaktivizoni Base Filtering Engine: Windows Firewall dhe Defender varen prej tij, dhe do të shkëmbenit një ndërprerje me një më të keqe.

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

Në Linux, merrni rreshtin që printon iptables -S dhe zëvendësoni -A me -D. Fshirja e rregullit të vetëm që identifikuat është më mirë se zbrazja e një zinxhiri, sepse politika juaj mbetet e paprekur.

sudo iptables -D OUTPUT -p udp -j REJECT

Nëse drop-i ndodhet në një zinxhir të përcaktuar nga përdoruesi, fshini së pari kërcimin drejt atij zinxhiri dhe pastaj hiqni zinxhirin me -X. Vendosja e politikës së zinxhirit në ACCEPT ndërsa rregullat drop ekzistojnë ende ndihmon vetëm paketat që arrijnë fare në vendimin e politikës. Zbrazja e të gjitha tabelave është mjeti i fundit: heq edhe rregulla që i keni shtuar për arsye të tjera, dhe me ufw aktiv e lë shërbimin të besojë se zotëron zinxhirë që nuk ekzistojnë më.

Gjeni pronarin që e kthen aty

Pas riparimit të menjëhershëm, kërkoni çdo gjë që do ta rikthente gjendjen. Në Linux, kontrolloni nëse një njësi këmbënguljeje është e aktivizuar, nëse klienti ka një cilësim për të rikthyer firewall-in në hyrje dhe nëse ekziston një skedar rregullash i ruajtur nën /etc. Në Windows, kontrolloni përsëri hyrjet e nisjes, shërbimet dhe detyrat e planifikuara, pastaj rindizni dhe rilexoni gjendjen me të njëjtat komanda si më parë.

Nëse bllokimi kthehet, fshirja nuk ishte zgjidhja; pronari ishte. Shënoni cili klient ose shërbim e instalon dhe çaktivizoni funksionin atje, në vend që të luftoni me të në shtresën e firewall-it pas çdo shkëputjeje.

Verifikoni me trafik të vërtetë, jo me një ping të vetëm

Provoni një zgjidhje emri, një lidhje TCP dhe një sesion të ri shfletuesi, pastaj rindizni dhe përsëritni të njëjtat tre kontrolle. Një ping që punon ndërsa HTTPS dështon tregon një filtër në shtresën transport dhe jo rrjetin, dhe një bllokim që rishfaqet vetëm pas rindezjes tregon një pronar që nuk e keni gjetur ende.

Ruani provat: çelësin BFE të eksportuar, ose daljen e iptables -S të kapur përpara ndryshimit. Përpara se ta quani të rregulluar, konfirmoni shtresën nga e cila hoqët objektin, pronarin që mund ta riinstalojë, gjendjen pas një rindezjeje të pastër dhe që shfletimi i zakonshëm punon pa një proces VPN në punë. Faqja e manualit iptables(8) ka sintaksën e saktë të fshirjes dhe të politikës nëse pastrimin e shkruani si skript.