Hva er split-tunneling – slik fungerer VPN-ruting per app i praksis

Kort fortalt: en standard VPN ruter 100 % av enhetens trafikk gjennom den krypterte tunnelen. Split-tunneling bryter bevisst den regelen. Du velger hvilke apper eller hvilke destinasjoner som skal omgå tunnelen og gå rett ut via den vanlige tilkoblingen. Det høres enkelt ut, og konseptuelt er det det – men den praktiske implementeringen varierer betydelig mellom operativsystemer, og personvern-avveiningene er lette å overse. En strømme-app som rutes utenfor tunnelen ser fortsatt din ekte IP. En bankapp som rutes utenfor tunnelen kommuniserer fortsatt med banken din over hjemmenettverket – noe som er greit, helt til samme app sender et DNS-spørsmål som lekker gjennom omveien og avslører et annet domene du ikke hadde til hensikt å eksponere.

Hva VPN-tunneling faktisk gjør (utgangspunktet)

Før du kan forstå hva som splittes, må du ha klart for deg hva den fulle tunnelen gjør. En VPN-klient som kjører på enheten din oppretter et virtuelt nettverksgrensesnitt – på Linux kalles det typisk tun0 eller wg0, på macOS heter det utun, på iOS og Android administrerer operativsystemet det gjennom en per-app-utvidelse-API. Operativsystemets rutingstabell endres deretter slik at standardruten – regelen som sier «send pakker uten annen matchende rute til denne gatewayen» – peker mot det virtuelle grensesnittet i stedet for det fysiske Wi-Fi- eller mobilgrensesnittet.

Fra det tidspunktet krypterer VPN-klienten alle pakker enheten genererer, pakker dem inn i en ny IP-header som peker mot VPN-serveren, og sender dem ut via det fysiske grensesnittet som en enhetlig strøm. VPN-serveren dekrypterer pakken, videresender den til den virkelige destinasjonen på det offentlige internett, mottar svaret, krypterer det igjen og sender det tilbake. Din internettleverandør ser bare den krypterte strømmen til én enkelt IP. Destinasjonsnettsteder ser VPN-serverens IP, ikke din.

Det er standardoppsettet. Split-tunneling griper inn i denne modellen ved å legge til mer spesifikke ruter i rutingstabellen – regler som sier «for trafikk til denne destinasjonen» eller «for trafikk fra denne appen, ignorer standard tunnelrute og bruk det fysiske grensesnittet direkte».

Hva split-tunneling endrer

Konseptuelt introduserer split-tunneling et veiskille i nettverksflyten din. Noen pakker går gjennom den krypterte tunnelen; andre går ut via det direkte grensesnittet. Beslutningen tas av VPN-klienten etter regler du konfigurerer. Det finnes tre vanlige kategorier av split-regler:

• App-basert – «Send all trafikk fra Netflix utenfor tunnelen; tunnel alt annet.» Implementeres ved å merke pakker med prosessens UID eller PID, og deretter ta rutingsbeslutninger per merke.
• Destinasjonsbasert – «Send trafikk til 10.0.0.0/8 utenfor tunnelen så jeg kan nå min lokale NAS; tunnel alt annet.» Implementeres utelukkende med rutingstabelloppføringer – den enkleste formen.
• URL- eller domenebasert – «Send trafikk til *.bank.com utenfor tunnelen.» Dette er skjørt fordi OS-rutingslaget ikke kjenner til domener; det krever at VPN-klienten enten fanger opp DNS og omskriver svar, eller vedlikeholder en dynamisk IP-tillatelsesliste som følger DNS-oppslag. Leverandører implementerer dette inkonsekvent.

Her er det arkitektoniske bildet, forenklet:

Full tunnel (ingen split):
  [App A] -> [App B] -> [App C]
        \        |        /
         [Virtuelt VPN-grensesnitt]
                 |
         [Kryptert tunnel]
                 |
         [VPN-server] -> internett

Split-tunnel (app-basert, App C utelatt):
  [App A] -> [App B]        [App C]
        \        /               \
   [Virtuelt VPN-grensesnitt]   [Fysisk Wi-Fi]
              |                    |
       [Kryptert tunnel]    [Ukryptert internett]
              |                    |
        [VPN-server]         direkte til dest

«Splitten» er divergenspunktet inne i operativsystemet ditt – valget mellom virtuelt grensesnitt og fysisk grensesnitt tas før kryptering skjer, så en pakke som omgår tunnelen ble aldri kryptert i utgangspunktet. Det er ingen dekrypteringstrinn; den forlater bare enheten din som den er.

Invers split-tunneling – tillatelsesliste vs. blokkeringsliste

Split-tunneling-konfigurasjoner finnes i to varianter som ser symmetriske ut, men som har svært ulik standardfeilatferd:

• Blokkeringslistemodus (vanlig standard) – «Tunnel alt unntatt appene/destinasjonene på denne listen.» Standarden er beskyttet; bare spesifikke unntak lekker. Hvis du glemmer å legge til en app på listen, forblir den beskyttet.
• Tillatelseslistemodus (også kalt invers split-tunneling) – «Tunnel bare appene/destinasjonene på denne listen; alt annet går direkte.» Standarden er ubeskyttet; bare spesifikke apper tunneles. Hvis du glemmer å legge til en app på listen, lekker den.

Tillatelseslistemodus er riktig valg for «Jeg vil bare at nettleseren min skal bruke VPN, alt annet kan bruke min vanlige tilkobling.» Blokkeringslistemodus er riktig valg for «Jeg vil ha de fleste ting beskyttet, men noen få spesifikke apper trenger det ekte nettverket.» De fleste forbrukere vil ha blokkeringslistemodus. Drifts- og DevOps-team foretrekker noen ganger tillatelseslistemodus fordi de forsøker å eksponere spesifikke tjenester gjennom tunnelen uten å forstyrre resten av systemet.

Feilscenarioet for tillatelseslistemodus er alvorlig: hvis du legger til en ny app og glemmer å legge den til i tillatelseslisten, lekker den appens trafikk. Feilscenarioet for blokkeringslistemodus er mildere: glemte apper forblir beskyttet – du får bare irriterende kompatibilitetsproblemer når en strømme- eller bankapp feiler fordi den ser VPN-IP-en.

Når du bør bruke split-tunneling – fem konkrete scenarioer

Split-tunneling har reelle legitime bruksområder. Dette er situasjonene der det er riktig verktøy:

1. Strømmetjenester som oppdager og blokkerer VPN-endepunkter

Netflix, Disney+, Hulu og de fleste regionale kringkastere vedlikeholder store tillatelseslister over kjente VPN-datasenter-IP-er og nekter å strømme når de oppdager en. Du kan enten slå av VPN-en (og miste all beskyttelse) eller split-tunnele strømmeappen slik at den ser din ekte IP mens alt annet forblir beskyttet.

2. Bank- og finansapper med stedsbasert svindeldeteksjon

Banker behandler ofte et plutselig IP-bytte til et VPN-datasenter som et svindelsignal – de vil utløse ekstra autentisering, holde transaksjoner tilbake eller kort låse kontoen. Å splitte bankens app ut av tunnelen holder ditt ekte-IP-forhold til banken konsistent. Dette er en brukervennlighetskorrigering, ikke en sikkerhetsoppgradering – bankens tilkobling er allerede TLS-kryptert, så VPN-en ga aldri mye sikkerhet til den spesifikke sesjonen uansett.

3. Lokale nettverksressurser (NAS, skriver, smarthjem)

Når VPN-en fanger all trafikk, kan enheten din ikke lenger nå skriveren på 192.168.1.50 fordi den IP-en ikke er nåbar gjennom VPN-tunnelen. Destinasjonsbasert split-tunneling (ekskludering av 192.168.0.0/16 og 10.0.0.0/8) gjenoppretter lokal tilgang uten å deaktivere VPN-en for det offentlige internett. Mange VPN-klienter gjør dette automatisk som standard; noen gjør det ikke.

4. Latens-sensitive applikasjoner

Konkurransespilling på nett, direktesendt videokonferanser og taleanrop lider når ekstra latens introduseres ved å rute gjennom en VPN-server i en fjern region. Å splitte disse spesifikke appene ut kan gjenvinne latensen mens alt annet forblir kryptert. Avveiningen: de appene er nå identifiserbare for internettleverandøren din og synlige for nettverksobservatører.

5. Jobb-VPN-er ved siden av personlige VPN-er

Hvis arbeidsgiveren din krever en bedrifts-VPN for tilgang til interne ressurser, og du vil ha personlig trafikk gjennom en annen (personvernfokusert) VPN, lar split-tunneling på bedrifts-VPN-en – som bare sender bedriftens IP-områder gjennom den – resten av trafikken din gå til den personlige VPN-en. Dette er et avansert oppsett, men det er en ryddig måte å holde jobb- og persontrafikk atskilt.

Når du IKKE bør bruke split-tunneling – personvernfellene

Split-tunneling gjør nettverksatferden din mer kompleks, og kompleks nettverksatferd lekker på ikke-åpenbare måter. De vanligste feilscenarioene:

DNS-lekkasjer gjennom omveisbanen

Selv når en apps TCP-trafikk rutes utenfor tunnelen, kan DNS-spørsmålene fortsatt være konfigurert til å bruke VPN-ens DNS-løser – eller verre, kan falle tilbake til internettleverandørens DNS-løser hvis VPN-klienten ikke håndterer system-DNS forsiktig. Resultatet: en app som burde være usynlig for internettleverandøren din blir delvis synlig. Leverandøren ser DNS-spørsmålet for banking.example.com selv om den påfølgende TCP-tilkoblingen gikk gjennom en annen bane. Vi har en dypere gjennomgang av hvordan DNS-kryptering passer inn i vår DNS-over-HTTPS-guide.

Forvirring mellom app og domene

App-basert split-tunneling ruter etter prosessidentitet, men moderne apper oppretter tilkoblinger til mange domener. «Strømme-appen» din laster sannsynligvis annonser, telemetri, anbefalings-API-er og analysendepunkter fra dusinvis av ulike domener – noen av dem deles med apper du faktisk vil tunnele. Å ekskludere hele appen betyr å ekskludere alle disse tilkoblingene. Domenebasert split-tunneling har det motsatte problemet: én enkelt app kan laste det samme CDN-domenet for både strømmevideo (som du vil ha ubeskyttet) og for innhold du helst ikke vil avsløre.

IPv6-lekkasjer

Mange split-tunnel-implementeringer ble designet da IPv4 var den eneste rutingsproblematikken. Hvis nettverket ditt har IPv6-tilkobling og split-tunnel-reglene ikke eksplisitt inkluderer IPv6-ruter, kan pakker som burde tunneles gå ut over IPv6 utenfor tunnelen. Dette er en av de vanligste VPN-lekkasjene i 2026 og skyldes nesten alltid ufullstendig konfigurasjon av split-tunnel-regler. Test for det med en IPv6-lekkasjetest etter at du har aktivert split-tunneling.

Interaksjoner med nødstengsel (kill switch)

Et nødstengsel er designet for å blokkere all trafikk hvis VPN-en faller bort, slik at ingenting lekker ubeskyttet. Når split-tunneling er aktivert, blir logikken for nødstengsel vanskeligere – nødstengsel bør fortsatt tillate at split-tunnelede apper kommuniserer, men bare disse, og bare når VPN-en selv også er nede. Mange VPN-klienter har feil der nødstengsel enten ikke klarer å blokkere tunnelede apper når VPN-en faller bort, eller feilaktig blokkerer split-tunnelede apper som burde fortsette å fungere. Test kombinasjonen eksplisitt.

Sammenligning av split-tunneling-moduser

Hvordan split-tunneling fungerer på hvert operativsystem

iOS – begrenset og indirekte

iOS eksponerer ikke en ekte split-tunneling-API til tredjeparts VPN-apper. NetworkExtension-rammeverket lar en VPN konfigureres enten systemomfattende (all trafikk) eller per app (bare apper eksplisitt registrert av en MDM-profil). Ekte per-app-split-ruting krever Apples NEAppProxyProvider med en MDM-distribuert konfigurasjonsprofil – det vil si et scenario med administrert enhet. Forbruker-VPN-apper på iOS som reklamerer for «split-tunneling» implementerer typisk destinasjonsbaserte ekskluderinger (f.eks. ekskludering av spesifikke IP-områder fra tunnelen) eller bruker on-demand-regler-API-et til å betinget aktivere VPN basert på Wi-Fi SSID eller domenematch. App-basert split-tunneling for forbruker-iOS-brukere er ikke egentlig tilgjengelig.

Android – førsteklasses støtte

Androids VpnService-API støtter per-app-ruting innebygd. VPN-klienten kan kalle addAllowedApplication() eller addDisallowedApplication() for å spesifisere hvilke apper som går gjennom tunnelen. OS håndterer per-app-rutingen transparent – VPN-klienten trenger ikke gjøre merking på pakkenivå. Android støtter også systeminnstillingen «Always-on VPN» med alternativet «Block connections without VPN», som kombinerer nødstengselatferd med per-app-konfigurasjonen: tunnelede apper går gjennom, ikke-tunnelede apper går direkte, og hvis VPN-en faller bort, blokkeres de tunnelede appene.

macOS – implementeringen varierer

macOS støtter split-tunneling gjennom flere mekanismer: NetworkExtension-rammeverket (likt iOS, med mer fleksibilitet), pakkefiltre konfigurert via pf-regler, eller rutingstabellmanipulering av VPN-klienter som kjører med forhøyede rettigheter. App-basert split-tunneling på macOS er gjennomførbart, men krever at VPN-klienten spør kjernen om socket-til-prosess-mappinger. Destinasjonsbasert splitting er enkel og pålitelig.

Windows – vanligste plattform for split-tunneling

Windows VPN-klienter har brukt split-tunneling i over ti år. Windows Filtering Platform (WFP) gir API-et for pakkeinspeeksjon og rutingsbeslutning på kjernenivå som VPN-klienter kobler seg til. Per-app-split-tunneling på Windows er godt støttet og mye brukt. De fleste bedrifts-VPN-distribusjoner bruker Windows split-tunneling for å sikre at bedriftstrafikk går gjennom bedriftstunnelen mens generell internetttrafikk går direkte – delvis av ytelsesgrunner, delvis for å redusere belastningen på bedriftens VPN-konsentratorer.

Vanlige feil ved konfigurering av split-tunneling

Ved å se på hvordan folk faktisk feilkonfigurerer split-tunneling avdekkes noen tilbakevendende mønstre. Hvis du setter det opp, sjekk deg selv mot denne listen:

• Ikke teste for DNS-lekkasjer etter aktivering. Kjør en lekkasjetest (dnsleaktest.com eller tilsvarende) etter enhver konfigurasjonsendring. Hvis du ser internettleverandørens DNS-løser oppført for en app som burde være tunnelet, lekker omveien DNS.
• Glemme at nettlesere er spesielle. En nettleser som kjører en strømmende webapp ruter både strømmevideo og de andre fanene gjennom samme prosess. Å ekskludere nettleseren ekskluderer all nettlesingen din. Bruk en separat nettleserprofil eller en annen app for strømmetilfellet.
• Ikke håndtere IPv6. Deaktiver IPv6 helt hvis VPN-klienten din ikke håndterer det eksplisitt. Lekkasjeraten fra glemte IPv6-split-tunnel-regler er høy.
• Bruke domenebaserte regler for sikkerhetskritiske beslutninger. Domenebasert split-tunneling er greit for brukervennlighetstilpasninger. Det er ikke pålitelig nok til å håndheve «denne sensitive appen må alltid gå gjennom VPN» – til det bruker du app-baserte regler med appen eksplisitt tunnelet, helst i tillatelseslistemodus.
• Ikke gjennomgå reglene kvartalsvis. Apper legges til og fjernes; nye apper fra samme utgiver arver ingenting fra de gamle. Revidér split-tunnel-regelsettet ditt jevnlig.

Den ærlige dommen om split-tunneling

Split-tunneling er genuint nyttig for spesifikke problemer – strømmeapper som oppdager VPN-er, bankapper som flaggerer VPN-innlogginger, lokal nettverkstilgang – og det har en lang historie med legitim bruk i bedriftsmiljøer. For forbrukere er den ærlige innrammingen at det er et brukervennlighetsverktøy først og et personvernverktøy i andre rekke. Hver split-tunnel-regel svekker beskyttelsesmodellen på en spesifikk måte, og sikkerhetsavveiningen er bare verdt det når beskyttelsen uansett ikke ville ha hjulpet den trafikken (f.eks. en bankøkt som allerede er TLS-kryptert og går til én enkelt kjent destinasjon).

Hvis trusselmodellen din er «Jeg vil ha VPN på fiendtlige offentlige Wi-Fi-nettverk så den lokale nettverksoperatøren ikke kan observere trafikken min», er full tunnel riktig svar. Ikke aktiver split-tunneling bare fordi VPN-klienten tilbyr det – hvert unntak er et hull. Hvis trusselmodellen din er «Jeg vil ha de fleste ting beskyttet, men spesifikke apper trenger det ekte nettverket», er split-tunneling riktig verktøy, men konfigurer det nøye, test for DNS- og IPv6-lekkasjer etterpå, og gjennomgå reglene jevnlig. Den tekniske referansen i WireGuard-hurtigstartdokumentasjonen viser hvordan de underliggende rutingsbeslutningene fungerer på protokollnivå.

Casper's Cloak bruker en full-tunnel-arkitektur som standard fordi trusselmodellen vi beskytter mot – fiendtlige nettverk, overvåking fra internettleverandør, annonseteknologisporing – drar nytte av den enklere «tunnel alt»-modellen. Vi kombinerer det med sporerfiltrering på DNS-laget og AI-trusseldeteksjon for kjente ondsinnede destinasjoner, slik at den fulle tunnelen også gjør aktiv filtrering – ikke bare ruting. For strømme- og banktilfellene er det riktige trekket vanligvis å koble fra kortvarig fremfor å vedlikeholde et permanent sett med split-tunnel-ekskluderinger du vil glemme.