Slik tester du en VPN-killbryter uten ekte konto

Du trenger ikke en ekte konto for å finne ut om en killbryter holder; det er nettopp kontoen testen setter i fare. Kontrollen lager et kort vindu der trafikk kan eller ikke kan gå utenfor tunnelen, så lasten bør være noe du kan miste. Jeg gjør dette nå med en lokkeside og en reserveprofil i nettleseren, og det gir et klarere svar enn rutinen med nettleser og webmail jeg brukte før. Nedenfor følger jeg samme rekkefølge som klienten viser: innstillingen, målet, overgangen og så beviset.

Testen svarer på ett smalt spørsmål: kan dette programmet i løpet av denne overgangen nå nettverket utenfor tunnelen? det sier ingenting om hvorvidt resten av policyen er fornuftig. Hold omfanget så lite, og resultatet er verdt å skrive ned.

Finn bryteren og omfanget dens i klienten

Åpne klienten og finn blokkeringsinnstillingen før du endrer noen nettverkstilstand. Produsentene kaller den ulikt: killbryter, låsemodus, nettverkslås, blokker trafikk utenfor tunnelen. Etiketten sier mindre enn alternativene inni. Det som avgjør, er om blokkeringen gjelder alltid eller bare når appen mener at tunnelen nettopp har sviktet, og om den dekker alle programmer eller en valgt liste.

List så opp overgangene klienten din faktisk kan utføre. En brukerinitiert frakobling, å avslutte appen og å miste kontakten med serveren er tre ulike kodestier i de fleste klienter, og de deler ikke én blokkeringspolicy. Noen slipper blokkeringen når appen avsluttes. Andre lar filterregler stå til noe fjerner dem. Les produsentens innstillingsreferanse for versjonen du kjører i stedet for å anta, og skriv så ned hvilken av de tre du tester.

Noter også profilen: protokoll, adressefamilier og om delt tunnel er på. En påstand om hele enheten er meningsløs hvis profilen med vilje utelater noen programmer, og et unntak du selv har satt opp, er ikke en lekkasje. Innstillingsreferansen for OpenVPN Connect er en slik side som navngir hvilken bryter som endrer hvilken atferd, selv om etikettene varierer mellom klienter.

Velg et lokkemål som også virker uten tunnelen

Lokket trenger to egenskaper, og hopper du over en av dem blir resultatet uleselig. Det må kunne nås direkte når tunnelen er nede og blokkeringen er av, ellers kan det at det sluttet å svare rett og slett bety at verten er borte. Og det må ikke kreve innlogging, kake eller betaling, slik at en lekkasje koster én logglinje i stedet for en sesjon.

En statisk side på en vert du kontrollerer er det reneste valget. En reserve virtuell maskin med en vanlig HTTP-tjener er nesten like god, og en offentlig tilkoblingssjekk går fint hvis du godtar at tilgjengeligheten er utenfor din kontroll. Noter adressen, porten, adressefamilien og om forespørselen trenger et navneoppslag, fordi hver av dem blir en variabel du senere kan måtte isolere.

Fastsett grunnlinjen før du rører bryteren. Med tunnelen oppe må lokket svare gjennom tunnelen, noe som beviser at policyruten virker. Med tunnelen nede og blokkeringen av må det svare direkte, noe som beviser at målet lever. Først da sier en feil i blokkert tilstand deg noe.

Kjør overgangene i fast rekkefølge

Ta overgangene én om gangen og gi hver noen sekunder til å sette seg, fordi klienter ofte river og bygger opp regler igjen i det gapet. Den samme korte kontrollen hver gang gjør observasjonene sammenlignbare:

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=$?"

Raden med å avslutte appen fortjener en egen kjøring, selv om du aldri lukker klienten i vanlig bruk. Hvis blokkeringen slippes ved avslutning, gir en krasj eller en tvungen oppdatering deg samme eksponering, og det er et faktum om utrullingen, ikke om tålmodigheten din. På Windows er de tilsvarende probene Resolve-DnsName decoy.example og curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.

Skill en blokkering fra en ødelagt resolver

En side som ikke lastes har flere årsaker, og bare én av dem er at bryteren virker. Hvis navnet ikke løses opp, har du lært at DNS er blokkert eller ødelagt, ikke at datastien er blokkert. Prøv også en litteral adresse, slik at svaret ikke avhenger av oppslag i det hele tatt.

Utgangskodene til curl holder disse tilfellene fra hverandre. 6 er en feil i navneoppslaget, 7 betyr at tilkoblingen ble avvist, 28 er en tidsavbrudd. En blokkert rute viser seg vanligvis som tidsavbrudd eller avvisning mot en litteral adresse, mens en blokkering av bare DNS lar 6 stå igjen og skjuler alt annet. En bufret side eller en captive portal lurer øyet, derfor er utgangskoden beviset, ikke skjermen.

Gjenta proben over IPv6 med en litteral adresse. En blokkering som dekker IPv4 og ignorerer IPv6 er vanlig nok til å fortjene sin egen linje i notatene, og en klient som slår av IPv6 utenfor tunnelen bør feile rent på begge familier.

Noter omfanget resultatet dekker

Når tunnelen er tilbake, bekreft gjenopprettingen: lokket svarer gjennom tunnelen, resolveren returnerer svar, og policyen står der du forlot den. Angre så eksperimentene. En midlertidig brannmurregel, en feilsøkingsrute eller en testprofil som blir stående, forvirrer neste kjøring og kan overleve appen.

Én gjennomgang dekker én klientversjon, én profil, én overgang og én adressefamilie. Skriv ned de fire sammen med utfallet:

• Klientversjon og plattform, og om innstillingen er per profil eller global.
• Profil, protokoll og eventuelle unntak for delt tunnel.
• Testet overgang og hvordan du utløste den.
• Adressefamilier og DNS, med curls utgangskoder for blokkert og ikke-blokkert tilstand.

Hvis noen linje er tom, er testen ikke ferdig. Roaming betyr å gjenta linjen for nettverksendring. En uovervåket omstart betyr å kontrollere at reglene kommer tilbake, og det er et spørsmål om gjenopprettingsrekkefølge, ikke om bryteren. Kjør sekvensen på nytt etter en klientoppdatering, fordi bryterne sjelden endres mens atferden bak dem gjør det. Behold lokket: ingenting må roteres, og neste kontroll tar fem minutter.