Kortversjonen: en VPN-tilkobling er ikke en permanent tilstand — det er en nettverksøkt som kan falle bort. Wi-Fi-roaming, mobilmaster-overganger, serverrestart, tapstopikker i pakker, applikasjonssuspensjon og OS-søvnssykluser avbryter tunnelen regelmessig. Når tunnelen faller, sier operativsystemets standardruting «hvis det ikke finnes noen spesifikk rute, bruk det fysiske nettverkskortet» — noe som betyr at trafikken din faller tilbake til den ekte forbindelsen og sender din ekte IP til det du kommuniserte med. En killswitch er mekanismen som sier «nei, stopp all trafikk inntil tunnelen er oppe igjen.» Konseptuelt enkelt. I praksis har begrepet blitt brukt til å beskrive minst tre ganske forskjellige ting, med svært ulike feilmodi.
Hvorfor killswitcher eksisterer — problemet med stille tilbakefall
Se for deg hva som skjer uten en killswitch. Du sitter på en kafé med VPN tilkoblet. Du leser e-post via en nettbasert e-postklient. Wi-Fi har et kort brudd — kanskje to sekunder. VPN-klienten forsøker å koble til igjen, men det underliggende nettverket er nede, så gjenoppkoblingen mislykkes. Etter 30 sekunder er nettverket tilbake. Nå avhenger det av VPN-klientens oppførsel hva som skjer:
- Uten en killswitch — i det øyeblikket Wi-Fi er tilbake, endrer operativsystemets standardrute tilbake til Wi-Fi-kortet. VPN-klienten prøver fortsatt å koble til igjen, men appene dine venter ikke. Nettbasert e-posts bakgrunnssynkronisering sender neste forespørsel ut over det bare Wi-Fi med din ekte IP og hvilken DNS-løser nettverket ga deg. Innen VPN-en er ferdig med å koble til igjen (5–20 sekunder senere) har lekkasjen allerede skjedd.
- Med en killswitch — når VPN-en kobler fra, installerer killswitchen en brannmurregel som blokkerer all trafikk som ikke går gjennom tunnelen. Selv når Wi-Fi er tilbake, kan ikke appene dine sende noe før VPN-sesjonen er fullstendig gjenopprettet. E-postens synkroniseringsforespørsel mislykkes med en nettverksfeil (appen prøver igjen), men ingen trafikk forlater enheten din via det bare nettverkskortet.
Problemet med stille tilbakefall er det sentrale killswitcher er designet for å løse. Det er ikke «VPN-en krasjet og nå surfer jeg åpent» — det er det langt mer subtile tilfellet der VPN-en er kortvarig utilgjengelig, appene dine ikke vet om det, og de lekker i mellomtiden.
De tre typene killswitch
Når leverandører sier «killswitch», kan de mene én av disse tre arkitekturene. Forskjellene er viktige fordi feilmodiene er ulike.
1. Systemomfattende killswitch (brannmurbasert)
Den sterkeste modellen. VPN-klienten installerer en brannmurregel i operativsystemet — ved hjelp av pf på macOS, Windows Filtering Platform på Windows, iptables eller nftables på Linux, eller en systemnettverksutvidelse på iOS/Android — som slipper alle utgående pakker som ikke er beregnet på VPN-serverens IP. Når VPN-en er oppe, ruter tunnelen selv trafikk til VPN-serveren, så pakker passerer. Når VPN-en er nede, er det ingenting som matcher «tillat»-regelen, så alt blokkeres. Brannmurregelen forblir på plass selv om VPN-klienten krasjer, fordi OS-brannmuren er uavhengig av applikasjonen som installerte regelen.
2. App-nivå killswitch (per applikasjon)
I stedet for å blokkere all trafikk, blokkerer killswitchen kun spesifikke apper du har lagt til i en liste. Når VPN-en faller, mister disse appene nettverksforbindelsen inntil VPN-en er tilbake; andre apper fortsetter å fungere normalt. Dette er nyttig for svært spesifikke scenarioer — beskyttelse av en bestemt nettleser, IRC-klient eller BitTorrent-klient — men det er svakere som generelt forsvar fordi det etterlater en stor angrepsflate (systemstatusfeltet-apper, bakgrunnstjenester, OS-komponenter og appene du glemte å legge til i listen).
3. Nettverksnivå brannmur (alltid-på VPN)
På Android spesielt finnes det en sterkere primitiv enn killswitch-implementeringene VPN-apper lager selv: den systemomfattende «Alltid-på VPN»-innstillingen med «Blokker tilkoblinger uten VPN» aktivert. Her er det OS-et selv som håndhever regelen — Android nekter å rute ikke-VPN-trafikk overhodet, uavhengig av hvilken app som ber om det. Selv om VPN-appen krasjer, holder OS-et linjen. Dette er den mest robuste killswitch-oppførselen tilgjengelig på mobil, og den er strengt sterkere enn app-implementerte killswitcher.
Hvordan hver type faktisk fungerer på OS-nivå
Implementeringsdetaljene er viktige fordi de forutsier feilmodiene. En brannmurbasert killswitch feiler når brannmur-API-et er buggy. En app-basert killswitch feiler når appen krasjer. En OS-håndhevet alltid-på VPN feiler i praksis aldri, med mindre du starter i sikkermodus.
iOS-implementering — NetworkExtension og on-demand-regler
iOS eksponerer ikke et bokstavelig «killswitch»-API til tredjeparters VPN-apper. Det den eksponerer er NetworkExtension-rammeverkets «on-demand rules»-mekanisme: regler som sier «hver gang en app prøver å opprette en nettverksforbindelse som ikke matcher et unntak, tving VPN-en til å koble til først.» Hvis VPN-en ikke kan etablere forbindelsen, henger tilkoblingsforespørselen. Fra brukerens perspektiv oppfører dette seg som en killswitch — men det er faktisk en «tving VPN på»-regel snarere enn en «blokker alt hvis VPN er nede»-regel. Det funksjonelle resultatet er likt; implementeringen er annerledes.
NetworkExtension-API-et støtter også flagget includeAllNetworks (lagt til i iOS 14) som gjør VPN-en til et systemomfattende nettverksfilter — selv trafikk fra kjernen og systemtjenester tvinges gjennom VPN-en. Med det flagget satt fungerer VPN-en virkelig som en full killswitch, der OS-et garanterer at ingen trafikk slipper unna tunnelen. Ikke alle VPN-leverandører aktiverer det; flagget har kompatibilitetsimplikasjoner.
Android-implementering — Alltid-på VPN + Blokker tilkoblinger uten VPN
Androids sterkeste killswitch-oppførsel finnes i Innstillinger, deretter Nettverk og internett, deretter VPN, deretter tannhjulikonet ved siden av VPN-en din, deretter de to bryterne: «Alltid-på VPN» og «Blokker tilkoblinger uten VPN.» Når begge er på, er det Android-systemet selv — ikke VPN-appen — som nekter å rute trafikk inntil VPN-en er tilkoblet. VPN-appen kan krasje, bli tvangsavsluttet eller avinstallert, og regelen består. Den offisielle Android-utviklerdokumentasjonen beskriver mekanismen i detalj. Dette er gullstandarden for killswitch-oppførsel på forbrukermobilenheter.
macOS-implementering — systemnettverksutvidelser
macOS 11 (Big Sur) og nyere kjører VPN-er gjennom System Extension-rammeverket — samme arkitektur som støtter innholdsfiltre og systemnivå-nettverksfiltre. Killswitchen implementeres vanligvis som en pakkefilterregel (pf) installert av VPN-klienten, kombinert med en nettverksutvidelse som holder modifikasjonen av rutetabellen. Når VPN-en faller, forblir pf-regelen på plass og fortsetter å blokkere trafikk inntil VPN-en gjenopprettes. Hvis VPN-klienten selv krasjer, avhenger oppførselen av om systemutvidelsen er konfigurert til å forbli lastet — veldesignede klienter beholder reglene på plass; dårlig designede klienter slipper dem ved krasj og lekker.
Windows-implementering — Windows Filtering Platform
Windows VPN-er implementerer vanligvis killswitchen ved å installere Windows Filtering Platform (WFP)-filterregler som blokkerer trafikk på det fysiske nettverkskortet mens de tillater trafikk på det virtuelle VPN-kortet. Filtrene vedvarer på tvers av VPN-klientprosessens restart (de eies av kjernefilter-laget, ikke brukerromsappen), så selv om VPN-appen krasjer, forblir filteret. Risikoen er at noen VPN-klienter bruker brannmurregelstrategier av lavere kvalitet — f.eks. manipulering av Windows Defender Firewall via PowerShell eller netsh — som kan omgås av andre brannmurregler eller av feilkonfigurasjon.
Når killswitcher svikter — lekkasjeforhold du bør kjenne til
En killswitch er ikke en perfekt garanti. Det er veldokumenterte forhold der trafikk kan lekke selv med en killswitch aktivert. Hver VPN-leverandør håndterer disse ulikt; noen løses med nøye implementering, andre er uunngåelige uten samarbeid på OS-nivå.
DNS-forgiftning under tilkoblingsoppstart
For å koble til VPN-serveren må VPN-klienten først løse opp serverens vertsnavn. Hvis killswitchen håndhever «ingen trafikk uten VPN», men VPN-klienten selv trenger å gjøre et DNS-oppslag for å finne VPN-serveren, må det finnes et unntak — og det unntaket er en liten lekkasjeflate. Et ondsinnet lokalt nettverk kan forgifte DNS-svaret og omdirigere VPN-klienten til en falsk server. De fleste klienter håndterer dette ved å bruke en hardkodet IP for VPN-serveren, eller ved å validere TLS-sertifikatet slik at en omdirigert server ikke valideres. Billige VPN-klienter hopper noen ganger over dette steget.
IPv6-lekkasjer
Hvis nettverket ditt har IPv6-tilkobling, men VPN-klientens killswitch bare blokkerer IPv4-trafikk, kan IPv6-trafikken flyte ut gjennom det bare nettverkskortet selv når killswitchen er «aktiv.» Dette er én av de vanligste lekkasjemodiene i den virkelige verden. Løsningen er at VPN-klienten installerer tilsvarende IPv6-brannmurregler. Mange eldre klienter gjør ikke dette. Test alltid for IPv6-lekkasjer etter aktivering av en killswitch ved å kjøre en lekkasjetest.
Fangstportaler (Wi-Fi-innloggingssider)
Kafeer, flyplasser og hoteller krever ofte at du logger inn via en fangstportal før du kan nå internett — inkludert VPN-serveren. En streng killswitch vil nekte å la deg nå fangstportalen fordi den ikke er VPN-serveren. De fleste VPN-klienter har en «sett killswitch på pause for fangstportal»-modus som du må aktivere manuelt. Mens den er pauset er du ubeskyttet, så ikke bla på noe sensitivt inntil killswitchen er tilbake på. Den OS-native alltid-på VPN på Android håndterer dette litt mer elegant via systemets fangstportaldeteksjon, men avveiningen er den samme.
App-suspensjon og bakgrunnsstart-kappløp
På mobil kan OS-et suspendere VPN-appen for å spare batteri. Når appen gjenopptas, er det et lite vindu der tunnelen gjenopprettes. Hvis killswitchen er implementert på OS-nivå (via includeAllNetworks på iOS eller alltid-på VPN på Android), er det ingen lekkasje. Hvis killswitchen er implementert rent i appen, kan det være et kort vindu der OS-et har gjenopptatt apper men VPN-en ikke har koblet til igjen, og apper som foretar nettverkskall i det vinduet vil lekke.
Oppstartstids-kappløp
På stasjonær maskin er perioden mellom oppstart og VPN-klientstart ubeskyttet. Nettverksbeviste apper som autostarter (Mail, Slack, Steam, systemoppdateringssjekker) foretar ofte tilkoblinger før VPN-en er oppe. En robust killswitch installerer brannmurregelen sin som en vedvarende oppstartstidregel slik at selv ved oppstart er trafikk blokkert inntil VPN-en kobler til. De fleste forbrukervpn-klienter gjør ikke dette; regelen gjelder bare etter at klienten starter.
Killswitch-typer sammenlignet
| Type | Hva den blokkerer | OS-støtte | Vanlige feilmodi |
|---|---|---|---|
| Systemomfattende brannmur | All ikke-VPN-trafikk på kjernenivå | macOS, Windows, Linux; iOS via includeAllNetworks | IPv6-lekkasjer hvis regler kun er IPv4; oppstartstids-kappløp; DNS bootstrap-unntak |
| App-nivå (per-app-blokkeringsliste) | Bare listeoppførte appers trafikk | Windows, noen macOS-klienter | Apper som ikke er på listen lekker fortsatt; OS-komponenter lekker; systemtjenester lekker |
| OS-håndhevet alltid-på VPN | All trafikk på OS-nivå, uavhengig av app-krasj | Android (Alltid-på VPN + Blokker uten VPN), iOS (NetworkExtension on-demand) | Fangstportal-innlogging blokkeres inntil du setter på pause; svært få andre feilmodi |
| Applikasjonsovervåker (den svake formen) | Ingenting direkte; lukker bare angitte apper når VPN faller | Noen Windows-klienter leverer fortsatt dette | Kappløp mellom deteksjon og lukking lekker; egentlig ikke en killswitch |
Hva «alltid-på VPN» faktisk gir deg som en app-nivå killswitch ikke gjør
Den viktigste distinksjonen i 2026 er mellom leverandørimplementerte killswitcher og OS-håndhevede alltid-på VPN. Her er grunnen til at OS-håndhevede versjoner er merkbart sterkere:
- Overlever VPN-app-krasj. Hvis VPN-appen krasjer av noen grunn, dør en app-nivå killswitch med den. Brannmurregelen den installerte kan vedvare eller ikke, avhengig av implementering. En OS-håndhevet regel holdes av OS-et selv og fortsetter å gjelde.
- Overlever omstart. Mange app-nivå killswitcher installerer regler ved appstart og fjerner dem ved avslutning, noe som etterlater et gap ved oppstart. OS-nivå alltid-på-innstillinger overholdes fra den første nettverkspakken OS-et ruter etter oppstart.
- Dekker systemtjenester. Skysynkronisering, OS-oppdateringssjekker, push-varselsdaemoner og andre OS-nivåtjenester går ikke gjennom normal VPN-klientruting. OS-håndhevet alltid-på dekker dem; en app-nivå killswitch gjør det kanskje ikke.
- Kan ikke omgås ved brukerens feiltrykk. En app-nivå killswitch har en bryter i appens brukergrensesnitt. En bruker (eller en annen app med tillatelser) kan deaktivere den. OS-nivå alltid-på er i systeminnstillingene og er vanskeligere å slå av ved et uhell.
På Android foretrekk den OS-håndhevede versjonen: slå på «Alltid-på VPN» og «Blokker tilkoblinger uten VPN» i systeminnstillingene, og behandle VPN-klientens egen killswitch som et supplement. På iOS, se etter VPN-klienter som velger inn includeAllNetworks; det er det tilsvarende flagget og gir lignende garantier.
Hva Casper gjør — det ærlige svaret
Casper's Cloak bruker en OS-integrert killswitch på hver plattform — includeAllNetworks på iOS slik at OS-et selv håndhever ingen-lekkasje-regelen, alltid-på VPN-innstillingene på Android, og pakkefilterregler på kjernenivå på macOS. Oppførselen er den samme på alle tre: når tunnelen faller, stopper all trafikk, inkludert IPv6 og inkludert OS-nivåtjenester. Når tunnelen er tilbake, gjenopptas trafikken. Det er ingen bryter å glemme, ingen per-app-liste å vedlikeholde, ingen IPv6-unntaksregel.
Vi kombinerer dette med trusselsbeskyttelse og trusselssskjold for aktiv filtrering mot kjente skadelige domener, slik at tunnelen ikke bare er et rutinglag — den avviser aktivt tilkoblinger til phishing, skadelig programvare C2 og kjent dårlig infrastruktur. Killswitchen er garantien på bunnnivå for at ingenting omgår filtreringen når tunnelen kortvarig faller. Den kombinerte effekten: selv på fiendtlige nettverk som de som omtales i vår artikkel om offentlige Wi-Fi-angrep, får du ikke det «to sekunders klartekst»-vinduet som en app-nivå-only killswitch etterlater åpent.
Vår holdning til killswitcher generelt: det er en grunnleggende forventning, ikke en premiumfunksjon. Enhver forbruker-VPN som ikke tilbyr en i 2026, mangler en grunnleggende sikkerhetsmekanisme. For bakgrunnen om trusselmodellering på hvorfor dette er viktig på systemnivå, dekker NSAs veiledning om valg og herding av VPN for fjerntilgang den arkitektoniske begrunnelsen i detalj, med en anbefaling til fordel for full-tunnel-arkitekturer støttet av håndhevelse på kjernenivå.
Bunnlinjen
«Har denne VPN-en en killswitch» er feil spørsmål. De riktige spørsmålene er: hvor i stacken håndheves killswitchen (app, system eller OS), dekker den IPv6, vedvarer den over app-krasj og omstarter, og er den på som standard. Hvis svarene er «OS-nivå», «ja», «ja» og «ja», gjør killswitchen jobben sin. Hvis svarene er «bare app-nivå», «nei», «avhenger av», og «av som standard», har du en killswitch i navn men ikke i beskyttelse.
Den enkle praksisen: på Android, slå på alltid-på VPN på systemnivå med «Blokker tilkoblinger uten VPN.» På iOS, bruk en VPN-klient som aktiverer includeAllNetworks. På stasjonær maskin, verifiser etter installasjon ved å kjøre en lekkasjetest, og koble deretter kortvarig fra VPN-serversiden (eller dra ut nettverkskabelen din) og bekreft at trafikken faktisk stopper. Hvis lekkasjetesten fortsatt viser din ekte IP, fungerer ikke killswitchen som annonsert — undersøk før du stoler på den.