Een VPN-killswitch testen zonder je echte accounts

Je hebt geen echt account nodig om erachter te komen of een killswitch standhoudt; juist het account brengt de test in gevaar. De controle maakt een kort venster waarin verkeer wel of niet buiten de tunnel kan gaan, dus de lading moet iets zijn dat je kunt missen. Ik doe dit nu met een lokpagina en een reservebrowserprofiel, en dat geeft een duidelijker antwoord dan de routine met browser en webmail die ik eerder gebruikte. Hierna volg ik dezelfde volgorde die de client toont: de instelling, de bestemming, de overgang en dan het bewijs.

De test beantwoordt een smalle vraag: kan deze toepassing tijdens deze overgang het netwerk buiten de tunnel bereiken? het zegt niets over de vraag of de rest van het beleid verstandig is. Houd de scope zo klein en het resultaat is het opschrijven waard.

Vind de schakelaar en zijn bereik in de client

Open de client en zoek de blokkeringsinstelling voordat je de netwerkstatus wijzigt. Fabrikanten noemen het verschillend: killswitch, lockdownmodus, netwerkvergrendeling, verkeer buiten de tunnel blokkeren. Het label vertelt minder dan de opties erbinnen. Wat telt is of de blokkade altijd geldt of alleen wanneer de app vindt dat de tunnel net is mislukt, en of zij alle toepassingen of een gekozen lijst dekt.

Som daarna de overgangen op die je client echt kan uitvoeren. Een door de gebruiker gestarte verbreking, de app afsluiten en contact met de server verliezen zijn in de meeste clients drie verschillende codepaden, en ze delen niet een blokkeringsbeleid. Sommige heffen de blokkade op als de app afsluit. Andere laten filterregels staan tot iets ze verwijdert. Lees de instellingenreferentie van de fabrikant voor jouw build in plaats van aan te nemen, en schrijf op welke van de drie je test.

Leg ook het profiel vast: protocol, adresfamilies en of split-tunneling aanstaat. Een claim over het hele apparaat is betekenisloos als het profiel bewust een paar toepassingen uitsluit, en een uitsluiting die je zelf instelde is geen lek. De instellingenreferentie van OpenVPN Connect is zo'n pagina die benoemt welke schakelaar welk gedrag verandert, al verschillen de labels per client.

Kies een lokbestemming die ook zonder tunnel werkt

De lokpagina heeft twee eigenschappen nodig, en het overslaan van een van beide levert een onleesbaar resultaat op. Ze moet rechtstreeks bereikbaar zijn wanneer de tunnel omlaag is en de blokkade uit, anders kan de melding dat ze niet meer antwoordt gewoon betekenen dat de host weg is. En ze mag geen login, cookie of betaling vragen, zodat een lek een logregel kost in plaats van een sessie.

Een statische pagina op een host die je beheert is de schoonste keuze. Een reserve virtuele machine met een gewone HTTP-server is bijna zo goed, en een openbare verbindingscheckpagina werkt als je accepteert dat de beschikbaarheid buiten je controle ligt. Noteer het adres, de poort, de adresfamilie en of het verzoek een naamopzoeking nodig heeft, want elk daarvan wordt een variabele die je later mogelijk moet isoleren.

Leg de basislijn vast voordat je de schakelaar aanraakt. Met de tunnel omhoog moet de lokpagina via de tunnel antwoorden, wat bewijst dat de policy-route werkt. Met de tunnel omlaag en de blokkade uit moet ze rechtstreeks antwoorden, wat bewijst dat de bestemming leeft. Pas dan zegt een fout in de geblokkeerde toestand je iets.

Voer de overgangen in vaste volgorde uit

Neem de overgangen een voor een en geef elk een paar seconden om te settelen, want clients breken in dat gat vaak regels af en bouwen ze opnieuw op. Dezelfde korte controle elke keer houdt de waarnemingen vergelijkbaar:

curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"

De rij met de app afsluiten verdient een eigen run, ook als je de client in normaal gebruik nooit sluit. Als de blokkade bij afsluiten vervalt, geven een crash of een gedwongen update je dezelfde blootstelling, en dat is een feit over de uitrol, niet over je geduld. Op Windows zijn de gelijkwaardige probes Resolve-DnsName decoy.example en curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.

Onderscheid een blokkade van een kapotte resolver

Een pagina die niet laadt heeft meerdere oorzaken, en slechts een daarvan is de schakelaar die werkt. Als de naam niet oplost, heb je geleerd dat DNS geblokkeerd of kapot is, niet dat het datapad geblokkeerd is. Probeer ook een letterlijk adres, zodat het antwoord helemaal niet van resolutie afhangt.

De exitcodes van curl houden die gevallen uit elkaar. 6 is een fout in naamresolutie, 7 betekent dat de verbinding werd geweigerd, 28 is een timeout. Een geblokkeerde route verschijnt meestal als een timeout of weigering tegen een letterlijk adres, terwijl een blokkade van alleen DNS 6 achterlaat en al het andere verbergt. Een gecachte pagina of een captive portal bedriegt het oog, daarom is de exitcode het bewijs, niet het scherm.

Herhaal de probe over IPv6 met een letterlijk adres. Een blokkade die IPv4 dekt en IPv6 negeert is algemeen genoeg om een eigen regel in je notities te verdienen, en een client die IPv6 buiten de tunnel uitzet hoort op beide families schoon te falen.

Leg het bereik vast dat het resultaat dekt

Als de tunnel terug is, bevestig dan het herstel: de lokpagina antwoordt via de tunnel, de resolver geeft antwoorden en het beleid staat waar je het achterliet. Draai daarna de experimenten terug. Een tijdelijke firewallregel, een debugroute of een testprofiel dat blijft staan, verwart de volgende run en kan de app overleven.

Een doorgang dekt een clientbuild, een profiel, een overgang en een adresfamilie. Schrijf die vier op met de uitkomst:

• Clientbuild en platform, en of de instelling per profiel of globaal is.
• Profiel, protocol en eventuele uitsluitingen voor split-tunneling.
• Geteste overgang en hoe je die opriep.
• Adresfamilies en DNS, met curl-exitcodes voor de geblokkeerde en niet-geblokkeerde toestand.

Als er een regel leeg is, is de test niet af. Roaming betekent de rij met de netwerkwijziging herhalen. Een onbeheerde herstart betekent controleren of de regels terugkomen, en dat is een vraag over de herstelvolgorde, niet over de schakelaar. Herhaal de reeks na een clientupdate, want de schakelaars veranderen zelden terwijl het gedrag erachter verandert. Houd de lokpagina bij de hand: er is niets te roteren en de volgende controle kost vijf minuten.