Hvad er split tunneling, og hvorfor giver det problemer?

Split tunneling er en VPN-konfiguration, hvor noget trafik sendes gennem VPN-tunnelen, mens resten sendes direkte til internettet uden VPN. Det bruges ofte for at undgå unødvendig VPN-belastning og samtidig bevare lokal adgang til bestemte tjenester.

Problemer opstår, fordi den samme enhed samtidigt kan bruge to “veje” for netværk: én vej via VPN og én udenom. Det betyder, at regler for routing, DNS (navneopslag) og firewallskal følge med. Når én del af kæden ikke matcher den øvrige, kan du få symptomer som manglende adgang til en hjemmeside, at login fejler, eller at nogle tjenester virker “tilfældige” afhængigt af hvilken destination der er involveret.

Et simpelt model: Hvem bestemmer hvor trafikken går?

Tænk på split tunneling som tre beslutninger, der skal fungere sammen:

  1. Hvilke destinationer (IP-adresser/domæner eller netværk) skal bruge VPN?
  2. Hvilket DNS skal bruges, når et domæne slås op?
  3. Hvilke applikations- og firewallregler gælder for henholdsvis VPN-grænsefladen og den normale netværksgrænseflade?

Hvis du fx har sat regler, så “kun bestemte websteder” går via VPN, men DNS-opslag stadig peger på svar, der forventer VPN-adgang, kan resultatet blive, at nogle forbindelser forsøger at ramme forkerte veje. Omvendt kan du få, at trafik der skal udenom, pludselig bliver sendt via VPN, fordi en regel er for bred.

Typiske VPN split tunneling-fejl (og hvad du bør kigge efter)

1) DNS-relaterede problemer og “halvt” login

Et klassisk mønster er, at navneopslag virker, men selve forbindelsen fejler, eller at login bliver ved med at spørge om godkendelse. Det kan skyldes forskel mellem:

  • DNS der bruges til at løse domæner,
  • DNS der håndterer interne domæner (fx på arbejdsnet),
  • og routing-regler for den trafik, der kommer efter DNS-opslaget.

Kontrolpunkt: Når problemet opstår, så sammenlign om fejlen handler om navneopslag (domænet kan ikke slås op) eller om netværksforbindelsen (domænet slås op, men forbindelsen timeout’er). Hvis du skifter mellem “uden VPN” og “med VPN”, kan du ofte se mønstret.

2) Uventede forbindelser: “det går ikke den vej, jeg troede”

Med split tunneling kan det se ud som om en app går via VPN, selv om den ikke burde, eller at den går udenom, selv om den forventer adgang til ressourcer bag VPN.

Kontrolpunkt: Find ud af om destinationen (domænet) faktisk rammer forskellige IP’er, der falder i forskellige regelkategorier. Nogle services bruger flere endpoints, og en ændring i IP kan få trafikken til at ramme en anden routing-/policy-regel.

3) App-specifik adfærd: nogle programmer virker, andre ikke

Nogle programmer bruger egne netværksbiblioteker, egne proxy- eller DNS-indstillinger eller implementerer netværksforbindelser på en måde, der gør at de følger andre systemindstillinger end forventet.

Kontrolpunkt: Test en simpel “single-purpose” URL eller tjeneste i samme app, og sammenlign med en anden app (fx browser vs. desktop-app). Hvis kun én app rammes, er problemet ofte appens netværksopsætning snarere end selve VPN-linket.

4) Firewall eller “policy-kollision”

Når der er to netværksveje (VPN og normal), kan firewallregler eller sikkerhedssoftware blokere den ene vej korrekt, mens den anden vej ikke er passende tilladt. Det kan give tidsudløb eller “connection refused”.

Kontrolpunkt: Undersøg om der er forskel i adfærd for:

  • trafik fra VPN-grænsefladen til de samme destinationer,
  • trafik fra den normale grænseflade.

5) Lækage eller blandet trafik (symptom-baseret)

Selv hvis du ikke har “bevis” for lækage, kan der være tegn på blanding: fx at en tjeneste tilsyneladende tilgår noget uden VPN, selv om du forventer den skal være omfattet. I praksis kan du ikke altid bekræfte alt med absolut sikkerhed på almindelige klienter, men du kan sammenligne svar og adfærd.

Kontrolpunkt: Vælg en testdestination, hvor du forventer en bestemt vej, og sammenlign responsmønsteret med en “alt via VPN” variant (hvis muligt). Hvis adfærden ændrer sig drastisk, peger det ofte på en policy-/DNS-/routing-inkonsistens.

Forskelle og grænser: hvad kan split tunneling ændre?

Split tunneling er ikke kun et hastighedsvalg; det ændrer også sikkerheds- og adgangsforudsætninger. Overvej disse grænser:

  • Interne ressourcer vs. eksterne ressourcer: Hvis en destination kræver adgang via VPN (fx et internt system), skal den typisk med i VPN-delen. Ellers vil forbindelsen mislykkes, selv om DNS slår korrekt op.
  • Navneopslag som “nøglen”: Domæner kan kræve, at navneopslag følger den samme routing-logik som selve trafikken. Uoverensstemmelser viser sig ofte som “det virker kun nogle gange”.
  • Dynamiske destinationer: Hvis dine split-tunnel-regler er baseret på lister, der ikke matcher virkelige endpoints (eller hvis services skifter IP’er), kan du få uforudsigelig adfærd.
  • Klientvariation: Forskellige VPN-klienter håndterer split tunneling forskelligt. Derfor bør du ikke kun fokusere på “hvilke domæner”, men også på DNS-/proxy-/firewallrelaterede indstillinger i samme klient.

Praktisk fejlfinding: en rækkefølge der typisk isolerer årsagen

Brug en metode, hvor du ændrer én faktor ad gangen, og dokumenterer hvad der sker:

  1. Bekræft symptomet: Virker problemet kun for bestemte domæner/tjenester, eller gælder det generelt?
  2. Test med samme destination: Brug den samme URL/tjeneste i to situationer (split tunneling slået til vs. slået fra), hvis det er muligt. Hvis alt fejler, er det mindre sandsynligt at være en enkelt policy-regel.
  3. Afklar DNS vs. forbindelsesproblem: Er fejlen tidligt (navneopslag) eller undervejs (timeout/afvisning)?
  4. Tjek policy-match: Hvis du har regler for bestemte destinationer, så er det ofte nok at spørge: matcher destinationen faktisk de forventede mønstre (domæne/IP/net)?
  5. Udeluk app-/proxy-faktorer: Prøv en anden app, og se om problemet følger appen. Hvis ja, kig på appens proxy-/DNS-indstillinger.
  6. Gå efter firewall/logforskelle: Hvis du har mulighed for det, så se efter mønstre i logfiler, der viser om forbindelsen rammer den rigtige vej.

Hvis du kan beskrive problemet som en af følgende kategorier, bliver det lettere at vælge den rigtige retning:

  • “Kun DNS-fejl”
  • “Kun adgang til enkelte tjenester via VPN”
  • “Kun én app virker/ikke virker”
  • “Adfærd skifter med destinationen”

Undersøgelsescheck: Hvad kan ændre udfaldet, uden at du ændrer split-tunnel-reglerne?

Nogle ændringer kan få split tunneling til at opføre sig anderledes, uden at du bevidst ændrer konfigurationen:

  • Ændringer i IP-endpoints for en tjeneste (samme domæne, nye IP’er)
  • Ændringer i DNS-opsætning i klienten eller i systemet
  • Opdateringer eller sikkerhedssoftware, der påvirker firewallregler
  • Skift i netværkstype (fx Wi‑Fi vs. kablet) eller skift af gateway

Af den grund er det ofte en god idé at gentage testen på samme netværk og tidlig i fejlfindingen, før du konkluderer at split tunneling-reglerne “er forkerte”.