Ein kill switch på ei funksjonsliste fortel nesten ingenting om kva som skjer når tunnelen fell. Éin implementasjon lukkar utvalde prosessar, ein annan installerer pakkefilter ved grensa til operativsystemet, og ein tredje prøver rett og slett å kople til på nytt. Skilnaden viser seg i sekunda etter ein feil, ikkje på innstillingsskjermen. Gå gjennom desse kontrollane i rekkjefølgje og stopp ved den første du ikkje kan svare ærleg på, for det er der den reelle dekninga di sluttar.

Namngi handhevingmekanismen først

Prosessavslutting er ein funksjon i livssyklusen til applikasjonen. Han finn utvalde program etter ein oppdaga tunnelefeil og lukkar dei. Alt som ikkje er hovudprosessen, overlever: hjelpetenester, bakgrunnssynkronisering og kvar applikasjon som blir starta eit sekund seinare, har sin eigen livssyklus og si eiga timing.

Pakkefiltrering er ein funksjon i operativsystemet. Han avviser trafikk som ikkje følgjer den tillatne vegen, som er eit sterkare løfte, men berre så langt regelen faktisk treff. Adressefamilie, grensesnitt, utelukka applikasjonar og unntak avgjer det, ikkje etiketten i klienten.

Overlever blokkeringa klienten?

Still fire spørsmål i denne rekkjefølgja: kva skjer ved eit krasj, ved manuell avslutting, ved utlogging og ved omstart. Ein regel som klienten sjølv vedlikeheld, blir vanlegvis fjerna under ei pen nedstenging og blir ofte liggjande att etter eit krasj. Ein regel som er installert i plattformlageret, kan oppføre seg motsett og overleve både klienten og av og til avinstallasjonen.

Lukk klienten midt i ein lang nedlasting og sjå om overføringa stoppar eller held fram.

Sjå etter standardhola

IPv6 er det første. Ein regel skriven for IPv4-adresser lèt IPv6-trafikk vere upåverka, og mange klientar skriv berre v4-halvdelen. Det andre er grensesnittet: USB-tethering, ein ekstra Wi-Fi-adapter og eit mobilmodem er kanskje ikkje omfatta av ein regel som er avgrensa til den primære tilkoplinga. Utelukka applikasjonar og unntak for lokalnettet er det tredje.

På Windows kan du lese dei installerte reglane i staden for å stole på brytaren: Get-NetFirewallRule -DisplayName '*VPN*' og netsh wfp show filters viser båe kva som finst. På Linux dekkjer iptables -S, ip6tables -S og nft list ruleset dei vanlege tilfella, og det er poenget å samanlikne alle tre.

DNS er den vanlege lekkasjen

Å blokkere TCP medan UDP 53 står ope gjev deg ein særs overtydande kill switch som framleis svarar på kvar vertsnamnoppslag. Det same gjeld når DNS blir overlete til ein resolver på eit anna grensesnitt, eller når klienten berre blokkerer v4 og resolveren er tilgjengeleg over v6.

Med tunnelen nede, slå opp eitt kjent namn og sjå om det kjem eit svar tilbake. Om det gjer det, er trafikken ikkje fullt blokkert, uansett kva statusikonet seier.

Test overgangen, ikkje brytaren

Å slå av VPN-en frå sin eigen meny er ei pen nedstenging, og den pene saka handterer kvar implementasjon godt. Overgangen som betyr noko, er den brutale: drep tunnelprosessen, trekk ut nettet, lat tenaren slutta å svare. Start så ein førespurnad og sjå om han feilar eller stille brukar den fysiske lenkja.

Eit resultat frå éin berbar blir ikkje overført til ein telefon eller ruter. Ulike plattform-API-ar, ulike standardverdiar, og på Android er skilnaden skarp: always-on med blokkering blir handheva av systemet i staden for klienten, så det held fram å verke når klienten ikkje gjer det. Android VPN-rettleiinga skildrar den delinga.

Hald ein veg tilbake

Blokkering på systemnivå har den motsette feilmodusen. Filter som overlever klienten, kan etterlate ein maskin heilt utan nett etter ein avinstallasjon, som er ein supportførespurnad utan openberr årsak. Før du aktiverer ein kill switch som skriv plattformreglar, noter korleis han blir fjerna, og hald reparasjonsvegen til leverandøren der du kan finne han.

Om du ikkje kan svare på krasj-, IPv6-, DNS- og overgangskontrollane for klienten din, handsam han som ein brytar på appnivå med kjende hol og planlegg deretter.

Relaterte artiklar