Avsluta eller koppla från: två olika VPN-utfall

Menyn erbjuder Koppla från, fönstret har en stängningsknapp och aktivitetshanteraren erbjuder Avsluta aktivitet. Var och en ser ut som ett sätt att stoppa VPN:en, och var och en kan lämna datorn i ett annat läge. En kan stoppa tunneln medan en blockering står kvar, en annan kan städa upp allt som en del av en snygg avslutning, och en tredje kan bara dölja gränssnittet medan bakgrundskomponenten fortsätter att köras. Att behandla dem som synonymer är precis hur ett integritetstest kommer fram till en felaktig slutsats om vad som hände.

Klientens dokumentation är den enda pålitliga platsen för att lära sig vad som är vad.

Fyra kontroller, möjligen fyra beteenden

Koppla från river vanligtvis ned tunneln medan klienten ligger kvar i minnet, vilket innebär att en tjänst, en komponent i aktivitetsfältet eller en regel för kill switch kan överleva klicket. Många klienter fortsätter sedan att blockera trafik eftersom deras policy säger att enheten inte får falla tillbaka på direkt åtkomst så länge klienten är närvarande. Det beteendet ser ut som ett trasigt nätverk och är avsiktligt skydd.

Avsluta är tänkt att avsluta programmet, och en väluppfostrad klient tar bort sina regler när den avslutas. Vissa lösningar lämnar i stället en separat hjälpare som upprätthåller policyn, och det är ett val, inte en defekt. Att stänga fönstret är en gränssnittsåtgärd utan definierad effekt på tunneln, och Pausa är, där det erbjuds, ett fjärde beteende med egna regler.

Ett avbrott på serversidan är en helt femte väg, och det är den användare i praktiken möter oftast.

Läs läget före och efter varje åtgärd

Registrera processlistan, tjänstens status och brandväggsreglerna före åtgärden och upprepa registreringen direkt efter. Att jämföra de två listorna visar vad kontrollen faktiskt gjorde, utan att lita på gränssnittets egen beskrivning.

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

Om reglerna försvinner tillsammans med processen ägdes de av klienten. Om reglerna står kvar medan processen är borta är det något annat som upprätthåller policyn, och att hitta den komponenten kommer före varje ändring. Registrera tjänstens status i samma ögonblick, för ett stoppat gränssnitt säger ingenting om en systemtjänst.

En manuell frånkoppling är inte en krasch

Koppla från kör den avsedda avstängningsvägen, och en krasch hoppar över den. Resultat från den ena överförs därför inte till den andra, så ett test som använde ett menyval kan inte stödja ett påstående om beteendet när klienten dör.

På samma sätt säger en krasch ingenting om en godkänd tillfällig paus. Håll de tre frågorna åtskilda i testplanen och i allt som skrivs ned efteråt. Avstängningsvägen förklarar också varför en ren avslutning kan ta bort regler som en krasch lämnar kvar. Samma knapp, annan kod, andra bevis.

Välj det otillgängliga läge du faktiskt behöver

Om trafiken måste förbli blockerad varje gång tunneln är nere, verifiera det kravet under den specifika åtgärd du bryr dig om, med ofarlig trafik till en känd destination. Ta med undantag för program och undantag för det lokala nätverket, eftersom upprätthållande för hela enheten ofta är snävare än namnet antyder. Bekräfta sedan vad som händer efter en omstart, för det är då det inaktuella läget brukar dyka upp.

Om målet är vanlig direkt åtkomst, använd den dokumenterade kontrollen i stället för att döda processer eller stänga av hela brandväggen. Inaktuella regler som en avbruten avslutning lämnar är ett annat problem än en avsiktlig låsning, och de behöver en annan återställning.

Skriv ned vilken komponent som stoppade: tunneln, det synliga programmet eller lagret som upprätthåller policyn. Den enda meningen hindrar det mesta av den förvirring som dessa kontroller skapar.