Sådan tester du en VPN-kill switch uden dine rigtige konti

Du behøver ikke en rigtig konto for at finde ud af, om en kill switch holder; det er netop, hvad en test sætter på spil. Kontrollen skaber et kort vindue, hvor trafik måske eller måske ikke forlader tunnelen, så nyttelasten bør være noget, du kan miste. Jeg gør det nu med en lokkeside og en ekstra browserprofil, og det giver et klarere svar end browser-plus-webmail-rutinen, jeg brugte før. Det følgende går i samme rækkefølge, som klienten viser: indstillingen, destinationen, skiftet og derefter beviserne.

Testen besvarer ét snævert spørgsmål: i dette skift, kan denne applikation nå netværket uden for tunnelen? Den siger intet om, hvorvidt resten af politikken er fornuftig. Hold omfanget så lille, og resultatet er værd at skrive ned.

Find kontakten og dens omfang i klienten

Åbn klienten, og find blokeringsindstillingen, før du ændrer nogen netværkstilstand. Leverandører kalder den forskelligt: kill switch, lockdown-tilstand, netværkslås, bloker trafik uden for tunnelen. Etiketten fortæller mindre end indstillingerne indeni. Det afgørende er, om blokeringen gælder altid, eller kun når appen vurderer, at en tunnel netop er fejlet, og om den dækker alle applikationer eller en valgt liste.

Oplist derefter de skift, din klient faktisk kan udføre. En brugerinitieret afbrydelse, at afslutte appen og at miste kontakten til serveren er tre forskellige kodestier i de fleste klienter, og de deler ikke én blokeringspolitik. Nogle frigiver blokeringen, når appen afsluttes. Andre lader filtreringsreglerne være installeret, indtil noget fjerner dem. Læs leverandørens indstillingsreference for den version, du kører, i stedet for at antage, og skriv derefter ned, hvilken af de tre du tester.

Notér også profilen: protokol, adressefamilier og om delt tunneling er aktiveret. En påstand om hele enheden er meningsløs, hvis profilen med vilje udelukker nogle få applikationer, og en udelukkelse, du har konfigureret, er ikke en lækage. OpenVPN Connects indstillingsreference er den slags side, der nævner, hvilken kontakt der ændrer hvilken adfærd, selv om etiketterne varierer fra klient til klient.

Vælg en lokkedestination, der også virker uden tunnelen

Lokken skal have to egenskaber, og springer du en af dem over, får du et ulæseligt resultat. Den skal kunne nås direkte, når tunnelen er nede og blokeringen er slået fra, ellers kan “den holdt op med at svare” bare betyde, at værten er væk. Og den må ikke kræve login, cookie eller betaling, så en lækage koster dig en loglinje i stedet for en session.

En statisk side på en vært, du kontrollerer, er det rene valg. En ekstra virtuel maskine med en almindelig HTTP-server er næsten lige så god, og en offentlig forbindelsestest-side virker, hvis du accepterer, at dens tilgængelighed ligger uden for din kontrol. Notér adressen, porten, adressefamilien og om anmodningen kræver et navneopslag, fordi hver af dem bliver en variabel, du måske senere skal isolere.

Etabler basislinjen, før du rører kontakten. Med tunnelen oppe skal lokken svare gennem tunnelen, hvilket beviser, at politikruten virker. Med tunnelen nede og blokeringen slået fra skal den svare direkte, hvilket beviser, at destinationen er levende. Først da fortæller en fejl i den blokerede tilstand dig noget.

Kør skiftene i en fast rækkefølge

Tag skiftene ét ad gangen, og giv hvert af dem et par sekunder til at falde til ro, fordi klienter ofte river regler ned og genopbygger dem i det mellemrum. At køre den samme korte kontrol hver gang holder observationerne sammenlignelige:

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

Rækken om at afslutte appen fortjener sin egen kørsel, selv om du aldrig lukker klienten i normal brug. Hvis blokeringen frigives ved afslutning, giver et nedbrud eller en tvungen opdatering dig den samme eksponering, og det er et faktum om udrulningen, ikke om din tålmodighed. På Windows er de tilsvarende prober Resolve-DnsName decoy.example og curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.

Skeln en blokering fra en ødelagt resolver

En side, der ikke indlæses, har flere årsager, og kun én af dem er, at kontakten virker. Hvis navnet ikke opløses, har du lært, at DNS er blokeret eller ødelagt, ikke at datastien er blokeret. Test også en bogstavelig adresse, så svaret slet ikke afhænger af opløsningen.

curls exitkoder holder de tilfælde adskilt: 6 er en navneopløsningsfejl, 7 betyder, at forbindelsen blev afvist, 28 er en timeout. En blokeret rute viser sig normalt som en timeout eller en afvisning mod en bogstavelig adresse. En ren DNS-blokering efterlader 6 og skjuler alt andet. En cachet side eller en tvangsportal narrer øjet, og derfor er exitkoden, ikke skærmen, beviset.

Gentag proben over IPv6 med en bogstavelig adresse. En blokering, der dækker IPv4 og ignorerer IPv6, er almindelig nok til at fortjene sin egen linje i dine noter, og en klient, der deaktiverer IPv6 uden for tunnelen, bør fejle rent på begge familier.

Notér det omfang, resultatet dækker

Når tunnelen er tilbage, bekræft gendannelsen: lokken svarer gennem tunnelen, resolveren returnerer svar, og politikken står, hvor du efterlod den. Fortryd derefter eksperimenterne. En midlertidig firewallregel, en fejlfindingsrute eller en testprofil, der bliver liggende, vil forvirre næste kørsel og kan overleve appen.

En enkelt gennemkørsel dækker én klientversion, én profil, ét skift og én adressefamilie. Skriv de fire ned sammen med resultatet:

• Klientversion og platform, og om indstillingen er pr. profil eller global.
• Profil, protokol og eventuelle undtagelser for delt tunnel.
• Testet skift, og hvordan du udløste det.
• Adressefamilier og DNS, med curls exitkoder for den blokerede og den ublokerede tilstand.

Hvis en linje er tom, er testen ikke færdig. Roaming betyder at gentage rækken om netværksskift. En uovervåget genstart betyder at kontrollere, at reglerne vender tilbage, hvilket er et spørgsmål om gendannelsesrækkefølge og ikke om kontakten. Kør sekvensen igen efter en klientopdatering, fordi kontakterne sjældent ændrer sig, mens adfærden bag dem gør. Behold lokken: intet at rotere, og den næste kontrol tager fem minutter.