Den korta versionen: en VPN-anslutning är inte ett permanent tillstånd – det är en nätverkssession som kan tappas. Wi-Fi-roaming, byte av celltorn, serveromstarter, paketförluster, appavstängningar och OS-sömnlägen avbryter regelbundet tunneln. När tunneln tappas säger operativsystemets standardroutningsregel "om det inte finns någon specifik rutt, använd det fysiska nätverkskortet" – vilket innebär att din trafik faller tillbaka till din riktiga anslutning och skickar din riktiga IP till vad du än kommunicerade med. En killswitch är den mekanism som säger "nej, sluta skicka trafik tills tunneln är uppe igen." Konceptuellt enkelt. I implementationen har begreppet kommit att betyda minst tre ganska olika saker, med mycket olika felscenarier.
Varför killswitchar finns – problemet med tyst återfall
Tänk dig vad som händer utan en killswitch. Du sitter på ett kafé med VPN:et anslutet. Du läser e-post via en webbmailklient. Wi-Fi har ett kortvarigt avbrott – kanske två sekunder. VPN-klienten försöker återansluta, men det underliggande nätverket är borta så återanslutningen misslyckas. Efter 30 sekunder kommer nätverket tillbaka. Vad som händer nu beror på VPN-klientens beteende:
- Utan killswitch – i det ögonblick Wi-Fi kommer tillbaka återgår operativsystemets standardrutt till Wi-Fi-nätverkskortet. VPN-klienten försöker fortfarande återansluta, men dina appar väntar inte. Webbmailens bakgrundssynkronisering skickar nästa begäran via det oskyddade Wi-Fi med din riktiga IP och den DNS-resolver nätverket gav dig. När VPN:et väl är återanslutet (5–20 sekunder senare) har läckan redan skett.
- Med killswitch – när VPN:et kopplas ned installerar killswitchen en brandväggsregel som blockerar all trafik som inte går genom tunneln. Även när Wi-Fi kommer tillbaka kan dina appar inte skicka något förrän VPN-sessionen är fullt återupprättad. Webbmailens synkbegäran misslyckas med ett nätverksfel (appen försöker igen), men ingen trafik lämnar din enhet via det oskyddade nätverkskortet.
Problemet med tyst återfall är det centrala som killswitchar är utformade för att lösa. Det handlar inte om "VPN:et kraschade och nu surfar jag okrypterat" – det är det mycket subtilare fallet där VPN:et är kortvarigt otillgängligt, dina appar inte vet om det, och de läcker under den luckan.
De tre typerna av killswitch
När leverantörer säger "killswitch" kan de mena någon av dessa tre arkitekturer. Skillnaderna spelar roll eftersom felscenarierna skiljer sig åt.
1. Systemövergripande killswitch (brandväggsbaserad)
Den starkaste modellen. VPN-klienten installerar en brandväggsregel i operativsystemet – med pf på macOS, Windows Filtering Platform på Windows, iptables eller nftables på Linux, eller ett systemnätverkstillägg på iOS/Android – som blockerar varje utgående paket som inte är avsett för VPN-serverns IP. När VPN:et är uppe dirigerar tunneln själv trafiken till VPN-servern, så paket passerar. När VPN:et är nere matchar ingenting "tillåt"-regeln, så allt blockeras. Brandväggsregeln förblir på plats även om VPN-klienten kraschar, eftersom OS-brandväggen är oberoende av applikationen som installerade regeln.
2. App-nivå killswitch (per applikation)
Istället för att blockera all trafik blockerar killswitchen bara specifika appar du lagt till i en lista. När VPN:et tappas förlorar dessa appar nätverksanslutningen tills VPN:et återkommer; andra appar fortsätter fungera normalt. Det här är användbart för mycket specifika scenarier – att skydda en specifik webbläsare, IRC-klient eller BitTorrent-klient – men det är svagare som generellt skydd eftersom det lämnar en stor attackyta (systemfältsapparna, bakgrundstjänster, OS-komponenter och de appar du glömde lägga till i listan).
3. Nätverksnivå brandvägg (alltid-på VPN)
På Android specifikt finns ett starkare alternativ än de killswitchar som VPN-appar implementerar själva: systemnivåinställningen "Alltid-på VPN" med "Blockera anslutningar utan VPN" aktiverad. Det är OS:et självt som verkställer regeln – Android vägrar att dirigera icke-VPN-trafik överhuvudtaget, oavsett vilken app som frågar. Även om VPN-appen kraschar håller OS:et linjen. Det här är det mest robusta killswitch-beteendet som finns tillgängligt på mobil och är strikt starkare än app-implementerade killswitchar.
Hur varje typ faktiskt fungerar på OS-nivå
Implementationsdetaljerna spelar roll eftersom de förutsäger felscenarierna. En brandväggsbaserad killswitch misslyckas när brandväggens API är buggigt. En appbaserad killswitch misslyckas när appen kraschar. En OS-verkställd alltid-på VPN misslyckas i princip aldrig, om du inte startar om i säkert läge.
iOS-implementering – NetworkExtension och on-demand-regler
iOS exponerar inte ett bokstavligt "killswitch"-API till tredjeparts-VPN-appar. Vad det exponerar är NetworkExtension-ramverkets "on-demand rules"-mekanism: regler som säger "när som helst en app försöker göra en nätverksanslutning som inte matchar ett undantag, tvinga VPN att ansluta först." Om VPN:et inte kan etableras hänger anslutningsbegäran. Från användarens perspektiv beter sig detta som en killswitch – men det är egentligen en "tvinga VPN på"-regel snarare än en "blockera allt om VPN är nere"-regel. Det funktionella resultatet är liknande; implementationen är annorlunda.
NetworkExtension-API:et stöder också flaggan includeAllNetworks (tillagd i iOS 14) som gör VPN:et till ett systemnivånätverksfilter – även trafik från kärnan och systemtjänster tvingas genom VPN:et. Med den flaggan inställd fungerar VPN:et verkligen som en fullständig killswitch, med OS:et som garanterar att ingen trafik flödar utanför tunneln. Inte alla VPN-leverantörer aktiverar den; flaggan har kompatibilitetsimplikationer.
Android-implementering – Alltid-på VPN + Blockera anslutningar utan VPN
Androids starkaste killswitch-beteende finns i Inställningar, sedan Nätverk och internet, sedan VPN, sedan kugghjulsikonen bredvid ditt VPN, sedan de två reglageknapparna: "Alltid-på VPN" och "Blockera anslutningar utan VPN." När båda är på vägrar Android-systemet självt – inte VPN-appen – att dirigera trafik tills VPN:et är anslutet. VPN-appen kan krascha, tvångsstängas eller avinstalleras, och regeln kvarstår. Den officiella Android-utvecklardokumentationen beskriver mekanismen i detalj. Det här är guldstandarden för killswitch-beteende på konsumentmobilenheter.
macOS-implementering – systemnätverkstillägg
macOS 11 (Big Sur) och senare kör VPN via System Extension-ramverket – samma arkitektur som stöder innehållsfilter och systemnätverksfilter. Killswitchen implementeras vanligtvis som en paketfilterregel (pf) installerad av VPN-klienten, kombinerat med ett nätverkstillägg som håller routningstabellmodifieringen. När VPN:et tappas förblir pf-regeln på plats och fortsätter blockera trafik tills VPN:et återupprättas. Om VPN-klienten självt kraschar beror beteendet på om systemtillägget är konfigurerat att förbli inläst – väldesignade klienter håller reglerna på plats; dåligt designade klienter tar bort dem vid krasch och läcker.
Windows-implementering – Windows Filtering Platform
Windows VPN-appar implementerar vanligtvis killswitchen genom att installera Windows Filtering Platform (WFP)-filterregler som blockerar trafik på det fysiska nätverkskortet och tillåter trafik på det virtuella VPN-nätverkskortet. Filtren kvarstår vid omstart av VPN-klientprocessen (de ägs av kärnsfilterlagret, inte user-space-appen), så även om VPN-appen kraschar förblir filtret aktivt. Risken är att vissa VPN-klienter använder lägre kvalitet brandväggsregelstrategier – t.ex. manipulera Windows Defender Firewall via PowerShell eller netsh – som kan kringgås av andra brandväggsregler eller felkonfiguration.
När killswitchar misslyckas – läckscenarier att känna till
En killswitch är inte en perfekt garanti. Det finns väldokumenterade förhållanden under vilka trafik kan läcka även med en killswitch aktiverad. Varje VPN-leverantör hanterar dessa på olika sätt; vissa åtgärdas genom noggrann implementering, andra är oundvikliga utan samarbete på OS-nivå.
DNS-förgiftning under anslutningsetableringen
För att ansluta till VPN-servern måste VPN-klienten först lösa serverns värdnamn. Om killswitchen verkställer "ingen trafik utan VPN", men VPN-klienten självt behöver göra en DNS-sökning för att hitta VPN-servern, måste det finnas ett undantag – och det undantaget är en liten läckyta. Ett skadligt lokalt nätverk kan förgifta DNS-svaret och omdirigera VPN-klienten till en falsk server. De flesta klienter hanterar detta genom att använda en hårdkodad IP för VPN-servern, eller genom att fästa TLS-certifikatet så att en omdirigerad server inte validerar. Billiga VPN-klienter hoppar ibland över det här steget.
IPv6-läckor
Om ditt nätverk har IPv6-anslutning men VPN-klientens killswitch bara blockerar IPv4-trafik kan din IPv6-trafik flöda ut via det oskyddade nätverkskortet även när killswitchen är "aktiv." Det här är ett av de vanligaste verkliga läckscenarierna. Lösningen är att VPN-klienten installerar matchande IPv6-brandväggsregler. Många äldre klienter gör inte det. Testa alltid för IPv6-läckor efter att du aktiverat en killswitch genom att köra ett läcktest.
Captive portals (Wi-Fi-inloggningssidor)
Kaféer, flygplatser och hotell kräver ofta att du loggar in via en captive portal innan du kan nå internet – inklusive VPN-servern. En strikt killswitch vägrar låta dig nå captive portalen eftersom captive portalen inte är VPN-servern. De flesta VPN-klienter har ett "pausa killswitch för captive portal"-läge som du måste aktivera manuellt. Medan det är pausat är du oskyddad, så surfa inte på något känsligt tills killswitchen är tillbaka. Det OS-inbyggda alltid-på VPN:et på Android hanterar detta något smidigare via systemets captive portal-detektering, men avvägningen är densamma.
App-avstängning och bakgrundsomstart-lopp
På mobil kan OS:et stänga av VPN-appen för att spara batteri. När appen återupptas finns det ett litet fönster där tunneln håller på att återupprättas. Om killswitchen är implementerad på OS-nivå (via includeAllNetworks på iOS eller alltid-på VPN på Android) finns det ingen läcka. Om killswitchen är implementerad enbart i appen kan det finnas ett kort fönster där OS:et har återupptagit appar men VPN:et inte har återanslutit, och appar som gör nätverksanrop under det fönstret läcker.
Startsekvenslopp
På datorer är perioden mellan uppstart och att VPN-klienten startar oskyddad. Nätverksmedvetna appar som autostarter (Mail, Slack, Steam, systemuppdateringskontroller) gör ofta anslutningar innan VPN:et är uppe. En robust killswitch installerar sin brandväggsregel som en persistent startsekvensregel så att även vid uppstart blockeras trafik tills VPN:et ansluter. De flesta konsument-VPN-klienter gör inte detta; regeln tillämpas bara efter att klienten startar.
Jämförelse av killswitch-typer
| Typ | Vad den blockerar | OS-stöd | Vanliga felscenarier |
|---|---|---|---|
| Systemövergripande brandvägg | All icke-VPN-trafik på kärnnivå | macOS, Windows, Linux; iOS via includeAllNetworks | IPv6-läckor om regler bara gäller IPv4; startsekvenslopp; DNS-bootstrapundantag |
| App-nivå (per-app blocklista) | Bara listade appars trafik | Windows, vissa macOS-klienter | Appar inte på listan fortsätter läcka; OS-komponenter läcker; systemtjänster läcker |
| OS-verkställt alltid-på VPN | All trafik på OS-nivå, oavsett app-krasch | Android (Alltid-på VPN + Blockera utan VPN), iOS (NetworkExtension on-demand) | Captive portal-inloggning blockeras tills du pausar; väldigt få andra felscenarier |
| Applikationsmonitor (den svaga formen) | Ingenting direkt; stänger bara specificerade appar när VPN tappas | Vissa Windows-klienter levererar fortfarande detta | Lopp mellan detektering och stängning läcker; egentligen ingen riktig killswitch |
Vad "alltid-på VPN" verkligen ger dig som en app-nivå killswitch inte gör
Den viktigaste distinktionen 2026 är mellan leverantörsimplementerade killswitchar och OS-verkställda alltid-på VPN. Här är varför den OS-verkställda versionen är meningsfullt starkare:
- Överlever VPN-app-krascher. Om VPN-appen kraschar av något skäl dör en app-nivå killswitch med den. Brandväggsregeln den installerade kan kvarstå eller inte beroende på implementationen. En OS-verkställd regel hålls av OS:et självt och fortsätter gälla.
- Överlever omstarter. Många app-nivå killswitchar installerar regler vid appstart och tar bort dem vid appavslutning, vilket lämnar en lucka vid uppstart. OS-nivå alltid-på-inställningar respekteras från det första nätverkspaketet som OS:et dirigerar efter uppstart.
- Täcker systemtjänster. Molnsynkronisering, OS-uppdateringskontroller, push-notifikationsdaemonar och andra OS-nivåtjänster går inte via normal VPN-klientrouting. OS-verkställt alltid-på täcker dem; en app-nivå killswitch kanske inte gör det.
- Kan inte kringgås av misstag från användare. En app-nivå killswitch har en reglage i appens gränssnitt. En användare (eller en annan app med behörigheter) kan inaktivera den. OS-nivå alltid-på finns i systeminställningarna och är svårare att råka stänga av.
På Android, föredra den OS-verkställda versionen: aktivera "Alltid-på VPN" och "Blockera anslutningar utan VPN" i systeminställningarna, och behandla VPN-klientens egna killswitch som ett tillägg. På iOS, leta efter VPN-klienter som väljer att använda includeAllNetworks; det är den motsvarande flaggan och den ger liknande garantier.
Vad Casper gör – det ärliga svaret
Casper's Cloak använder en OS-integrerad killswitch på varje plattform – includeAllNetworks på iOS så att OS:et självt verkställer no-leak-regeln, alltid-på VPN-inställningarna på Android, och paketfilterregler på kärnnivå på macOS. Beteendet är detsamma på alla tre: när tunneln tappas stoppas all trafik, inklusive IPv6 och inklusive OS-nivåtjänster. När tunneln återkommer återupptas trafiken. Inget reglage att glömma, ingen per-app-lista att underhålla, ingen IPv6-lucka.
Vi kombinerar detta med hotskydd och hotskärm för aktiv filtrering mot kända skadliga domäner, så tunneln är inte bara ett routinglager – den avvisar aktivt anslutningar till nätfiske, skadlig programvara C2 och känd skadlig infrastruktur. Killswitchen är det bottenlager som garanterar att ingenting kringgår filtreringen när tunneln kortvarigt tappas. Den kombinerade effekten: även på fientliga nätverk som de som täcks i vår genomgång av attacker mot offentligt Wi-Fi, undviker du det "två sekunders klartext"-fönster som en app-nivå-only killswitch lämnar öppet.
Vår ståndpunkt om killswitchar generellt: det är en grundläggande förväntning, inte en premiumfunktion. Alla konsument-VPN som inte erbjuder en 2026 saknar en grundläggande säkerhetsmekanism. För hotsmodelleringsbakgrunden om varför detta spelar roll på systemnivå täcker NSA:s vägledning om val och härdning av VPN för fjärråtkomst den arkitektoniska motiveringen i detalj, med en rekommendation till förmån för full-tunnel-arkitekturer stödda av verkställighet på kärnnivå.
Slutsats
"Har det här VPN:et en killswitch" är fel fråga. De rätta frågorna är: var i stacken verkställs killswitchen (app, system eller OS), täcker den IPv6, kvarstår den vid app-krascher och omstarter, och är den på som standard. Om svaren är "OS-nivå", "ja", "ja" och "ja" gör killswitchen sitt jobb. Om svaren är "bara app-nivå", "nej", "beror på" och "av som standard" har du en killswitch till namnet men inte till skyddet.
Den enkla praktiken: på Android, aktivera alltid-på VPN på systemnivå med "Blockera anslutningar utan VPN." På iOS, använd en VPN-klient som aktiverar includeAllNetworks. På datorer, verifiera efter installation genom att köra ett läcktest, koppla sedan kortvarigt ned VPN-serversidan (eller dra ut nätverkskabeln) och bekräfta att trafiken faktiskt stoppas. Om läcktestet fortfarande visar din riktiga IP fungerar inte killswitchen som annonserat – undersök detta innan du litar på den.