Så testar du en VPN-killswitch utan riktiga konton
Gör ett killswitch-test med en lockbete-sida och en reservprofil: täck varje avbrottstyp, läs curls utgångskoder och skilj en riktig blockering från ett DNS-fel.
Du behöver inget riktigt konto för att ta reda på om en killswitch håller; det är just kontot som testet utsätter för risk. Kontrollen skapar ett kort fönster där trafik kan eller inte kan lämna tunneln, så nyttolasten bör vara något du kan förlora. Jag gör detta nu med en lockbete-sida och en reservprofil i webbläsaren, och det ger ett tydligare svar än rutinen med webbläsare och webbmail som jag använde tidigare. Nedan följer jag samma ordning som klienten visar: inställningen, målet, övergången och sedan beviset.
Testet svarar på en enda smal fråga: kan det här programmet under den här övergången nå nätverket utanför tunneln? det säger inget om huruvida resten av policyn är förnuftig. Håll omfånget så litet och resultatet är värt att skriva ner.
Hitta reglaget och dess omfattning i klienten
Öppna klienten och hitta blockeringsinställningen innan du ändrar något nätverksläge. Tillverkarna kallar den olika: killswitch, låsläge, nätverkslås, blockera trafik utanför tunneln. Etiketten säger mindre än alternativen inuti. Det som avgör är om blockeringen gäller alltid eller bara när appen bedömer att tunneln just har fallerat, och om den täcker alla program eller en vald lista.
Lista sedan de övergångar som din klient faktiskt kan utföra. En användarinitierad frånkoppling, att avsluta appen och att tappa kontakten med servern är tre olika kodvägar i de flesta klienter, och de delar inte en blockeringspolicy. Vissa släpper blockeringen när appen avslutas. Andra lämnar filterregler kvar tills något tar bort dem. Läs tillverkarens inställningsreferens för den version du kör i stället för att anta, och skriv sedan ner vilken av de tre du testar.
Anteckna även profilen: protokoll, adressfamiljer och om delad tunnel är på. Ett påstående om hela enheten är meningslöst om profilen medvetet utesluter några program, och ett undantag du själv konfigurerat är inget läckage. Inställningsreferensen för OpenVPN Connect är en sådan sida som namnger vilket reglage som ändrar vilket beteende, även om etiketterna skiljer sig mellan klienter.
Välj ett lockbete-mål som också fungerar utan tunneln
Lockbetet behöver två egenskaper, och hoppar du över någon av dem blir resultatet oläsligt. Det måste gå att nå direkt när tunneln är nere och blockeringen är av, annars kan att det slutat svara helt enkelt betyda att värden är borta. Och det får inte kräva inloggning, kaka eller betalning, så att ett läckage kostar en loggrow i stället för en session.
En statisk sida på en värd du kontrollerar är det renaste valet. En reserv-virtuell maskin med en vanlig HTTP-server är nästan lika bra, och en offentlig anslutningskontroll fungerar om du accepterar att dess tillgänglighet ligger utanför din kontroll. Anteckna adressen, porten, adressfamiljen och om begäran behöver en namnsökning, eftersom var och en av dem blir en variabel du senare kan behöva isolera.
Fastställ baslinjen innan du rör reglaget. Med tunneln uppe måste lockbetet svara genom tunneln, vilket bevisar att policyvägen fungerar. Med tunneln nere och blockeringen av måste det svara direkt, vilket bevisar att målet lever. Först då säger ett misslyckande i det blockerade läget dig något.
Kör övergångarna i fast ordning
Ta övergångarna en i taget och ge var och en några sekunder att sätta sig, eftersom klienter ofta river och bygger om regler i det glappet. Samma korta kontroll varje gång gör observationerna jämförbara:
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=$?"| Transition | Expected with the block on | Failure signature |
|---|---|---|
| Manual disconnect | Decoy stops answering within seconds | Decoy still returns 200 |
| Server or path failure | Blocked, with no exemption for the old endpoint | Direct access during the gap |
| Quit the app | Client-dependent; record what happens | Block disappears with the process |
| Wi-Fi to Ethernet | Block holds until the tunnel returns | Traffic flows mid-change |
Raden med att avsluta appen förtjänar en egen körning, även om du aldrig stänger klienten i normal användning. Om blockeringen släpper vid avslut ger en krasch eller en påtvingad uppdatering dig samma exponering, och det är ett faktum om driftsättningen, inte om ditt tålamod. På Windows är motsvarande prober Resolve-DnsName decoy.example och curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.
Skilj en blockering från en trasig resolver
En sida som inte laddas har flera orsaker, och bara en av dem är att reglaget fungerar. Om namnet inte löses upp har du lärt dig att DNS är blockerat eller trasigt, inte att datavägen är blockerad. Prova också en litteral adress, så att svaret inte alls beror på uppslagning.
curls utgångskoder håller isär de fallen. 6 är ett fel i namnuppslagningen, 7 betyder att anslutningen nekades, 28 är en timeout. En blockerad väg visar sig oftast som en timeout eller nekad anslutning mot en litteral adress, medan en blockering av bara DNS lämnar 6 och döljer allt annat. En cachad sida eller en captive portal lurar ögat, därför är utgångskoden beviset, inte skärmen.
Upprepa proben över IPv6 med en litteral adress. En blockering som täcker IPv4 och ignorerar IPv6 är vanlig nog att förtjäna en egen rad i dina anteckningar, och en klient som stänger av IPv6 utanför tunneln bör misslyckas rent på båda familjerna.
Anteckna omfånget som resultatet täcker
När tunneln är tillbaka, bekräfta återhämtningen: lockbetet svarar genom tunneln, resolvern returnerar svar och policyn står där du lämnade den. Ångra sedan experimenten. En tillfällig brandväggsregel, en debugväg eller en testprofil som lämnas kvar förvirrar nästa körning och kan överleva appen.
En genomgång täcker en klientversion, en profil, en övergång och en adressfamilj. Skriv ner de fyra tillsammans med utfallet:
- Klientversion och plattform, och om inställningen är per profil eller global.
- Profil, protokoll och eventuella undantag för delad tunnel.
- Testad övergång och hur du utlöste den.
- Adressfamiljer och DNS, med curls utgångskoder för det blockerade och icke-blockerade läget.
Om någon rad är tom är testet inte klart. Roaming innebär att nätverksändringsraden upprepas. En obevakad omstart innebär att kontrollera att reglerna kommer tillbaka, och det är en fråga om återställningsordning, inte om reglaget. Kör om sekvensen efter en klientuppdatering, eftersom reglagen sällan ändras medan beteendet bakom dem gör det. Behåll lockbetet: inget behöver roteras och nästa kontroll tar fem minuter.