Összeomlott a VPN-alkalmazás: a vészkapcsoló még mindig be van kapcsolva?

Kezdje ott, ahol a felhasználó kezdi: a kliensablak eltűnt, a tálcán lévő ikon elment, a böngésző pedig vagy betölt, vagy nem. Ez a megfigyelés önmagában nem mondja meg, túlélte-e a blokkolás. A válasz azon múlik, melyik komponens tartja a szabályokat, meghalt-e az a komponens az ablakkal együtt, és azon, hogy a platform az alkalmazáson kívül tartja-e a kikényszerítést. Haladjon az ablaktól a folyamathoz, majd a tűzfalhoz, majd a tényleges útvonalhoz.

Ne indítsa újra először; az újraindítás általában megsemmisíti a bizonyítékokat.

Kezdje azzal, ami még fut

Nyissa meg a folyamatok listáját, mielőtt bármihez hozzáér. Az asztali kliens általában egy felhasználói felületi folyamatra és egy szolgáltatásra vagy démonra válik szét, és az első összeomlása nem feltétlenül állítja le a másodikat. Windows alatt a szolgáltatás talán még szerepel a listán, Linux alatt az egység talán még aktív, Android alatt pedig a hozzájárulás megadása után a rendszer birtokolja az alagutat. Olvassa el ezt a három tényt ebben a sorrendben.

Ha a démon él, az alagút valószínűleg szintén él, és a hiányzó ablak csak kozmetika.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

A blokkolást a kikényszerítőnél olvassa, ne az alkalmazásban

Ha a kliens tűzfalszabályok beszúrásával valósítja meg a vészkapcsolóját, azok a szabályok az operációs rendszerhez tartoznak, és túlélik az őket létrehozó folyamatot. Az összeomlás ekkor feloldás nélkül blokkolva hagyja, ami inkább tűnik törött hálózatnak, mint védelemnek. Ha viszont a blokkolás a kliens saját csomagútvonalában él, a folyamat megölése ugyanabban a pillanatban megszünteti a blokkolást.

Az Android ezt megint másként kezeli: az always-on VPN lockdownnal platformbeállítás, tehát a blokkolás az alkalmazásfolyamattól függetlenül fennmarad, és a rendszer újraindíthatja a szolgáltatást. A pontos viselkedéshez nézze meg a platform dokumentációját, ahelyett hogy feltételezné, hogy megegyezik az asztali kliensével.

Különböztesse meg a tiszta kilépést az összeomlástól

Egy normál Quit általában lefuttatja a kliens leállítási útvonalát, amely szándékosan eltávolítja a szabályokat és bezárja az alagutat. Az összeomlás kihagyja ezt az útvonalat, és otthagyja mindazt, amit a kikényszerítő már telepített. A különbség a szabályok időbélyegeiben látszik a folyamat kilépéséhez képest, és abban, hogy létezik-e még gazdátlan, elavult alagút-interfész.

Ez a megkülönböztetés dönti el a helyreállítást: a tiszta kilépéshez új kapcsolat kellhet, míg az összeomláshoz az kellhet, hogy a visszamaradt szabályokat a kliens támogatott javító műveletével távolítsák el.

Állítsa helyre más vezérlők törése nélkül

Indítsa újra a klienst a dokumentált munkafolyamatán keresztül, majd ellenőrizze a követelmény mindkét felét: az alagút viszi a forgalmat, és a blokkolás még érvényes, amikor kell. A teljes tűzfal kiöblítése a kapcsolat visszaszerzéséhez nem kapcsolódó vezérlőket is eltávolít, és ez az üzlet ritkán éri meg.

Ismétlődő összeomlás esetén gyűjtse össze a kliens verzióját, a platform buildjét és a szállító által kért korlátozott naplókat. Egy kliensprofil, egy privát kulcs vagy egy másik fiók teljes kapcsolati naplója nem szükséges az összeomlási jelentéshez, és ezek csatolása egy támogatási esetet adatkezelési problémává tesz.

Egy összeomlás nem bizonyíték szivárgásra. Bizonyíték az a megfigyelt csomag, amely olyan útvonalon távozik, amelyet a szabályzatnak meg kellett volna akadályoznia, abban a pillanatban rögzítve, amikor a kliens le volt állva. Tesztelje ezt szándékosan, ártalmatlan céllal, és írja le, melyik kikényszerítési réteg tartott.