Afsluiten of verbreken: twee verschillende VPN-uitkomsten

Het menu biedt Verbreken, het venster heeft een sluitknop en Taakbeheer biedt Taak beëindigen. Elk lijkt een manier om de VPN te stoppen, en elk kan de machine in een andere staat achterlaten. Het ene stopt misschien de tunnel terwijl een blokkade blijft staan, het andere ruimt alles op als onderdeel van een nette afsluiting, en een derde verbergt mogelijk alleen de interface terwijl het achtergrondonderdeel blijft draaien. Ze als synoniemen behandelen is precies hoe een privacy-test tot de verkeerde conclusie komt over wat er is gebeurd.

De documentatie van de client is de enige betrouwbare plek om te leren wat wat is.

Vier bedieningselementen, mogelijk vier gedragingen

Verbreken breekt meestal de tunnel af terwijl de client in het geheugen blijft, wat betekent dat een service, een systeemvakonderdeel of een regel voor de killswitch de klik kan overleven. Veel clients blijven daarna verkeer blokkeren omdat hun beleid zegt dat het apparaat niet mag terugvallen op directe toegang zolang de client aanwezig is. Dat gedrag lijkt op een kapot netwerk en is bewuste bescherming.

Afsluiten is bedoeld om de toepassing te beëindigen, en een welgemanierde client verwijdert zijn regels bij het afsluiten. Sommige ontwerpen laten in plaats daarvan een aparte helper achter die het beleid afdwingt, en dat is een keuze, geen defect. Het venster sluiten is een interface-actie zonder vastgesteld effect op de tunnel, en Pauzeren is, waar het wordt aangeboden, een vierde gedrag met eigen regels.

Een storing aan de serverkant is een heel vijfde pad, en dat is degene die gebruikers in de praktijk het vaakst tegenkomen.

Lees de staat voor en na elke actie

Leg de proceslijst, de servicestatus en de firewallregels vast vóór de actie, en herhaal de opname direct daarna. Het vergelijken van de twee lijsten laat zien wat het bedieningselement echt deed, zonder te vertrouwen op de beschrijving van de interface zelf.

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

Verdwijnen de regels samen met het proces, dan waren ze van de client. Blijven de regels staan terwijl het proces weg is, dan dwingt iets anders het beleid af, en dat onderdeel vinden komt vóór elke wijziging. Leg de servicestatus op hetzelfde moment vast, want een gestopte interface zegt niets over een systeemservice.

Handmatig verbreken is geen crash

Verbreken doorloopt het bedoelde afsluitpad, en een crash slaat dat over. Resultaten van het ene gaan daarom niet over naar het andere, dus een test met een menu-item kan geen bewering over gedrag ondersteunen wanneer de client sterft.

Op dezelfde manier zegt een crash niets over een goedgekeurde tijdelijke pauze. Houd die drie vragen apart in het testplan en in alles wat daarna wordt opgeschreven. Het afsluitpad verklaart ook waarom een nette afsluiting regels kan verwijderen die een crash achterlaat. Dezelfde knop, andere code, ander bewijs.

Kies de niet-beschikbare staat die je echt nodig hebt

Als verkeer geblokkeerd moet blijven wanneer de tunnel platligt, verifieer die eis dan tijdens de specifieke actie die je belangrijk vindt, met onschadelijk verkeer naar een bekend doel. Neem uitzonderingen voor toepassingen en uitzonderingen voor het lokale netwerk op, want handhaving voor het hele apparaat is vaak smaller dan de naam suggereert. Bevestig daarna wat er na een herstart gebeurt, want dan duikt verouderde staat meestal op.

Als het doel gewone directe toegang is, gebruik dan het gedocumenteerde bedieningselement in plaats van processen te doden of de hele firewall uit te schakelen. Verouderde regels die een onderbroken afsluiting achterlaat, zijn een ander probleem dan een bewuste vergrendeling, en ze vragen een ander herstel.

Schrijf op welk onderdeel stopte: de tunnel, de zichtbare toepassing of de laag die het beleid afdwingt. Die ene zin voorkomt het grootste deel van de verwarring die deze bedieningselementen veroorzaken.