Začnite tam, kde začína používateľ: okno klienta je preč, ikona v oznamovacej oblasti zmizla a prehliadač buď načítava, alebo nenačítava. Samotné toto pozorovanie vám nepovie, či blokácia prežila. Odpoveď závisí od toho, ktorý komponent drží pravidlá, či tento komponent zomrel spolu s oknom a či platforma drží vynucovanie mimo aplikácie. Prejdite od okna k procesu, potom k firewallu, potom k skutočnej ceste.

Nereštartujte ako prvé; reštart zvyčajne zničí dôkazy.

Začnite tým, čo ešte beží

Otvorte zoznam procesov, skôr než sa čohokoľvek dotknete. Desktopový klient sa zvyčajne delí na proces používateľského rozhrania a službu alebo démona, a pád prvého nemusí zastaviť druhý. Vo Windows môže byť služba stále v zozname, v Linuxe môže byť jednotka stále aktívna a v Androide tunel patrí systému, keď je udelený súhlas. Prečítajte si tieto tri fakty v tomto poradí.

Ak je démon živý, tunel je pravdepodobne tiež živý a chýbajúce okno je len 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

Blokáciu čítajte u vynucovateľa, nie v aplikácii

Ak klient realizuje svoj núdzový vypínač vkladaním pravidiel firewallu, tie pravidlá patria operačnému systému a prežijú proces, ktorý ich vytvoril. Pád vás potom nechá zablokovaných bez akéhokoľvek rozhrania na vypnutie, čo vyzerá ako pokazená sieť, nie ako ochrana. Ak blokácia naopak žije vnútri vlastnej cesty paketov klienta, zabitie procesu blokáciu odstráni v tej istej chvíli.

Android to rieši zase inak: always-on VPN s lockdownom je nastavenie platformy, takže blokácia pretrváva nezávisle od procesu aplikácie a systém môže službu reštartovať. Presné správanie si overte v dokumentácii platformy, namiesto toho, aby ste predpokladali, že zodpovedá desktopovému klientovi.

Rozlíšte čistý odchod od pádu

Bežné Quit zvyčajne spustí vypínaciu cestu klienta, ktorá pravidlá zámerne odstráni a tunel zavrie. Pád túto cestu preskočí a nechá všetko, čo vynucovateľ už nainštaloval. Rozdiel je vidieť v časových značkách pravidiel voči ukončeniu procesu a v tom, či stále existuje zastarané rozhranie tunela bez vlastníka.

Rozhoduje to o vašej obnove: čistý odchod môže vyžadovať nové pripojenie, kým pád môže vyžadovať odstránenie zvyšných pravidiel podporovanou opravnou akciou klienta.

Obnovte bez rozbitia ďalších kontrol

Reštartujte klienta podľa jeho dokumentovaného postupu a potom skontrolujte obe polovice požiadavky: tunel prenáša prevádzku a blokácia sa stále uplatňuje, keď má. Prepláchnutie celého firewallu kvôli obnove konektivity odstráni aj nesúvisiace kontroly a tento obchod sa málokedy vyplatí.

Pri opakovanom páde zozbierajte verziu klienta, build platformy a obmedzené logy, ktoré žiada dodávateľ. Profil klienta, súkromný kľúč alebo úplný log pripojenia iného účtu nie sú pre hlásenie o páde potrebné a ich priloženie mení prípad podpory na problém so spracovaním údajov.

Jeden pád nie je dôkaz úniku. Dôkazom je pozorovaný paket, ktorý odchádza cestou, ktorej mala politika zabrániť, zachytený v okamihu, keď bol klient vypnutý. Otestujte to zámerne, s neškodným cieľom, a zapíšte, ktorá vrstva vynucovania vydržala.

Súvisiace články