Wat is split tunneling — hoe per-app VPN-routering in de praktijk werkt

De korte versie: een standaard VPN stuurt 100% van het verkeer van je apparaat door de versleutelde tunnel. Split tunneling doorbreekt die regel bewust. Je kiest welke apps of bestemmingen de tunnel omzeilen en rechtstreeks via je normale verbinding gaan. Dat klinkt eenvoudig, en conceptueel is het dat ook — maar de praktische implementatie verschilt sterk per besturingssysteem, en de privacyafwegingen zijn gemakkelijk over het hoofd te zien. Een streaming-app die buiten de tunnel wordt gerouteerd, ziet nog steeds je echte IP-adres. Een bank-app die buiten de tunnel wordt gerouteerd, communiceert nog steeds met je bank via je thuisnetwerk — wat prima is, totdat diezelfde app ook een DNS-query doet die via het omleidingspad lekt en een ander domein blootgeeft dat je niet van plan was te onthullen.

Wat VPN-tunneling eigenlijk doet (de basis)

Voordat je begrijpt wat er wordt gesplitst, moet je goed weten wat de volledige tunnel doet. Een VPN-client op je apparaat maakt een virtuele netwerkinterface aan — op Linux heet die doorgaans tun0 of wg0, op macOS utun, en op iOS en Android beheert het besturingssysteem die via een per-app extensie-API. De routeringstabel van het besturingssysteem wordt vervolgens aangepast zodat de standaardroute — de regel die zegt: "stuur pakketten zonder andere overeenkomende route naar deze gateway" — naar die virtuele interface wijst in plaats van naar je fysieke wifi- of mobiele interface.

Vanaf dat moment wordt elk pakket dat je apparaat genereert versleuteld door de VPN-client, verpakt in een nieuw IP-header dat naar de VPN-server wijst, en via de fysieke interface verstuurd als één homogene stroom. De VPN-server ontsleutelt het pakket, stuurt het door naar de werkelijke bestemming op het publieke internet, ontvangt het antwoord, versleutelt het opnieuw en stuurt het terug. Je internetprovider ziet alleen de versleutelde stroom naar één enkel IP-adres. Bestemmingswebsites zien het IP-adres van de VPN-server, niet het jouwe.

Dat is de standaard. Split tunneling grijpt in op dit model door specifiekere routes toe te voegen aan de routeringstabel — regels die zeggen: "voor verkeer naar deze bestemming" of "voor verkeer van deze app: negeer de standaard tunnelroute en gebruik de fysieke interface rechtstreeks."

Wat split tunneling verandert

Conceptueel gezien introduceert split tunneling een splitsing in je netwerkstroom. Sommige pakketten gaan door de versleutelde tunnel; andere gaan via de kale interface. De beslissing wordt genomen door de VPN-client op basis van regels die jij configureert. Er zijn drie veelvoorkomende categorieën van splitsingsregels:

• Op basis van app — "Stuur al het verkeer van Netflix buiten de tunnel; tunnel al het andere." Geïmplementeerd door pakketten te taggen met de UID of PID van het oorspronkelijke proces en vervolgens routeringsbeslissingen per tag te nemen.
• Op basis van bestemming — "Stuur verkeer naar 10.0.0.0/8 buiten de tunnel zodat ik mijn NAS thuis kan bereiken; tunnel al het andere." Puur geïmplementeerd via routeringstabelentries — de eenvoudigste vorm.
• Op basis van URL of domein — "Stuur verkeer naar *.bank.com buiten de tunnel." Dit is fragiel omdat de routeringslaag van het besturingssysteem van nature geen domeinen kent; het vereist dat de VPN-client ofwel DNS onderschept en antwoorden herschrijft, ofwel een dynamische IP-acceptatielijst bijhoudt die DNS-resoluties volgt. Leveranciers implementeren dit inconsistent.

Hier is de architecturale weergave, vereenvoudigd:

Volledige tunnel (geen split):
  [App A] -> [App B] -> [App C]
        \        |        /
         [Virtuele VPN-interface]
                 |
         [Versleutelde tunnel]
                 |
         [VPN-server] -> internet

Split tunnel (op basis van app, App C uitgesloten):
  [App A] -> [App B]        [App C]
        \        /               \
   [Virtuele VPN-interface]   [Fysieke wifi]
              |                    |
       [Versleutelde tunnel]    [Gewoon internet]
              |                    |
        [VPN-server]         direct naar bestemming

De "split" is het vertrekpunt binnen je besturingssysteem — de keuze tussen de virtuele interface en de fysieke interface wordt gemaakt vóórdat versleuteling plaatsvindt, zodat een pakket dat de tunnel omzeilt nooit versleuteld is geweest. Er is geen ontsleutelingsstap; het verlaat je apparaat gewoon zoals het is.

Omgekeerd split tunneling — acceptatielijst vs. uitsluitingslijst

Split tunneling-configuraties bestaan in twee varianten die symmetrisch lijken maar bij falen heel anders gedragen:

• Uitsluitingslijstmodus (de gangbare standaard) — "Tunnel alles behalve de apps/bestemmingen op deze lijst." De standaard is beschermd; alleen specifieke uitzonderingen lekken. Als je vergeet een app aan de lijst toe te voegen, blijft die beschermd.
• Acceptatielijstmodus (ook wel omgekeerd split tunneling) — "Tunnel alleen de apps/bestemmingen op deze lijst; al het andere gaat rechtstreeks." De standaard is onbeschermen; alleen specifieke apps worden getunneld. Als je vergeet een app toe te voegen, lekt die.

Acceptatielijstmodus is de juiste keuze als je "alleen wilt dat mijn browser de VPN gebruikt, al het andere mag mijn normale verbinding gebruiken." Uitsluitingslijstmodus is de juiste keuze als je "de meeste dingen beschermd wilt hebben, maar een paar specifieke apps het echte netwerk nodig hebben." De meeste consumenten willen de uitsluitingslijstmodus. Operations- en DevOps-teams geven soms de voorkeur aan de acceptatielijstmodus omdat ze specifieke services via de tunnel willen blootstellen zonder de rest van het systeem te verstoren.

Het faalscenario voor de acceptatielijstmodus is ernstig: als je een nieuwe app toevoegt en vergeet die aan de acceptatielijst toe te voegen, lekt het verkeer van die app. Het faalscenario voor de uitsluitingslijstmodus is milder: vergeten apps blijven beschermd — je hebt alleen vervelende compatibiliteitsproblemen wanneer een streaming- of bank-app niet werkt omdat die het VPN-IP-adres ziet.

Wanneer split tunneling gebruiken — vijf concrete scenario's

Split tunneling heeft echte legitieme toepassingen. Dit zijn de situaties waarin het het juiste hulpmiddel is:

1. Streamingdiensten die VPN-eindpunten detecteren en blokkeren

Netflix, Disney+, Hulu en de meeste regionale omroepen onderhouden grote acceptatielijsten van bekende VPN-datacenter-IP's en weigeren te streamen wanneer ze er één detecteren. Je kunt de VPN uitschakelen (en alle bescherming verliezen) of de streaming-app via split tunneling laten lopen zodat die je echte IP ziet, terwijl alles andere beschermd blijft.

2. Bank- en financiële apps met op locatie gebaseerde fraudedetectie

Banken behandelen een plotselinge IP-wijziging naar een VPN-datacenter vaak als een fraudesignaal — ze activeren extra verificatie, houden transacties tegen, of vergrendelen het account kort. Door de bank-app buiten de tunnel te houden, blijft je echte-IP-relatie met de bank consistent. Dit is een gebruiksgemakfix, geen beveiligingsupgrade — de verbinding met de bank is al TLS-versleuteld, dus de VPN voegde toch al niet veel beveiliging toe aan die specifieke sessie.

3. Lokale netwerkbronnen (NAS, printer, slimme thuisapparaten)

Wanneer de VPN al het verkeer afvangt, kan je apparaat de printer op 192.168.1.50 niet meer bereiken omdat dat IP-adres niet bereikbaar is via de VPN-tunnel. Bestemmingsgebaseerd split tunneling (het uitsluiten van 192.168.0.0/16 en 10.0.0.0/8) herstelt lokale toegang zonder de VPN voor het publieke internet uit te schakelen. Veel VPN-clients doen dit standaard automatisch; sommige niet.

4. Latentiegevoelige toepassingen

Competitief online gamen, live videovergaderen en spraakgesprekken leiden onder extra latentie die ontstaat door routering via een VPN-server in een verafgelegen regio. Door die specifieke apps te splitsen kan de latentie worden hersteld, terwijl alles andere versleuteld blijft. De afweging: die apps zijn nu identificeerbaar voor je internetprovider en zichtbaar voor netwerkobservers.

5. Werk-VPN's naast persoonlijke VPN's

Als je werkgever een zakelijke VPN vereist voor toegang tot interne bronnen, en je persoonlijk verkeer via een andere (privacygerichte) VPN wilt laten lopen, laat split tunneling op de zakelijke VPN — waarbij alleen de zakelijke IP-bereiken erdoorheen worden gestuurd — de rest van je verkeer beschikbaar voor de persoonlijke VPN. Dit is een geavanceerde configuratie, maar een nette manier om werk- en persoonlijk verkeer gescheiden te houden.

Wanneer split tunneling NIET te gebruiken — de privacyvalkuilen

Split tunneling maakt je netwerkgedrag complexer, en complex netwerkgedrag lekt op niet voor de hand liggende manieren. De meest voorkomende faalscenario's:

DNS-lekken via het omleidingspad

Zelfs wanneer het TCP-verkeer van een app buiten de tunnel wordt gerouteerd, kunnen de DNS-query's ervan nog steeds zijn geconfigureerd om de DNS-resolver van de VPN te gebruiken — of, erger nog, terugvallen op de DNS-resolver van de internetprovider als de VPN-client de systeem-DNS niet zorgvuldig beheert. Het gevolg: een app die onzichtbaar zou moeten zijn voor je internetprovider wordt deels zichtbaar. De internetprovider ziet de DNS-query voor banking.example.com ook al ging de daaropvolgende TCP-verbinding via een ander pad. We hebben een uitgebreide uitleg over hoe DNS-versleuteling past in onze DNS-over-HTTPS-gids.

Verwarring tussen app en domein

Op apps gebaseerd split tunneling routeert op basis van procesidentiteit, maar moderne apps maken verbinding met veel domeinen. Jouw "streaming-app" laadt waarschijnlijk advertenties, telemetrie, aanbevelings-API's en analyse-eindpunten van tientallen verschillende domeinen — waarvan sommige worden gedeeld met apps die je wel getunneld wilt hebben. De hele app uitsluiten betekent al die verbindingen uitsluiten. Domeingebaseerd split tunneling heeft het tegenovergestelde probleem: één app kan hetzelfde CDN-domein laden voor zowel de streamingvideo (die je onbeschermen wilt) als voor content die je liever niet onthult.

IPv6-lekken

Veel split-tunnel-implementaties zijn ontworpen toen IPv4 de enige routeringszorg was. Als je netwerk IPv6-connectiviteit heeft en de split-tunnelregels geen IPv6-routes expliciet bevatten, kunnen pakketten die getunneld zouden moeten worden via IPv6 buiten de tunnel vertrekken. Dit is een van de meest voorkomende VPN-lekken in 2026 en wordt bijna altijd veroorzaakt door onvolledige configuratie van split-tunnelregels. Test dit met een IPv6-lektest na het inschakelen van split tunneling.

Interacties met de kill switch

Een kill switch is ontworpen om al het verkeer te blokkeren als de VPN wegvalt, zodat er niets onbeschermd lekt. Met split tunneling ingeschakeld wordt de kill switch-logica moeilijker — de kill switch moet split-getunnelde apps nog steeds laten communiceren, maar alleen die, en alleen wanneer de VPN zelf ook weggevallen is. Veel VPN-clients hebben fouten waarbij de kill switch ofwel getunnelde apps niet blokkeert wanneer de VPN wegvalt, ofwel split-getunnelde apps onterecht blokkeert die zouden moeten blijven werken. Test de combinatie expliciet.

Vergelijking van split tunneling-modi

Hoe split tunneling werkt per besturingssysteem

iOS — beperkt en indirect

iOS biedt geen echte split-tunneling-API aan externe VPN-apps. Het NetworkExtension-framework staat toe dat een VPN wordt geconfigureerd als systeembrede (al het verkeer) of per-app (alleen apps die expliciet zijn geregistreerd via een MDM-profiel). Echte per-app split-routering vereist Apple's NEAppProxyProvider met een MDM-gedistribueerd configuratieprofiel — dat wil zeggen een scenario met beheerde apparaten. Consumer-VPN-apps op iOS die "split tunneling" adverteren, implementeren doorgaans bestemmingsgebaseerde uitsluitingen (bijv. het uitsluiten van specifieke IP-bereiken van de tunnel) of gebruiken de on-demand regels-API om de VPN conditioneel te activeren op basis van wifi-SSID of domeinovereenkomst. Op apps gebaseerd split tunneling voor iOS-consumenten is in de praktijk niet beschikbaar.

Android — eersteklas ondersteuning

De VpnService-API van Android ondersteunt native per-app routering. De VPN-client kan addAllowedApplication() of addDisallowedApplication() aanroepen om te specificeren welke apps via de tunnel gaan. Het besturingssysteem verwerkt de per-app routering transparant — de VPN-client hoeft geen pakkettagging op niveauniveau te doen. Android ondersteunt ook de systeeminstelling "Altijd actieve VPN" met een optie "Verbindingen zonder VPN blokkeren", wat kill-switch-gedrag combineert met de per-app configuratie: getunnelde apps gaan erdoorheen, niet-getunnelde apps gaan rechtstreeks, en als de VPN wegvalt worden de getunnelde apps geblokkeerd.

macOS — implementatie varieert

macOS ondersteunt split tunneling via verschillende mechanismen: het NetworkExtension-framework (vergelijkbaar met iOS, maar met meer flexibiliteit), pakketfilters geconfigureerd via pf-regels, of routeringstabelmanipulatie door VPN-clients die draaien met verhoogde bevoegdheden. Op apps gebaseerd split tunneling op macOS is werkbaar maar vereist dat de VPN-client de kernel bevraagt voor socket-naar-proces-koppelingen. Bestemmingsgebaseerd splitsen is eenvoudig en betrouwbaar.

Windows — meest gangbaar platform voor split tunneling

Windows VPN-clients gebruiken split tunneling al meer dan tien jaar. Het Windows Filtering Platform (WFP) biedt de pakketinspectie op kernelniveau en de routeringsbeslissings-API waarop VPN-clients inhaken. Per-app split tunneling op Windows wordt goed ondersteund en breed ingezet. De meeste enterprise-VPN-implementaties gebruiken Windows split tunneling om ervoor te zorgen dat zakelijk verkeer via de zakelijke tunnel gaat, terwijl algemeen internetverkeer rechtstreeks gaat — deels voor prestaties, deels om de belasting op de zakelijke VPN-concentratoren te verminderen.

Veelgemaakte fouten bij het configureren van split tunneling

Als je bekijkt hoe mensen split tunneling in de praktijk verkeerd configureren, komen er een paar terugkerende patronen naar voren. Als je het instelt, controleer jezelf aan de hand van deze lijst:

• Niet testen op DNS-lekken na het inschakelen ervan. Voer een lektest uit (dnsleaktest.com of vergelijkbaar) na elke configuratiewijziging. Als je de DNS-resolver van je internetprovider ziet voor een app die getunneld zou moeten zijn, lekt het omleidingspad DNS.
• Vergeten dat browsers speciaal zijn. Een browser die een streaming-webapp uitvoert, routeert zowel de streamingvideo als je andere tabbladen via hetzelfde proces. De browser uitsluiten sluit al je browsegedrag uit. Gebruik een apart browserprofiel of een andere app voor het streamingscenario.
• IPv6 niet afhandelen. Schakel IPv6 volledig uit als je VPN-client het niet expliciet afhandelt. Het lekpercentage van vergeten IPv6 split-tunnelregels is hoog.
• Domeingebaseerde regels gebruiken voor beveiligingskritische beslissingen. Domeingebaseerd split tunneling is prima voor gebruiksgemakafstemmingen. Het is niet betrouwbaar genoeg om af te dwingen dat "deze gevoelige app altijd via de VPN moet gaan" — gebruik daarvoor op apps gebaseerde regels waarbij de app expliciet getunneld is, bij voorkeur in de acceptatielijstmodus.
• De regels niet elk kwartaal herzien. Apps worden toegevoegd en verwijderd; nieuwe apps van dezelfde uitgever erven niets van de oude. Controleer je split-tunnel-regelset periodiek.

Het eerlijke oordeel over split tunneling

Split tunneling is oprecht nuttig voor specifieke problemen — streaming-apps die VPN's detecteren, bank-apps die VPN-logins markeren, lokale netwerktoegang — en heeft een lange geschiedenis van legitiem gebruik in zakelijke omgevingen. Voor consumenten is de eerlijke omschrijving dat het in de eerste plaats een gebruiksgemakhulpmiddel is en pas in de tweede plaats een privacyhulpmiddel. Elke split-tunnelregel verzwakt het beschermingsmodel op een specifieke manier, en de beveiligingsafweging is alleen de moeite waard wanneer de bescherming dat specifieke verkeer toch niet had geholpen (bijv. een banksessie die al TLS-versleuteld is en naar een enkele bekende bestemming gaat).

Als je dreigingsmodel is "ik wil een VPN op vijandige openbare wifi-netwerken zodat de lokale netwerkbeheerder mijn verkeer niet kan observeren", is een volledige tunnel het juiste antwoord. Schakel split tunneling niet in alleen omdat de VPN-client het aanbiedt — elke uitsluiting is een gat. Als je dreigingsmodel is "ik wil de meeste verkeers beschermd hebben maar specifieke apps hebben het echte netwerk nodig", is split tunneling het juiste hulpmiddel, maar configureer het zorgvuldig, test daarna op DNS- en IPv6-lekken, en herzie de regels periodiek. De technische referentie bij de WireGuard-quickstartdocumentatie laat zien hoe de onderliggende routeringsbeslissingen werken op protocolniveau.

Casper's Cloak gebruikt standaard een volledige-tunnel-architectuur omdat het dreigingsmodel dat we beschermen — vijandige netwerken, ISP-surveillance, advertentietechnologietracking — profiteert van het eenvoudigere "tunnel alles"-model. Dat combineren we met trackerfiltering op de DNS-laag en AI-dreigingsdetectie voor bekende kwaadaardige bestemmingen, zodat de volledige tunnel ook actief filtert — niet alleen routeert. Voor de streaming- en bankrandgevallen is de juiste aanpak meestal om even te verbreken in plaats van een permanente set split-tunneluitsluitingen te handhaven die je zult vergeten.