Vad är delad tunneling — hur VPN-routing per app faktiskt fungerar

Kortversionen: ett vanligt VPN skickar 100% av enhetens trafik genom den krypterade tunneln. Delad tunneling bryter med det regeln avsiktligt. Du väljer vilka appar eller destinationer som kringgår tunneln och går direkt via din vanliga anslutning. Det låter enkelt, och i princip är det så — men den praktiska implementationen skiljer sig avsevärt mellan operativsystem, och integritetsavvägningarna är lätta att missa. En streamingapp som skickas utanför tunneln ser fortfarande din riktiga IP-adress. En bankapp som skickas utanför tunneln kommunicerar fortfarande med din bank via ditt hemnätverk — vilket är okej, tills samma app även gör en DNS-förfrågan som läcker via omvägen och avslöjar en annan domän du inte avsett att röja.

Vad VPN-tunneling faktiskt gör (utgångspunkten)

Innan du kan förstå vad som delas behöver du ha klart för dig vad den fullständiga tunneln gör. En VPN-klient som körs på din enhet skapar ett virtuellt nätverksgränssnitt — på Linux kallas det vanligtvis tun0 eller wg0, på macOS är det utun, på iOS och Android hanterar operativsystemet det via ett app-specifikt tilläggs-API. Operativsystemets routingtabell ändras sedan så att standardrutten — regeln som säger "skicka paket utan annan matchande rutt till den här gatewayen" — pekar på det virtuella gränssnittet i stället för ditt fysiska Wi-Fi eller mobilgränssnitt.

Från och med det krypteras varje paket som din enhet genererar av VPN-klienten, paketeras in i ett nytt IP-huvud som riktar sig mot VPN-servern, och skickas ut via det fysiska gränssnittet som en enda homogen ström. VPN-servern dekrypterar paketet, vidarebefordrar det till sin riktiga destination på det publika internet, tar emot svaret, krypterar det igen och skickar tillbaka det. Din internetleverantör ser bara den krypterade strömmen som går till en enda IP-adress. Destinationswebbplatser ser VPN-serverns IP, inte din.

Det är standardbeteendet. Delad tunneling griper in i den här modellen genom att lägga till mer specifika rutter i routingtabellen — regler som säger "för trafik till den här destinationen" eller "för trafik som genereras av den här appen, ignorera standardtunnelrutten och använd det fysiska gränssnittet direkt."

Vad delad tunneling förändrar

Konceptuellt introducerar delad tunneling en förgrening i ditt nätverksflöde. En del paket går genom den krypterade tunneln, andra går via det rena gränssnittet. Beslutet fattas av VPN-klienten utifrån regler du konfigurerar. Det finns tre vanliga kategorier av delningsregler:

• App-baserad — "Skicka all trafik från Netflix utanför tunneln; tunnla allt annat." Implementeras genom att märka paket med ursprungsprocessens UID eller PID och sedan fatta routingbeslut per märkning.
• Destinations-baserad — "Skicka trafik till 10.0.0.0/8 utanför tunneln så att jag kan nå min hemma-NAS; tunnla allt annat." Implementeras enbart med routingtabellsposter — den enklaste formen.
• URL- eller domänbaserad — "Skicka trafik till *.bank.com utanför tunneln." Det här är skört eftersom OS:ets routinglager inte känner till domäner nativt; det kräver att VPN-klienten antingen fångar upp DNS och skriver om svar, eller underhåller en dynamisk IP-tillåtelselista som följer DNS-upplösningar. Leverantörer implementerar detta inkonsekvent.

Här är den arkitektoniska bilden, förenklat:

Full tunnel (ingen delning):
  [App A] -> [App B] -> [App C]
        \        |        /
         [Virtuellt VPN-gränssnitt]
                 |
         [Krypterad tunnel]
                 |
         [VPN-server] -> internet

Delad tunnel (app-baserad, App C undantagen):
  [App A] -> [App B]        [App C]
        \        /               \
   [Virtuellt VPN-gränssnitt]   [Fysiskt Wi-Fi]
              |                    |
       [Krypterad tunnel]    [Okrypterat internet]
              |                    |
        [VPN-server]         direkt till dest

"Delningen" är förgreningspunkten inuti ditt operativsystem — valet mellan virtuellt gränssnitt och fysiskt gränssnitt görs innan kryptering sker, så ett paket som kringgår tunneln var aldrig krypterat från första början. Det finns inget dekrypteringssteg; det lämnar bara din enhet som det är.

Omvänd delad tunneling — tillåtelselista kontra blocklista

Konfigurationer för delad tunneling finns i två varianter som ser symmetriska ut men har mycket olika standardfelsbeteende:

• Blocklistläge (vanlig standard) — "Tunnla allt utom apparna/destinationerna på den här listan." Standardläget är skyddat; bara specifika undantag läcker. Om du glömmer att lägga till en app i listan förblir den skyddad.
• Tillåtelselistläge (även kallat omvänd delad tunneling) — "Tunnla bara apparna/destinationerna på den här listan; allt annat går direkt." Standardläget är oskyddat; bara specifika appar tunnlas. Om du glömmer att lägga till en app i listan läcker den.

Tillåtelselistläge är rätt val om du vill att "bara min webbläsare ska använda VPN, allt annat kan använda min vanliga anslutning." Blocklistläge är rätt val om du vill att "de flesta saker ska skyddas, men ett fåtal specifika appar behöver det riktiga nätverket." De flesta konsumenter vill ha blocklistläge. Drifts- och DevOps-team föredrar ibland tillåtelselistläge eftersom de försöker exponera specifika tjänster via tunneln utan att störa resten av systemet.

Felläget för tillåtelselistläge är allvarligt: om du lägger till en ny app och glömmer att lägga till den i tillåtelselistan läcker appens trafik. Felläget för blocklistläge är mildare: glömda appar förblir skyddade — du får bara irriterande kompatibilitetsproblem när en streaming- eller bankapp misslyckas för att den ser VPN-IP-adressen.

När du bör använda delad tunneling — fem konkreta scenarier

Delad tunneling har verkliga legitima användningsområden. Det här är situationerna där det är rätt verktyg:

1. Streamingtjänster som identifierar och blockerar VPN-slutpunkter

Netflix, Disney+, Hulu, och de flesta regionala TV-kanaler underhåller stora tillåtelselistor med kända VPN-datacenter-IP-adresser och vägrar strömma när de identifierar en. Du kan antingen stänga av VPN:et (och förlora allt skydd) eller dela tunneln för streamingappen så att den ser din riktiga IP medan allt annat förblir skyddat.

2. Bank- och finansappar med platsbaserad bedrägeridetektering

Banker behandlar ofta en plötslig IP-adressändring till ett VPN-datacenter som en bedrägerisignal — de utlöser extra autentisering, håller tillbaka transaktioner, eller låser tillfälligt kontot. Att dela bankappens trafik utanför tunneln håller din relation med banken via riktiga IP-adresser konsekvent. Det här är en användbarhetsförbättring, inte en säkerhetsuppgradering — bankens anslutning är redan TLS-krypterad, så VPN:et tillförde aldrig mycket säkerhet till just den sessionen.

3. Lokala nätverksresurser (NAS, skrivare, smarta hem-enheter)

När VPN:et fångar all trafik kan din enhet inte längre nå skrivaren på 192.168.1.50 eftersom den IP-adressen inte är nåbar via VPN-tunneln. Destinations-baserad delad tunneling (som undantar 192.168.0.0/16 och 10.0.0.0/8) återställer lokal åtkomst utan att inaktivera VPN:et för det publika internet. Många VPN-klienter gör det här automatiskt som standard; andra inte.

4. Latenskänsliga applikationer

Tävlingsinriktat onlinespelande, direktsänd videokonferens och röstsamtal drabbas när extra latens introduceras genom att routas via en VPN-server i en avlägsen region. Att dela ut de specifika apparna kan återvinna latensen medan allt annat hålls krypterat. Avvägningen: dessa appar är nu identifierbara för din internetleverantör och synliga för nätverksobservatörer.

5. Arbets-VPN kombinerat med personliga VPN

Om din arbetsgivare kräver ett företags-VPN för att komma åt interna resurser, och du vill att personlig trafik ska gå via ett annat (integritetsfokuserat) VPN, innebär delad tunneling på företagets VPN — att bara skicka företagets IP-intervall genom det — att resten av din trafik finns tillgänglig för det personliga VPN:et. Det här är en konfiguration för avancerade användare men ett rent sätt att hålla arbets- och personlig trafik separerad.

När du INTE bör använda delad tunneling — integritetsfallfällornas

Delad tunneling gör ditt nätverksbeteende mer komplext, och komplext nätverksbeteende läcker på icke-uppenbara sätt. De vanligaste felmöderna:

DNS-läckor via omvägsvägen

Även när en apps TCP-trafik skickas utanför tunneln kan dess DNS-förfrågningar fortfarande vara konfigurerade att använda VPN:ets DNS-resolver — eller ännu värre, falla tillbaka till internetleverantörens DNS-resolver om VPN-klienten inte hanterar system-DNS noggrant. Resultatet: en app som borde vara osynlig för din internetleverantör blir delvis synlig. Internetleverantören ser DNS-förfrågan för banking.example.com även om den efterföljande TCP-anslutningen gick via en annan väg. Vi har en djupare genomgång av hur DNS-kryptering passar in i vår DNS-over-HTTPS-guide.

App-kontra-domänförvirring

App-baserad delad tunneling routar via processidentitet, men moderna appar gör anslutningar till många domäner. Din "streamingapp" laddar troligen annonser, telemetri, rekommendations-API:er och analysändpunkter från dussintals olika domäner — varav en del delas med appar som du vill ska tunnlas. Att undanta hela appen innebär att undanta alla dessa anslutningar. Domänbaserad delad tunneling har det omvända problemet: en enda app kan ladda samma CDN-domän för både streamingvideon (som du vill ska vara oskyddad) och för innehåll du helst inte vill avslöja.

IPv6-läckor

Många implementationer av delad tunneling designades när IPv4 var det enda routingproblemet. Om ditt nätverk har IPv6-anslutning och reglerna för delad tunnel inte explicit inkluderar IPv6-rutter kan paket som borde tunnlas lämna via IPv6 utanför tunneln. Det här är ett av de vanligaste VPN-läckorna 2026 och orsakas nästan alltid av ofullständig konfiguration av regler för delad tunnel. Testa med ett IPv6-läckagetest efter att du aktiverat delad tunneling.

Kill switch-interaktioner

En kill switch är utformad för att blockera all trafik om VPN:et faller bort, så ingenting läcker oskyddat. Med delad tunneling aktiverad blir kill switch-logiken svårare — kill switchen bör fortfarande tillåta appar med delad tunneling att kommunicera, men bara de, och bara när VPN:et självt också är nere. Många VPN-klienter har buggar där kill switchen antingen misslyckas med att blockera tunnlade appar när VPN:et faller bort, eller felaktigt blockerar appar med delad tunnel som borde fortsätta fungera. Testa kombinationen explicit.

Jämförelse av lägen för delad tunneling

Hur delad tunneling fungerar på respektive operativsystem

iOS — begränsat och indirekt

iOS exponerar inget äkta split-tunneling-API till tredjeparts-VPN-appar. NetworkExtension-ramverket tillåter att ett VPN konfigureras antingen systemövergripande (all trafik) eller per app (bara appar som explicit registrerats av en MDM-profil). Äkta per-app split-routing kräver Apples NEAppProxyProvider med en MDM-distribuerad konfigurationsprofil — vilket innebär ett hanterat enhetsscenariot. Konsument-VPN-appar på iOS som annonserar "delad tunneling" implementerar vanligtvis destinations-baserade undantag (t.ex. undantar specifika IP-intervall från tunneln) eller använder on-demand-regler-API:et för att villkorligt aktivera VPN baserat på Wi-Fi SSID eller domänmatchning. App-baserad delad tunneling för konsument-iOS-användare är egentligen inte tillgängligt.

Android — förstklassigt stöd

Androids VpnService-API stöder per-app-routing nativt. VPN-klienten kan anropa addAllowedApplication() eller addDisallowedApplication() för att specificera vilka appar som går genom tunneln. OS hanterar per-app-routingen transparent — VPN-klienten behöver inte göra paketaggregering. Android stöder även systeminställningen "Alltid aktiv VPN" med alternativet "Blockera anslutningar utan VPN", vilket kombinerar kill switch-beteende med per-app-konfigurationen: tunnlade appar går igenom, icke-tunnlade appar går direkt, och om VPN:et faller bort blockeras tunnlade appar.

macOS — implementationen varierar

macOS stöder delad tunneling via flera mekanismer: NetworkExtension-ramverket (liknande iOS, med mer flexibilitet), paketfilter konfigurerade via pf-regler, eller routingtabellmanipulation av VPN-klienter som kör med förhöjda privilegier. App-baserad delad tunneling på macOS fungerar men kräver att VPN-klienten frågar kärnan om socket-till-process-mappningar. Destinations-baserad delning är enkel och tillförlitlig.

Windows — vanligaste plattformen för delad tunneling

Windows VPN-klienter har använt delad tunneling i över ett decennium. Windows Filtering Platform (WFP) tillhandahåller det kärndelskontrollerade paketinspektions- och routingbesluts-API som VPN-klienter kopplar in i. Per-app delad tunneling på Windows är välstöddat och brett distribuerat. De flesta VPN-driftsättningar i företag använder Windows delad tunneling för att säkerställa att företagstrafik går via företagstunneln medan generell internettrafik går direkt — delvis för prestanda, delvis för att minska belastningen på företagets VPN-koncentratorer.

Vanliga misstag vid konfiguration av delad tunneling

Att observera hur folk faktiskt felkonfigurerar delad tunneling avslöjar ett fåtal återkommande mönster. Om du konfigurerar det, kontrollera dig mot den här listan:

• Att inte testa för DNS-läckor efter att ha aktiverat det. Kör ett läckagetest (dnsleaktest.com eller liknande) efter varje konfigurationsändring. Om du ser din internetleverantörs DNS-resolver listad för en app som borde tunnlas, läcker omvägen DNS.
• Att glömma att webbläsare är speciella. En webbläsare som kör en streaming-webbapp skickar både streamingvideon och dina övriga flikar via samma process. Att undanta webbläsaren undantar all din surfning. Använd en separat webbläsarprofil eller en annan app för streamingfallet.
• Att inte hantera IPv6. Inaktivera IPv6 helt om din VPN-klient inte hanterar det explicit. Läckagehastigheten från glömda IPv6-regler för delad tunnel är hög.
• Att använda domänbaserade regler för säkerhetskritiska beslut. Domänbaserad delad tunneling är bra för användbarhetsjusteringar. Det är inte tillförlitligt nog för att tvinga fram att "den här känsliga appen alltid måste gå via VPN" — för det, använd app-baserade regler med appen explicit tunnlad, helst i tillåtelselistläge.
• Att inte granska reglerna kvartalsvis. Appar läggs till och tas bort; nya appar från samma utgivare ärver ingenting från de gamla. Granska regelbundet din regeluppsättning för delad tunneling.

Den ärliga domen om delad tunneling

Delad tunneling är genuint användbart för specifika problem — streamingappar som identifierar VPN, bankappar som flaggar VPN-inloggningar, lokal nätverksåtkomst — och har en lång historia av legitim driftsättning i företagsmiljöer. För konsumenter är den ärliga inramningen att det är ett verktyg för användbarhet i första hand och ett integritetsskydd i andra hand. Varje regel för delad tunnel försämrar skyddsmodellen på något specifikt sätt, och säkerhetsavvägningen är bara värd det när skyddet ändå inte hade hjälpt den trafiken (t.ex. en banksession som redan är TLS-krypterad och går till en enda välkänd destination).

Om din hotmodell är "Jag vill ha ett VPN på fientliga offentliga Wi-Fi-nätverk så att den lokala nätverksoperatören inte kan observera min trafik", är en full tunnel rätt svar. Aktivera inte delad tunneling bara för att VPN-klienten erbjuder det — varje undantag är ett hål. Om din hotmodell är "Jag vill att de flesta trafiken ska skyddas men specifika appar behöver det riktiga nätverket", är delad tunneling rätt verktyg, men konfigurera det noggrant, testa för DNS- och IPv6-läckor efteråt, och granska reglerna regelbundet. Den tekniska referensen i WireGuard quickstart-dokumentationen visar hur de underliggande routingbesluten fungerar på protokollnivå.

Casper's Cloak använder en full-tunnel-arkitektur som standard eftersom hotmodellen vi skyddar mot — fientliga nätverk, internetleverantörsövervakning, annonsteknologispårning — gynnas av den enklare "tunnla allt"-modellen. Vi kombinerar det med spårningsfiltrering på DNS-nivå och AI-hotdetektering för kända skadliga destinationer, så den fullständiga tunneln gör även aktiv filtrering — inte bara routing. För streaming- och banksituationer är det rätta steget vanligtvis att koppla från tillfälligt snarare än att underhålla en permanent uppsättning undantag för delad tunneling som du kommer att glömma bort.