VPN-appen er styrtet: er din sikkerhedsafbryder stadig slået til?

Begynd der, hvor brugeren begynder: klientvinduet er væk, ikonet i proceslinjen er forsvundet, og browseren indlæser enten eller gør ikke. Den observation alene kan ikke fortælle, om blokeringen overlevede. Svaret afhænger af, hvilken komponent der holder reglerne, om den komponent døde sammen med vinduet, og om platformen holder håndhævelsen uden for programmet. Gå udad fra vinduet til processen, derefter til firewallen, derefter til den faktiske vej.

Genstart ikke først; en genstart ødelægger som regel beviserne.

Begynd med det, der stadig kører

Åbn proceslisten, før du rører noget. En skrivebordsklient deler sig som regel i en brugergrænsefladeproces og en tjeneste eller daemon, og et nedbrud i den første standser ikke nødvendigvis den anden. På Windows er tjenesten måske stadig opført, på Linux er uniten måske stadig aktiv, og på Android ejes tunnelen af systemet, når der først er givet samtykke. Læs de tre fakta i den rækkefølge.

Er daemonen i live, er tunnelen sandsynligvis også i live, og det manglende vindue er kun kosmetik.

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

Læs blokeringen hos håndhæveren, ikke hos appen

Hvis klienten implementerer sin sikkerhedsafbryder ved at indsætte firewallregler, tilhører de regler styresystemet og overlever den proces, der oprettede dem. Så efterlader et nedbrud dig blokeret uden nogen grænseflade til at slå det fra, og det ligner et ødelagt netværk mere end en beskyttelse. Ligger blokeringen i stedet inde i klientens egen pakkevej, fjerner drabet på processen blokeringen i samme øjeblik.

Android håndterer det igen anderledes: always-on VPN med lockdown er en platformindstilling, så blokeringen består uafhængigt af appprocessen, og systemet kan genstarte tjenesten. Slå op i platformsdokumentationen for den præcise adfærd i stedet for at antage, at den svarer til en skrivebordsklient.

Skeln en ren afslutning fra et nedbrud

Et normalt Quit kører som regel klientens nedlukningsvej, som bevidst fjerner regler og lukker tunnelen. Et nedbrud springer den vej over og efterlader alt, hvad håndhæveren allerede har installeret. Forskellen ses i reglernes tidsstempler i forhold til processens afslutning, og i om der stadig findes en forældet tunnelegrænseflade uden ejer.

Den forskel afgør din genopretning: en ren afslutning kan kræve en ny forbindelse, mens et nedbrud kan kræve, at de resterende regler fjernes via klientens understøttede reparationshandling.

Genopret uden at bryde andre kontroller

Genstart klienten gennem dens dokumenterede arbejdsgang, og kontrollér derefter begge halvdele af kravet: tunnelen bærer trafik, og blokeringen gælder stadig, når den skal. At skylle hele firewallen for at få forbindelsen tilbage fjerner også urelaterede kontroller, og den handel er sjældent værd at gøre.

Ved et gentaget nedbrud, indsaml klientversionen, platformens build og de afgrænsede logs, som leverandøren beder om. En klientprofil, en privat nøgle eller en fuld forbindelseslog for en anden konto er ikke nødvendig i en nedbrudsrapport, og at inkludere det gør en supportsag til et datahåndteringsproblem.

Et enkelt nedbrud er ikke bevis på en lækage. Bevis er en observeret pakke, der forlader ad en vej, som politikken skulle have forhindret, fanget i det øjeblik klienten var nede. Test det bevidst, med en uskadelig destination, og skriv ned, hvilket håndhævelseslag der holdt.