VPN-appen krasjet: er dødmannsknappen fortsatt på?

Start der brukeren starter: klientvinduet er borte, ikonet i systemkurven er forsvunnet, og nettleseren laster eller laster ikke. Den observasjonen alene kan ikke fortelle om blokkeringen overlevde. Svaret avhenger av hvilken komponent som holder reglene, om den komponenten døde sammen med vinduet, og om plattformen holder håndhevelsen utenfor programmet. Gå utover fra vinduet til prosessen, deretter til brannmuren, deretter til den faktiske veien.

Ikke start på nytt først; en omstart ødelegger vanligvis bevisene.

Start med det som fortsatt kjører

Åpne prosesslisten før du rører noe. En skrivebordsklient deler seg vanligvis i en brukergrensesnittprosess og en tjeneste eller daemon, og en krasj i den første stopper ikke nødvendigvis den andre. På Windows kan tjenesten fortsatt stå i listen, på Linux kan enheten fortsatt være aktiv, og på Android eies tunnelen av systemet når samtykke først er gitt. Les de tre faktaene i den rekkefølgen.

Er daemonen i live, er tunnelen sannsynligvis også i live, og det manglende vinduet er bare kosmetikk.

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

Les blokkeringen hos håndheveren, ikke i appen

Hvis klienten implementerer dødmannsknappen sin ved å sette inn brannmurregler, tilhører de reglene operativsystemet og overlever prosessen som opprettet dem. En krasj lar deg da stå blokkert uten noe grensesnitt for å slå det av, og det ser mer ut som et ødelagt nettverk enn som en beskyttelse. Hvis blokkeringen i stedet bor inne i klientens egen pakkevei, fjerner drapet på prosessen blokkeringen i samme øyeblikk.

Android håndterer dette igjen annerledes: always-on VPN med lockdown er en plattforminnstilling, så blokkeringen består uavhengig av app-prosessen, og systemet kan starte tjenesten på nytt. Slå opp i plattformdokumentasjonen for den nøyaktige oppførselen i stedet for å anta at den samsvarer med en skrivebordsklient.

Skill en ren avslutning fra en krasj

En vanlig Quit kjører vanligvis klientens avslutningsvei, som fjerner regler og lukker tunnelen med vilje. En krasj hopper over den veien og lar alt stå som håndheveren allerede har installert. Forskjellen vises i tidsstemplene til reglene relativt til prosessens avslutning, og i om det fortsatt finnes et foreldreløst tunellgrensesnitt.

Den forskjellen avgjør gjenopprettingen din: en ren avslutning kan trenge en ny tilkobling, mens en krasj kan kreve at de gjenværende reglene fjernes via klientens støttede reparasjonshandling.

Gjenopprett uten å bryte andre kontroller

Start klienten på nytt via dens dokumenterte arbeidsflyt, og kontroller deretter begge halvdelene av kravet: tunnelen bærer trafikk, og blokkeringen gjelder fortsatt når den skal. Å skylle hele brannmuren for å få tilbake tilkoblingen fjerner også urelaterte kontroller, og den byttehandelen er sjelden verdt det.

Ved en gjentatt krasj, samle inn klientversjonen, plattformbyggingen og de begrensede loggene leverandøren ber om. En klientprofil, en privat nøkkel eller en full tilkoblingslogg for en annen konto er ikke nødvendig i en krasjrapport, og å ta det med gjør en støttesak til et datahåndteringsproblem.

Én krasj er ikke bevis på en lekkasje. Bevis er en observert pakke som forlater via en vei som policyen skulle ha hindret, fanget i det øyeblikket klienten var nede. Test det med vilje, med en ufarlig destinasjon, og skriv ned hvilket håndhevelseslag som holdt.