Kill switch i appen kontra kill switch i brannmuren: hva hver av dem blokkerer

En kill switch på en funksjonsliste forteller nesten ingenting om hva som skjer når tunnelen faller. Én implementasjon lukker utvalgte prosesser, en annen installerer pakkefiltre ved operativsystemets grense, og en tredje prøver ganske enkelt å koble til på nytt. Forskjellen viser seg i sekundene etter en feil, ikke på innstillingsskjermen. Gå gjennom disse kontrollene i rekkefølge og stopp ved den første du ikke kan svare ærlig på, for det er der den reelle dekningen din slutter.

Navngi håndhevelsesmekanismen først

Prosessavslutning er en funksjon i applikasjonens livssyklus. Den finner utvalgte programmer etter en oppdaget tunnelefeil og lukker dem. Alt som ikke er hovedprosessen, overlever: hjelpetjenester, bakgrunnssynkronisering og enhver applikasjon som startes et sekund senere, har sin egen livssyklus og sin egen timing.

Pakkefiltrering er en operativsystemfunksjon. Den avviser trafikk som ikke følger den tillatte veien, som er et sterkere løfte, men bare så langt regelen faktisk treffer. Adressefamilie, grensesnitt, utelukkede applikasjoner og unntak avgjør det, ikke etiketten i klienten.

Overlever blokkeringen klienten?

Still fire spørsmål i denne rekkefølgen: hva skjer ved et krasj, ved manuell avslutning, ved utlogging og ved omstart. En regel som klienten selv vedlikeholder, fjernes vanligvis under en pen nedstenging og blir ofte liggende igjen etter et krasj. En regel som installeres i plattformens lager, kan oppføre seg motsatt og overleve både klienten og av og til avinstallasjonen.

Lukk klienten midt i en lang nedlasting og se om overføringen stopper eller fortsetter.

Se etter standardhullene

IPv6 er det første. En regel skrevet for IPv4-adresser lar IPv6-trafikk være upåvirket, og mange klienter skriver bare v4-halvdelen. Det andre er grensesnittet: USB-tethering, en ekstra Wi-Fi-adapter og et mobilmodem er kanskje ikke omfattet av en regel som er begrenset til den primære tilkoblingen. Utelukkede applikasjoner og unntak for lokalnettet er det tredje.

På Windows kan du lese de installerte reglene i stedet for å stole på bryteren: Get-NetFirewallRule -DisplayName '*VPN*' og netsh wfp show filters viser begge hva som finnes. På Linux dekker iptables -S, ip6tables -S og nft list ruleset de vanlige tilfellene, og det er poenget å sammenligne alle tre.

DNS er den vanlige lekkasjen

Å blokkere TCP mens UDP 53 står åpent gir deg en svært overbevisende kill switch som fortsatt svarer på hvert vertsnavnoppslag. Det samme gjelder når DNS overlates til en resolver på et annet grensesnitt, eller når klienten bare blokkerer v4 og resolveren er tilgjengelig over v6.

Med tunnelen nede, slå opp ett kjent navn og se om det kommer et svar tilbake. Hvis det gjør det, er trafikken ikke fullt blokkert, uansett hva statusikonet sier.

Test overgangen, ikke bryteren

Å slå av VPN-en fra sin egen meny er en pen nedstenging, og den pene saken håndterer enhver implementasjon godt. Overgangen som betyr noe, er den brutale: drep tunnelprosessen, trekk ut nettverket, la serveren slutte å svare. Start deretter en forespørsel og se om den feiler eller stille bruker den fysiske lenken.

Et resultat fra én bærbar overføres ikke til en telefon eller ruter. Ulike plattform-API-er, ulike standardverdier, og på Android er forskjellen skarp: always-on med blokkering håndheves av systemet i stedet for klienten, så det fortsetter å virke når klienten ikke gjør det. Android VPN-veiledningen beskriver den delingen.

Hold en vei tilbake

Blokkering på systemnivå har den motsatte feilmodusen. Filtre som overlever klienten, kan etterlate en maskin helt uten nettverk etter en avinstallasjon, som er en supporthenvendelse uten åpenbar årsak. Før du aktiverer en kill switch som skriver plattformregler, noter hvordan den fjernes, og hold leverandørens reparasjonsvei der du kan finne den.

Hvis du ikke kan svare på krasj-, IPv6-, DNS- og overgangskontrollene for klienten din, behandle den som en bryter på appnivå med kjente hull og planlegg deretter.