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

En kill switch på en funksjonsliste sier nesten ingenting om hva som skjer når tunnelen faller ut. Én implementasjon stenger utvalgte prosesser, en annen legger inn pakkefiltre ved operativsystemets grense, og en tredje forsøker bare å koble til igjen. Forskjellen kommer til syne i sekundene etter en svikt, ikke på innstillingsskjermen. Arbeid deg gjennom disse kontrollene i rekkefølge og stopp ved den første du ikke kan besvare ærlig, for der slutter den faktiske dekningen din.

Navngi håndhevingsmekanismen først

Avslutning av prosesser er en egenskap ved 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 ett sekund senere, har sin egen livssyklus og sitt eget tidsforløp.

Pakkefiltrering er en egenskap ved operativsystemet. Den avviser trafikk som ikke følger den tillatte veien, noe som er et sterkere løfte, men bare så langt regelen faktisk rekker. Adressefamilie, grensesnitt, utelatte applikasjoner og unntak avgjør dette, ikke merkelappen i klienten.

Overlever sperren klienten?

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

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

Se etter de vanlige hullene

IPv6 er det første. En regel skrevet for IPv4-adresser lar IPv6-trafikk være urørt, og mange klienter skriver bare v4-halvdelen. Det andre er grensesnittet: USB-tethering, en ekstra Wi-Fi-adapter og et mobilt modem er kanskje ikke omfattet av en regel begrenset til den primære forbindelsen. Utelatte 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 å sammenligne alle tre er hele poenget.

DNS er den vanlige lekkasjen

Å sperre TCP mens UDP 53 står åpen gir deg en meget overbevisende kill switch som fortsatt svarer på hver vertsnavnforespørsel. Det samme gjelder når DNS overlates til en resolver på et annet grensesnitt, eller når klienten bare sperrer 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 fullstendig sperret, uansett hva statusikonet sier.

Test overgangen, ikke bryteren

Å slå av VPN-en fra dens egen meny er en ryddig avslutning, og den ryddige saken håndterer enhver implementasjon godt. Overgangen som betyr noe, er den hardhendte: drep tunnelprosessen, trekk ut nettet, la serveren slutte å svare. Start så en forespørsel og se om den mislykkes eller i det stille bruker den fysiske forbindelsen.

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

Ha en vei tilbake

Sperring på systemnivå har den motsatte feilmodusen. Filtre som overlever klienten, kan etterlate en maskin helt uten nettverk etter en avinstallasjon, noe som er en supporthenvendelse uten åpenbar årsak. Før du slår på 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, må du behandle den som en bryter på applikasjonsnivå med kjente hull og planlegge deretter.