Vad som händer i det ögonblick tunneln bryts
Anslutningen öppnas upp. Ett VPN lägger till rutter som styr trafiken in i ett virtuellt nätverksgränssnitt. När tunnelprocessen dör eller får timeout försvinner dessa rutter, medan standardrutten via Wi-Fi eller Ethernet finns kvar — så systemet fortsätter att skicka paket, nu direkt via din internetleverantör. Apparna återansluter sina sockets inom några sekunder och skickar trafik från din riktiga IP-adress, utan någon felruta någonstans.
Avbrott hör till vardagen. Att byta från Wi-Fi till mobildata, en laptop som vaknar ur viloläge, ett ostabilt hotellnätverk eller en omstart av VPN-servern bryter alla tunneln för en kort stund. Vad den stunden kostar beror på om något alls får lämna din enhet medan tunneln är nere.
Vad en kill switch egentligen gör
En kill switch är en uppsättning brandväggsregler, inte magi. Den strikta varianten tillåter bara två sorters utgående trafik: paket som går in i tunnelgränssnittet och VPN-klientens egna krypterade paket till servern. Om tunneln går ner har apptrafiken helt enkelt ingenstans att ta vägen förrän den är tillbaka.
Det förändrar hur felet yttrar sig snarare än förhindrar felen. Med en kill switch blir ett avbrott en pausad anslutning som du märker; utan en blir det trafik från din riktiga adress som du inte märker. Nätverk är inte perfekta och tunneln kommer fortfarande att brytas — att den stängs igen gör de stunderna ofarliga.
Kill switch i systemet eller i appen
Skillnaden ligger i vad som händer när själva appen dör. En kill switch i appen är kod i VPN-klienten som övervakar tunneln och blockerar trafiken när den bryts. Den fungerar bara så länge klienten körs: om klienten kraschar eller stängs av en batterioptimerare dör skyddet med den — i exakt det ögonblick tunneln försvinner.
En kill switch på systemnivå lägger in regler i operativsystemets egen brandvägg, som granskar varje utgående paket oavsett vilka appar som körs. Android har detta inbyggt: alltid-på-VPN tillsammans med blockering av anslutningar utan VPN gör att själva operativsystemet vägrar släppa igenom trafik utanför tunneln, till och med innan appen startat efter en omstart. Det enkla sättet att se skillnaden: tvångsavsluta VPN-appen medan du surfar — om sidorna fortfarande laddas sitter kill switchen i appen.
DNS-läckor: förfrågningar som går förbi tunneln
En DNS-läcka innebär att dina namnuppslagningar går till den resolver som ditt lokala nätverk tilldelat — oftast internetleverantörens — trots att själva trafiken går genom tunneln. Webbplatserna ser VPN-adressen, men resolvern får namnet på varje sida du öppnar, vilket i praktiken är en surflogg. Windows är den klassiska syndaren: med flera aktiva gränssnitt kan det fråga alla parallellt och använda det svar som kommer först.
Lösningen har två delar, och en bra klient gör båda: pekar systemet mot resolvern inne i tunneln och blockerar DNS på alla andra gränssnitt så att en förirrad fråga inte har någonstans att ta vägen. Kontrollera sedan: kör ett läcktest och granska resolvrarna som listas — om någon tillhör din internetleverantör läcker uppslagningarna.
WebRTC-läckor: webbläsaren lämnar ut adresser
WebRTC är webbläsartekniken bakom videosamtal, och vilken webbplats som helst kan anropa den med några rader JavaScript. För att sätta upp direkta anslutningar samlar den in varje adress som skulle kunna nå din dator: lokala adresser och, genom att fråga en STUN-server, din publika. En sida kan läsa av dessa kandidater utan att du behöver göra något.
Med en tunnel för hela enheten går STUN-förfrågan inne i tunneln, så den hittar VPN:ets adress. De farliga uppsättningarna är de partiella: en proxy enbart för webbläsaren eller delad tunnel som lämnar webbläsaren utanför — då går WebRTC:s UDP-paket ut direkt och avslöjar din riktiga IP-adress.
Testa i stället för att resonera: vårt kostnadsfria verktyg på /webrtc-leak-test/ visar vilka adresser din webbläsare avslöjar just nu. Om den riktiga dyker upp bör du gå över till en tunnel för hela enheten eller stänga av WebRTC i webbläsarens inställningar.
IPv6-läckor: tunneln täcker bara IPv4
Många VPN-konfigurationer hanterar enbart IPv4. Om din operatör även levererar IPv6 – vilket de flesta mobilnät gör – behåller systemet en fungerande IPv6-väg utanför tunneln, och moderna system föredrar IPv6 när en sajt erbjuder båda. Resultatet blir selektiv exponering: sajter utan IPv6 ser VPN-adressen, sajter med IPv6 ser din riktiga adress, och ett test som bara kontrollerar IPv4 rapporterar att allt är i sin ordning.
Det finns två rena lösningar. Den bättre är ett VPN som hanterar IPv6 ordentligt – antingen genom att tunnla det tillsammans med IPv4 eller genom att lägga in en blockerande rutt så att IPv6-paket kastas i stället för att skickas direkt. Den enklare nödlösningen är att stänga av IPv6 på enheten eller routern. Oavsett vilket: verifiera. Läcktestet ska inte visa någon IPv6-adress som inte tillhör VPN-tjänsten.
Så testar du din uppsättning på rätt sätt
Kör kontrollerna under de förhållanden du faktiskt använder – hemma på Wi-Fi, med mobildata i telefonen, på ett kafénätverk – eftersom läckor beror på varje nätverks DNS-inställningar och tillgång till IPv6. Rutinen tar ungefär fem minuter:
- Notera din riktiga IP med VPN avstängt, anslut och bekräfta att både den synliga IPv4- och IPv6-adressen har ändrats – vår /data-leak-checker/ visar IP, DNS-resolvrar och WebRTC i ett och samma svep
- Kontrollera listan över resolvrar: alla DNS-servrar som visas ska tillhöra VPN-tjänsten, ingen din operatör
- Bryt tunneln med flit – slå av och på Wi-Fi eller tvångsavsluta appen – och se om sidor laddas innan den hinner återansluta
- Upprepa efter uppdateringar av operativsystemet eller VPN-appen, eftersom båda i tysthet kan återställa nätverksinställningar