Aplikace VPN spadla: je nouzový vypínač pořád zapnutý?

Začněte tam, kde začíná uživatel: okno klienta je pryč, ikona v oznamovací oblasti zmizela a prohlížeč buď načítá, nebo nenačítá. Samotné toto pozorování vám neřekne, zda blokace přežila. Odpověď závisí na tom, která komponenta drží pravidla, zda tato komponenta zemřela spolu s oknem a zda platforma drží vynucování mimo aplikaci. Jděte od okna k procesu, pak k firewallu, pak ke skutečné cestě.

Nerestartujte jako první; restart obvykle zničí důkazy.

Začněte tím, co ještě běží

Otevřete seznam procesů, než se čehokoli dotknete. Desktopový klient se obvykle dělí na proces uživatelského rozhraní a službu nebo démona, a pád prvního nutně nezastaví druhý. Ve Windows může být služba stále v seznamu, v Linuxu může být jednotka stále aktivní a v Androidu tunel vlastní systém, jakmile je udělen souhlas. Přečtěte si tyto tři skutečnosti v tomto pořadí.

Pokud je démon živý, tunel je pravděpodobně také živý a chybějící okno je jen kosmetika.

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

Čtěte blokaci od vynucovatele, ne od aplikace

Pokud klient svůj nouzový vypínač provádí vkládáním pravidel firewallu, tato pravidla patří operačnímu systému a přežijí proces, který je vytvořil. Pád vás pak nechá zablokované bez rozhraní, jak to vypnout, což vypadá jako rozbitá síť, nikoli jako ochrana. Pokud blokace naopak žije uvnitř vlastní cesty paketů klienta, zabití procesu blokaci odstraní ve stejný okamžik.

Android to řeší zase jinak: always-on VPN s lockdownem je nastavení platformy, takže blokace přetrvává nezávisle na procesu aplikace a systém může službu restartovat. Přesné chování si ověřte v dokumentaci platformy, místo abyste předpokládali, že odpovídá desktopovému klientovi.

Rozlište čistý odchod od pádu

Běžné Quit obvykle spustí vypínací cestu klienta, která pravidla záměrně odstraní a tunel zavře. Pád tuto cestu přeskočí a nechá vše, co vynucovatel už nainstaloval. Rozdíl je vidět v časových značkách pravidel vůči ukončení procesu a v tom, zda stále existuje zastaralé rozhraní tunelu bez vlastníka.

Rozhoduje to o vaší obnově: čistý odchod může vyžadovat nové připojení, kdežto pád může vyžadovat odstranění zbylých pravidel podporovanou opravnou akcí klienta.

Obnovte se bez rozbití dalších kontrol

Restartujte klienta přes jeho dokumentovaný postup a pak zkontrolujte obě poloviny požadavku: tunel přenáší provoz a blokace se stále uplatňuje, když má. Propláchnutí celého firewallu kvůli obnově konektivity odstraní i nesouvisející kontroly a tento obchod se málokdy vyplatí.

Při opakovaném pádu seberte verzi klienta, build platformy a omezené logy, které dodavatel žádá. Profil klienta, soukromý klíč nebo úplný log připojení jiného účtu pro hlášení o pádu nejsou potřeba a jejich přiložení mění případ podpory na problém se zpracováním dat.

Jeden pád není důkaz úniku. Důkazem je pozorovaný paket, který odchází cestou, jíž měla politika zabránit, zachycený v okamžiku, kdy byl klient vypnutý. Otestujte to záměrně, s neškodným cílem, a zapište, která vrstva vynucování vydržela.