Menuen tilbyder Afbryd, vinduet har en lukkeknap, og jobliste tilbyder Afslut opgave. Hver af dem ser ud som en måde at stoppe VPN'en på, og hver af dem kan efterlade maskinen i en anden tilstand. En kan stoppe tunnelen, mens en blokering bliver stående, en anden kan rydde alt op som en del af en ordentlig afslutning, og en tredje kan blot skjule grænsefladen, mens baggrundskomponenten fortsætter med at køre. At behandle dem som synonymer er netop, hvordan en privatlivstest når den forkerte konklusion om, hvad der skete.

Klientens dokumentation er det eneste pålidelige sted at lære, hvad der er hvad.

Fire kontroller, muligvis fire adfærdsmønstre

Afbryd river normalt tunnelen ned, mens klienten forbliver i hukommelsen, hvilket betyder, at en tjeneste, en komponent i proceslinjen eller en regel for kill switch kan overleve klikket. Derefter bliver mange klienter ved med at blokere trafik, fordi deres politik siger, at enheden ikke må falde tilbage til direkte adgang, mens klienten er til stede. Den adfærd ligner et ødelagt netværk og er en bevidst beskyttelse.

Afslut skal afslutte programmet, og en velopdragen klient fjerner sine regler på vej ud. Nogle design efterlader i stedet en separat hjælper, der håndhæver politikken, og det er et valg, ikke en fejl. At lukke vinduet er en grænsefladehandling uden defineret virkning på tunnelen, og Pause, hvor det tilbydes, er en fjerde adfærd med sine egne regler.

Et udfald på serversiden er en helt femte vej, og det er den, brugerne faktisk oftest møder.

Læs tilstanden før og efter hver handling

Registrér proceslisten, tjenestens tilstand og firewall-reglerne før handlingen, og gentag derefter registreringen straks efter. At sammenligne de to lister viser, hvad kontrollen reelt gjorde, uden at stole på grænsefladens egen beskrivelse.

systemctl status wg-quick@wg0 --no-pager
pgrep -a -f 'openvpn|wireguard|vpnagent'
ip link show | grep -E 'tun|wg'
nft list ruleset | grep -E 'drop|reject' | head -20
scutil --nc list

Hvis reglerne forsvinder sammen med processen, var det klienten, der ejede dem. Hvis reglerne bliver stående, mens processen er væk, er det noget andet, der håndhæver politikken, og at finde den komponent kommer før enhver ændring. Registrér tjenestens tilstand i samme øjeblik, for en stoppet grænseflade siger intet om en systemtjeneste.

En manuel afbrydelse er ikke et nedbrud

Afbryd kører den tilsigtede nedlukningsvej, og et nedbrud springer den over. Resultater fra det ene overføres derfor ikke til det andet, så en test, der brugte et menupunkt, kan ikke understøtte en påstand om adfærd, når klienten dør.

På samme måde siger et nedbrud intet om en godkendt midlertidig pause. Hold de tre spørgsmål adskilt i testplanen og i alt, hvad der skrives ned bagefter. Nedlukningsvejen forklarer også, hvorfor en ren afslutning kan fjerne regler, som et nedbrud efterlader. Samme knap, anden kode, andet bevis.

Vælg den utilgængelige tilstand, du faktisk har brug for

Hvis trafik skal forblive blokeret, hver gang tunnelen er nede, skal du verificere det krav under den konkrete handling, du bekymrer dig om, med ufarlig trafik til en kendt destination. Medtag undtagelser for programmer og for det lokale netværk, fordi håndhævelse på hele enheden ofte er snævrere, end navnet antyder. Bekræft derefter, hvad der sker efter en genstart, for det er der, forældet tilstand normalt dukker op.

Hvis målet er almindelig direkte adgang, skal du bruge den dokumenterede kontrol i stedet for at dræbe processer eller slå hele firewallen fra. Forældede regler efterladt af en afbrudt afslutning er et andet problem end en bevidst låsning, og de kræver en anden genopretning.

Skriv ned, hvilken komponent der stoppede: tunnelen, det synlige program eller det lag, der håndhæver politikken. Den ene sætning forebygger det meste af den forvirring, disse kontroller skaber.

Relaterede artikler