VPN-rakendus jooksis kokku: kas turvalüliti on endiselt sisse lülitatud?

Alustage sealt, kust kasutaja alustab: kliendiaken on kadunud, süsteemisalve ikoon kadus ja brauser kas laeb või ei lae. See tähelepanek üksi ei ütle teile, kas blokeering jäi püsima. Vastus sõltub sellest, milline komponent reegleid hoiab, kas see komponent suri koos aknaga ja kas platvorm hoiab rakendamist väljaspool rakendust. Liikuge aknast protsessi juurde, siis tulemüüri juurde, siis tegeliku teekonna juurde.

Ärge taaskäivitage esimese asjana; taaskäivitamine hävitab tavaliselt tõendid.

Alustage sellest, mis veel töötab

Avage protsesside loend enne, kui midagi puutute. Töölaua klient jaguneb tavaliselt kasutajaliidese protsessiks ning teenuseks või deemoniks, ja esimese kokkujooksmine ei peata tingimata teist. Windowsis võib teenus veel loendis olla, Linuxis võib üksus veel aktiivne olla ja Androidis kuulub tunnel süsteemile, kui nõusolek on antud. Lugege neid kolme fakti selles järjekorras.

Kui deemon on elus, on tunnel tõenäoliselt samuti elus ja puuduv aken on vaid kosmeetika.

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

Lugege blokeeringut rakendajalt, mitte rakendusest

Kui klient rakendab oma turvalülitit tulemüürireeglite sisestamisega, kuuluvad need reeglid operatsioonisüsteemile ja jäävad püsima ka pärast nende loonud protsessi. Siis jätab kokkujooksmine teid blokeerituks ilma ühegi liideseta selle väljalülitamiseks, mis näeb välja pigem katkise võrguna kui kaitsena. Kui blokeering elab seevastu kliendi enda paketiteekonnas, eemaldab protsessi tapmine blokeeringu samal hetkel.

Android käsitleb seda jälle teisiti: always-on VPN koos lockdowniga on platvormi seade, seega püsib blokeering rakenduse protsessist sõltumatult ja süsteem võib teenuse uuesti käivitada. Täpse käitumise kohta vaadake platvormi dokumentatsiooni, selle asemel et eeldada, et see vastab töölaua kliendile.

Eristage puhast väljumist kokkujooksmisest

Tavaline Quit käivitab tavaliselt kliendi sulgemistee, mis eemaldab reeglid ja sulgeb tunneli meelega. Kokkujooksmine jätab selle tee vahele ja jätab alles kõik, mille rakendaja on juba paigaldanud. Erinevus ilmneb reeglite ajatemplites protsessi väljumise suhtes ja selles, kas omanikuta vana tunneli liides on veel olemas.

See erinevus otsustab teie taastamise: puhas väljumine võib vajada uut ühendust, samas kui kokkujooksmine võib nõuda, et ülejäänud reeglid eemaldataks kliendi toetatud parandustoiminguga.

Taastage muid kontrolle rikkumata

Taaskäivitage klient selle dokumenteeritud töövoo kaudu ja kontrollige seejärel nõude mõlemat poolt: tunnel kannab liiklust ja blokeering kehtib endiselt siis, kui peab. Kogu tulemüüri tühjendamine ühenduvuse taastamiseks eemaldab ka mitteseotud kontrolle ja see vahetus tasub end harva ära.

Korduva kokkujooksmise korral koguge kliendi versioon, platvormi build ja piiratud logid, mida tarnija küsib. Kliendiprofiil, privaatvõti või teise konto täielik ühenduslogi ei ole kokkujooksmise aruande jaoks vajalikud ja nende lisamine muudab tugijuhtumi andmetöötlusprobleemiks.

Üks kokkujooksmine ei ole lekkimise tõend. Tõend on täheldatud pakett, mis väljub teed pidi, mille poliitika pidi takistama, jäädvustatud hetkel, mil klient oli maas. Katsetage seda meelega kahjutu sihtkohaga ja kirjutage üles, milline rakenduskiht pidas.