Slik testar du ein VPN-killbrytar utan ekte konto

Du treng ikkje ein ekte konto for å finne ut om ein killbrytar held; det er nettopp kontoen testen set i fare. Kontrollen lagar eit kort vindauge der trafikk kan eller ikkje kan gå utanfor tunnelen, så lasta bør vere noko du kan miste. Eg gjer dette no med ei lokkeside og ein reserveprofil i nettlesaren, og det gir eit klarare svar enn rutinen med nettlesar og webmail eg brukte før. Nedanfor følgjer eg same rekkjefølgje som klienten viser: innstillinga, målet, overgangen og så beviset.

Testen svarar på eitt smalt spørsmål: kan dette programmet i løpet av denne overgangen nå nettverket utanfor tunnelen? det seier ingenting om resten av policyen er fornuftig. Hald omfanget så lite, og resultatet er verdt å skrive ned.

Finn brytaren og omfanget hans i klienten

Opne klienten og finn blokkeringsinnstillinga før du endrar nokon nettverkstilstand. Produsentane kallar henne ulikt: killbrytar, låsemodus, nettverkslås, blokker trafikk utanfor tunnelen. Etiketten seier mindre enn alternativa inni. Det som avgjer, er om blokkeringa gjeld alltid eller berre når appen meiner at tunnelen nettopp har svikta, og om ho dekkjer alle program eller ei vald liste.

List så opp overgangane klienten din faktisk kan utføre. Ei brukarinitiert fråkopling, å avslutte appen og å miste kontakten med tenaren er tre ulike kodestiar i dei fleste klientar, og dei deler ikkje éin blokkeringspolicy. Nokre slepp blokkeringa når appen blir avslutta. Andre lèt filterreglar stå til noko fjernar dei. Les innstillingsreferansen til produsenten for versjonen du køyrer i staden for å anta, og skriv så ned kva av dei tre du testar.

Noter òg profilen: protokoll, adressefamiliar og om delt tunnel er på. Ei påstand om heile eininga er meiningslaus om profilen med vilje utelèt nokre program, og eit unntak du sjølv har sett opp, er ikkje ei lekkasje. Innstillingsreferansen for OpenVPN Connect er ei slik side som nemner kva brytar som endrar kva åtferd, sjølv om etikettene varierer mellom klientar.

Vel eit lokkemål som òg verkar utan tunnelen

Lokket treng to eigenskapar, og hoppar du over ein av dei blir resultatet uleseleg. Det må kunne nåast direkte når tunnelen er nede og blokkeringa er av, elles kan det at det slutta å svare rett og slett tyde at verten er borte. Og det må ikkje krevje innlogging, kake eller betaling, slik at ei lekkasje kostar éi logglinje i staden for ein sesjon.

Ei statisk side på ein vert du kontrollerer er det reinaste valet. Ein reserve virtuell maskin med ein vanleg HTTP-tenar er nesten like god, og ein offentleg tilkoplingssjekk går fint om du godtek at tilgjengelegheita er utanfor din kontroll. Noter adressa, porten, adressefamilien og om førespurnaden treng eit namneoppslag, fordi kvar av dei blir ein variabel du seinare kan måtte isolere.

Fastset grunnlinja før du rører brytaren. Med tunnelen oppe må lokket svare gjennom tunnelen, noko som beviser at policyruta verkar. Med tunnelen nede og blokkeringa av må det svare direkte, noko som beviser at målet lever. Først då seier ein feil i blokkert tilstand deg noko.

Køyr overgangane i fast rekkjefølgje

Ta overgangane éin om gongen og gje kvar nokre sekund til å setje seg, fordi klientar ofte riv og byggjer opp reglar igjen i det gapet. Den same korte kontrollen kvar gong gjer observasjonane samanliknbare:

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

Rada med å avslutte appen fortener ei eiga køyring, sjølv om du aldri lukkar klienten i vanleg bruk. Om blokkeringa blir sleppt ved avslutting, gir ein krasj eller ei påtvinga oppdatering deg same eksponering, og det er eit faktum om utrullinga, ikkje om tolmodet ditt. På Windows er dei tilsvarande probane Resolve-DnsName decoy.example og curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.

Skil ei blokkering frå ein øydelagd resolver

Ei side som ikkje blir lasta har fleire årsaker, og berre éi av dei er at brytaren verkar. Om namnet ikkje blir løyst opp, har du lært at DNS er blokkert eller øydelagd, ikkje at datastien er blokkert. Prøv òg ei litteral adresse, slik at svaret ikkje avheng av oppslag i det heile.

Utgangskodane til curl held desse tilfella frå kvarandre. 6 er ein feil i namneoppslaget, 7 tyder at tilkoplinga vart avvist, 28 er eit tidsavbrot. Ei blokkert rute viser seg vanlegvis som tidsavbrot eller avvising mot ei litteral adresse, medan ei blokkering av berre DNS lèt 6 stå igjen og skjuler alt anna. Ei bufra side eller ein captive portal lurar auget, derfor er utgangskoden beviset, ikkje skjermen.

Gjenta proben over IPv6 med ei litteral adresse. Ei blokkering som dekkjer IPv4 og ignorerer IPv6 er vanleg nok til å fortjene si eiga linje i notata, og ein klient som slår av IPv6 utanfor tunnelen bør feile reint på begge familiane.

Noter omfanget resultatet dekkjer

Når tunnelen er tilbake, stadfest gjenopprettinga: lokket svarar gjennom tunnelen, resolveren returnerer svar, og policyen står der du forlét henne. Angre så eksperimenta. Ein mellombels brannmurregel, ei feilsøkingsrute eller ein testprofil som blir ståande, forvirrar neste køyring og kan overleve appen.

Éin gjennomgang dekkjer éin klientversjon, éin profil, éin overgang og éin adressefamilie. Skriv ned dei fire saman med utfallet:

• Klientversjon og plattform, og om innstillinga er per profil eller global.
• Profil, protokoll og eventuelle unntak for delt tunnel.
• Testa overgang og korleis du utløyste han.
• Adressefamiliar og DNS, med utgangskodane til curl for blokkert og ikkje-blokkert tilstand.

Om noka linje er tom, er testen ikkje ferdig. Roaming tyder å gjenta linja for nettverksendring. Ein uovervaka omstart tyder å kontrollere at reglane kjem tilbake, og det er eit spørsmål om gjenopprettingsrekkjefølgje, ikkje om brytaren. Køyr sekvensen på nytt etter ein klientoppdatering, fordi brytarane sjeldan blir endra medan åtferda bak dei blir det. Hald lokket: ingenting må roterast, og neste kontroll tek fem minutt.