A kill switch a VPN leválasztása után is blokkolja a forgalmat

Az alagút eltűnt, a hálózati ikon normálisnak látszik, és semmi sem töltődik be. Leválasztotta a VPN-t, eltávolította vagy újraindította, és a megszakítás alatt védő blokk még mindig áll. Az ügyfélablak nem tudja megmagyarázni, mert nem az ügyfél blokkolja önt: a döntést az ön nevében írták a kernelbe, és semmi nem maradt hátra az eltávolításához. Windowson ez az állapot a Windows Filtering Platformban lakik; Linuxon iptables vagy nftables szabálykészlet, gyakran egy pillanatképpel, amelyet a rendszerindítás újrajátszik. A következő az általam használt sorrend: olvassa ki az állapotot, törölje a legszűkebb objektumot, amely a hibát magyarázza, majd keressen mindent, ami újra meg újra visszateszi.

A kill switch kernelállapot, nem beállítás

Az asztali kliensek szűrők hozzáadásával valósítják meg a blokkolást, amelyek az alagúton kívüli forgalmat elutasítják. Windowson ezek WFP-szűrők a kapcsolat-átirányítási és a szállítási rétegen, és némelyikük állandó: a Base Filtering Engine házirend-tárában rögzülnek, és a gép indításakor helyreállnak, mielőtt bármilyen VPN-szoftver futna. A kliensek abban különböznek, mikor tisztítanak. Van, amelyik leválasztáskor eltávolítja a szűrőket, más csak tiszta kilépéskor, és megint más csak akkor, ha előbb kikapcsolják a kill switch-et. Távolítsa el a blokk aktív állapotában, vagy ölje meg a folyamatot, és a szűrők megmaradnak.

A Linux megfelelője egy drop vagy reject szabály a kimeneti útvonalon, néha továbbítási szabály, néha megváltoztatott láncházirend. Ezek a szabályok túlélik a hozzáadó folyamatot, mert kernelállapotok: ölje meg a klienst, rontsa el vagy szakítsa meg az áramot, és a kernel tovább dobálja a csomagokat, és semmi nem marad az visszavonásukra. Egy perzisztencia-csomag második állandósági réteget ad azzal, hogy pillanatképet készít az aktuális szabálykészletről, és indításkor helyreállítja, így a következő indítás már telepített blokkal kezdődik.

A WFP-állapotot olvassa ki, mielőtt bármit törölne

A Windows hozza a szükséges eszközöket. Futtasson emelt szintű parancssort, és mentse ki a platform állapotát; a mentés wfpstate.xml néven érkezik a munkakönyvtárba.

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

Keresse az XML-ben a távozott szállító nevét, a Block műveletet és a réteget. A kapcsolat-átirányítási és szállítási szűrők azok, amelyek a szokásos forgalmat megtörik; a fogadás-elfogadás rétegén lévő szűrő általában nem az ön oka. Ha a Base Filtering Engine egyáltalán nem fut, keressen máshol, mert semmi más nem tudja érvényesíteni ezeket a szűrőket.

Ellenőrizze a tűzfal szokásos nézetét is, mert a legtöbb ember csak az egyiket vizsgálja a kettő közül:

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

Ha a beépített profilok be vannak kapcsolva, és egyetlen szabály sem illeszkedik a hibás forgalomra, a blokk harmadik féltől származó szolgáltatótól jön, nem a Windows tűzfalától. Ez a különbség dönti el, melyik eszközt használja a javításhoz.

A Linux-szabályokat abban a szintaxisban olvassa, amellyel törölni fog

iptables -S ugyanabban a formában írja ki a szabályokat, amelyben hozzáadják őket, így a kimenet közvetlenül újrahasználható törléshez. iptables -L -v -n csomagszámlálókat ad, és ezek a számlálók megmondják, hogy egy szabály valóban illeszkedik-e a sikertelen kéréseihez, vagy csak ül a láncban.

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

A láncházirendeket olvassa, ne csak a szabályokat: -P OUTPUT DROP akkor is blokkolja a forgalmat, ha egyetlen szabály sem illeszkedik. Vizsgálja külön az IPv6-ot, mert a mindkét családot telepítő kliens az IPv4-szabályok eltűnése után is hagyhatja az IPv6-blokkot, és a tünet akkor attól függ, melyik családot részesíti előnyben az alkalmazás. Ahol nftables van használatban, futtassa a nft list ruleset parancsot is; a két eszköz kompatibilitási rétegen keresztül él együtt, és egy lista nem feltétlenül mutat meg minden szabályt, amely csomagot dobhat.

Törölje a legszűkebb objektumot, amely a hibát magyarázza

Windowson az első lépés továbbra is a szállító saját eltávolítási útvonala: futtassa újra a telepítőt, és használja a javítást vagy az eltávolítást, vagy futtassa a tisztítóeszközt, ha a szállító közzétesz egyet. A visszamaradt szolgáltatások és ütemezett feladatok gyakoriak, és a bejelentkezéskor a klienst indító feladat a következő indításkor újratelepíti a szűrőit. A kliens beállításjegyzék-kulcsának olvasásakor meghiúsuló eltávolítás általában azt jelenti, hogy egy szolgáltatás vagy feladat még fogja, nem azt, hogy a beállításjegyzék sérült.

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

Az állandó szűrők az utolsó eszköz. A HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter alatt élnek, szűrőnként egy érték GUID-kulccsal. Először exportálja a kulcsot, jegyezze fel az eltávolított GUID-okat, csak a távozott klienshez tartozó értékeket törölje, majd indítsa újra, hogy a motor újraépítse az állapotát. Ne törölje a teljes kulcsot, és ne tiltsa le a Base Filtering Engine-t: a Windows tűzfal és a Defender függ tőle, és egy kiesést cserélne egy rosszabbra.

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

Linuxon vegye a iptables -S által kiírt sort, és cserélje a -A-t -D-ra. Az egyetlen azonosított szabály törlése jobb, mint egy lánc kiürítése, mert érintetlenül hagyja a saját házirendjét.

sudo iptables -D OUTPUT -p udp -j REJECT

Ha a drop felhasználó által meghatározott láncban él, először törölje az arra a láncra mutató ugrást, majd távolítsa el a láncot a -X paranccsal. Egy láncházirend ACCEPT-re állítása, miközben drop-szabályok még jelen vannak, csak azoknak a csomagoknak segít, amelyek egyáltalán elérik a házirend-döntést. Az összes tábla kiürítése az utolsó eszköz: eltávolítja a más okból hozzáadott szabályokat is, és bekapcsolt ufw mellett azt hagyja a szolgáltatásnak hinni, hogy olyan láncok birtokában van, amelyek már nem léteznek.

Keresse meg a tulajdonost, aki visszateszi

A közvetlen javítás után keressen mindent, ami visszaállíthatná az állapotot. Linuxon ellenőrizze, hogy engedélyezve van-e egy perzisztencia-egység, van-e a kliensnek bejelentkezéskor tűzfal-visszaállítási beállítása, és létezik-e mentett szabályfájl a /etc alatt. Windowson ismét ellenőrizze az indítási bejegyzéseket, a szolgáltatásokat és az ütemezett feladatokat, majd indítsa újra, és olvassa ki az állapotot ugyanazokkal a parancsokkal, mint korábban.

Ha a blokk visszatér, nem a törlés volt a megoldás; a tulajdonos volt az. Jegyezze fel, melyik kliens vagy szolgáltatás telepíti, és ott kapcsolja ki a funkciót, ahelyett hogy minden leválasztás után a tűzfal rétegén harcolna vele.

Valódi forgalommal ellenőrizze, ne egyetlen pinggel

Tesztelje a névfeloldást, egy TCP-kapcsolatot és egy friss böngészőmunkamenetet, majd indítsa újra, és ismételje meg ugyanazt a három ellenőrzést. Az a ping, amely működik, miközben a HTTPS meghiúsul, szállítási rétegbeli szűrőre utal, nem a hálózatra, és az a blokk, amely csak az újraindítás után jelenik meg újra, olyan tulajdonosra utal, amelyet még nem talált meg.

Őrizze meg a bizonyítékokat: az exportált BFE-kulcsot vagy a változás előtt rögzített iptables -S kimenetet. Mielőtt javítottnak nevezné, erősítse meg a réteget, amelyről az objektumot eltávolította, a tulajdonost, aki újratelepítheti, az egyetlen tiszta újraindítás utáni állapotot, és hogy a szokásos böngészés futó VPN-folyamat nélkül működik. Az iptables(8) kézikönyvoldal tartalmazza a pontos törlési és házirend-szintaxist, ha szkripteli a tisztítást.