VPN-killswitch: welk verkeer hij blokkeert en wanneer
Herverbinden herstelt een tunnel; een killswitch bepaalt wat er gebeurt zolang die weg is. Test verlies, handmatig loskoppelen, app afsluiten en netwerk wisselen apart.
Twee functies worden met hetzelfde woord beschreven en doen verschillend werk. Automatisch herverbinden probeert de tunnel terug te halen, en dat kan binnen een seconde lukken terwijl verzoeken in die tussenpoos mislukken. Een killswitch bepaalt wat er met verkeer gebeurt in die tussenpoos. Een client lezen alsof de twee één instelling zijn, is hoe mensen uiteindelijk een pictogram vertrouwen in plaats van een beleid.
Blokkeren en herverbinden zijn aparte beslissingen
De ene client blokkeert alleen wanneer het verlies onverwacht is, herverbindt daarna en heft de blokkade op. Een andere houdt een blokkade op systeemniveau tot iemand een instelling met de hand wijzigt, en een derde ziet een bewuste ontkoppeling als toestemming om gewone toegang te herstellen. Dat zijn drie verschillende gedragingen, en de documentatie van de leverancier zegt welke jouw build implementeert.
Het importeren van een profiel beslist niets over die vraag. Hetzelfde serverprofiel laadt in twee clients met tegenovergesteld blokkeergedrag, omdat het profiel instellingen draagt en geen belofte. Daarom kunnen een selectievakje op de desktop en een schakelaar op de telefoon met vergelijkbare labels ook verschillende regels implementeren. Lees de beschrijving bij het bedieningselement op jouw platform en test daarna wat het doet.
Hetzelfde profiel gedraagt zich anders in twee clients
De instellingen van de OpenVPN Connect-app beschrijven een tunnelmodus die gewoon verkeer alleen tegenhoudt zolang de client een gepauzeerde of herverbindende status meldt, wat smaller is dan een algemene belofte over elke gebeurtenis op elk platform. Lees de genoemde statussen, niet de productnaam. Een beschrijving die voor één clientversie is geschreven, gaat niet over naar de client van een andere leverancier.
Android toont hetzelfde woord voor twee bedieningselementen, omdat altijd-aan-vpn en het blokkeren van verbindingen zonder vpn apart worden gedocumenteerd. Een desktopclient met een vergelijkbaar genoemd selectievakje kan iets smallers of breders implementeren dan elk van beide. Beschouw een gedeeld label in twee menu's als toeval tot beide beschrijvingen zijn gelezen. Beheerde apparaten voegen een derde laag toe, omdat een apparaatprofiel een instelling kan afdwingen die de gebruiker niet ziet en niet kan intrekken.
Vergelijkbare platforminstellingen zijn niet gelijkwaardig
Vergelijk het bedieningselement dat je ziet met het beleid dat werkelijk geldt. Op een beheerd apparaat kan de zichtbare schakelaar grijs zijn, of hij kan aan staan terwijl een profiel op een hoger niveau het omgekeerde afdwingt. Vraag om het effectieve beleid in plaats van het lokale, en krijg het antwoord schriftelijk.
Noteer wat elke laag beweert voordat je iets test, want de twee zijn het vaak oneens en die onenigheid raakt makkelijk zoek zodra de tests beginnen. Een apparaat dat tijdens een test correct blokkeert, blokkeert misschien om een reden die niemand heeft gedocumenteerd.
Voer één gebeurtenis tegelijk uit en noteer de code
Test één gebeurtenis per run, met een onschadelijk verzoek, en maak van elke poging een nieuw verzoek in plaats van een pagina die misschien al in de cache staat. De opdrachten hieronder halen de tunnel neer, vragen een pagina op en laten zien of de interface terugkwam.
ip link set tun0 down
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 https://example.com
ip -brief address show tun0
De tabel koppelt elke actie aan de observatie die ertoe doet en aan het bewijs dat het waard is te bewaren. Een verzoek dat binnen de tijdslimiet faalt, vertelt je dat de blokkade ingreep; een verzoek dat doorkomt, vertelt je dat het verkeer een andere route vond, wat een uitgesloten route kan zijn en geen uitgeschakelde blokkade. Herhaal de hele set na een betekenisvolle software-update of een wijziging in het routebeleid, want beide kunnen de tak veranderen zonder dat een zichtbare instelling beweegt. Uiteindelijk wil je voorspelbaar faalgedrag, geen geruststellend pictogram.
| What I do | What I watch | Evidence to keep |
|---|---|---|
| Bring the tunnel down by hand | Whether a fresh request fails at once | The HTTP code and the client state at that second |
| Choose Disconnect in the client | Whether ordinary access returns on purpose | The same request succeeding with no tunnel up |
| Quit the app, then reboot | Whether the block outlives the client | A request made from a clean boot |
| Move from Wi-Fi to cellular | Whether DNS and IPv6 follow the policy | The resolver answer, the route table and the code again |
Uitzonderingen, gastportalen en wat een blokkade niet kan
Toegang tot het lokale netwerk is de gebruikelijke uitzondering, en die verandert de reikwijdte van de belofte. Een client kan een printer op hetzelfde subnet bereiken terwijl hij al het andere blokkeert, wat thuis redelijk is en op een gastnetwerk twijfelachtig. Bepaal of je die uitzondering wilt voordat een incident hem voor je ontdekt.
Een strikte blokkade maakt ook inloggen op een gastportaal onhandig, want het portaal is precies het directe verkeer dat de blokkade moet stoppen. Leer de ondersteunde manier om het netwerk te autoriseren, en herstel daarna het beleid bewust in plaats van bedieningselementen uit te zetten tot een pagina laadt. Houd het antwoord van de resolver en de routetabel in dezelfde notitie, zoals hieronder. Wat een killswitch niet kan, is de dienst anoniem maken, want het blokkeren van verkeer buiten de tunnel zegt niets over wat er binnenin gebeurt.
resolvectl query example.com
ss -tunp | grep -v tun0