Wat is VPN-tracering? Hoe voorkom je dat je wordt gevolgd?

Inleiding: waarom een VPN geen “vrijbrief” is

De gangbare aanname is: installeer NordVPN / Surfshark / een zelfgehoste WireGuard, verander je exit-IP, en “niemand weet meer wie je bent”. Dat is een denkwijze uit de jaren 2010. Trackingtechnologie is de “IP-laag” allang voorbij:

• Detecteren dat “je een VPN gebruikt” is een basisvaardigheid van fraudedetectie (controleren of het IP-adres bij het ASN van een VPN-provider hoort — vrijwel alle datacenterbereiken van commerciële VPN's zijn al gemarkeerd)
• Om “je eerdere echte IP-adres” te achterhalen is alleen de IP-laag nodig — WebRTC- / IPv6- / DNS-lekken / omzeiling van de CDN-origin — en na één misstap heb je voorgoed een cookie-label
• Achterhalen “welke persoon je precies bent” leunt helemaal niet op het IP-adres — maar op browserfingerprinting, gedragspatronen en correlatie tussen accounts
• In extreme gevallen kan internationale rechtshulp (dagvaardingen / grensoverschrijdend onderzoek) VPN-providers dwingen logs af te staan

Met andere woorden: wat je volgt is niet één kwetsbaarheid — het is de doorsnede van N dimensies — jij moet je op elke dimensie verdedigen, terwijl de tracker maar op één ervan hoeft te slagen. Daarom is “volledige anonimiteit” technisch gezien bijna onmogelijk, maar is “de correlatie flink verminderen” wel haalbaar — dit artikel laat zien hoe.

① Lekken op de IP-laag — je echte IP-adres ligt direct op straat

Het meest klassieke en meest voorkomende geval. Een VPN neemt alleen het HTTP- / TCP-verkeer van de browser over, maar de volgende kanalen kunnen de VPN volledig omzeilen en het publieke IP-adres van je thuisaansluiting rechtstreeks aan de andere kant doorgeven:

1.1 WebRTC-lekken

De ingebouwde WebRTC van de browser (bedoeld voor videogesprekken) gebruikt actief het STUN-protocol om het publieke IP-adres te achterhalen dat hij ziet, en JavaScript kan die waarde direct uitlezen. HTTP- / SOCKS-proxy's onderscheppen alleen TCP, terwijl STUN over UDP loopt en via de netwerkadapter thuis volledig om de proxy heen gaat, waardoor je echte IP-adres zichtbaar wordt.

Verdediging: gebruik een VPN in TUN-modus (Mihomo / Clash Premium / WireGuard TUN / Tailscale), die al het TCP- en UDP-verkeer op de virtuele netwerkadapter overneemt. Gebruik je alleen een proxy in de browser, beperk WebRTC dan met een beleid in plaats van het te verwijderen: Chrome / Edge-bedrijfsbeleid WebRtcIPHandling = disable_non_proxied_udp; Brave: schakel “Disable Non-Proxied UDP” in; Firefox: about:config → media.peerconnection.ice.proxy_only_if_behind_proxy = true.

Zelf testen: gebruik onze lektest op /leak om te controleren of het publieke IP-adres dat WebRTC-STUN teruggeeft, overeenkomt met je HTTP-exit.

1.2 Lekken via IPv6-dual-stack

Je VPN proxyt alleen IPv4, maar je thuisbreedband heeft ook IPv6 — de browser gaat bij voorkeur via IPv6 naar buiten en omzeilt de VPN volledig. Dit is een extreem veelvoorkomende kwetsbaarheid bij thuisbreedbandgebruikers van China Telecom.

Verdediging: gebruik een VPN die zowel IPv4 als IPv6 proxyt, of schakel IPv6 uit op systeem- / browserniveau. Op Windows pas je het register aan; op macOS gebruik je networksetup.

1.3 DNS-lekken (apart behandeld, zie ② DNS-laag)

1.4 Omzeiling via de CDN-origin

Gebruikt een site een CDN zoals Cloudflare, dan bereik je eigenlijk het IP-adres van een CDN-edge-node — maar als een aanvaller het echte origin-IP van de site achterhaalt, kan hij de CDN omzeilen en de server rechtstreeks benaderen. Andersom geldt dit ook voor trackers: staat de CDN-node die je bereikt in China, maar wordt een statisch bestand in dezelfde sessie rechtstreeks van de origin opgehaald (niet gedekt door de CDN), dan belandt je echte IP-adres in de toegangslogs van de originserver.

Verdediging: dit randgeval hangt vooral af van een strikte configuratie van de doelsite zelf — als gebruiker kun je er weinig aan doen.

② Lekken op de DNS-laag — welke domeinen je opvraagt, verraadt wie je bent

Je IP-verkeer gaat via de VPN, maar DNS-query's kunnen nog steeds via je lokale provider lopen. Dat kan op twee manieren lekken:

2.1 Land van de resolver komt niet overeen

Je VPN-exit staat in Nederland, maar als je systeem DNS-query's doet, gebruikt de stub-resolver de DNS die je thuisbreedbandprovider (China Telecom) heeft ingesteld. Wanneer de gezaghebbende nameserver de query ontvangt, ziet hij een bron-IP van China Telecom — en zo kennen de beheerders achter elk domein dat je bezoekt je echte locatie.

2.2 Subnetlekken via ECS

Publieke recursieve resolvers (8.8.8.8 van Google heeft EDNS Client Subnet standaard aan) sturen je echte /24-subnet door naar de gezaghebbende doelserver voor “locatiegebaseerde CDN-routering”. Maar op dat moment is je subnet bekend bij de externe autoriteit — preciezer dan het exit-IP van de resolver, tot op het subnet van je eigen buurt.

Verdediging:

• Dwing je VPN-client een eigen DNS te gebruiken — gebruik de DNS van de VPN-provider zelf (NordVPN / Mullvad / ProtonVPN bieden die allemaal)
• Laat DNS-query's niet buiten de tunnel lekken — dan ziet de resolver je echte IP-adres, dat niet overeenkomt met je webverkeer en je meteen verraadt. Let op: 1.1.1.1 / 8.8.8.8 zijn anycast; zolang de query door de tunnel gaat, komt hij uit bij een instantie vlak bij je VPN-exit en verraadt hij niets. Het echte probleem is dat het systeem de tunnel omzeilt en ze rechtstreeks benadert
• Kies je toch een publieke recursieve resolver, zorg dan op zijn minst dat die in hetzelfde land staat als je VPN-exit
• Gebruik DoH (DNS-over-HTTPS) om DNS-query's verplicht te versleutelen en man-in-the-middle-inspectie door je provider te voorkomen

Zelf testen: onze DNS-lektest op /leak draait een eigen gezaghebbende nameserver en routeert de query's van je browser echt naar onze server, zodat je het resolver-IP en het ECS-subnet ziet. Hoe het precies werkt, lees je in de complete gids over publieke DNS-resolvers.

③ TLS-fingerprinting (ja3 / ja4) — wie is je client?

Tijdens de HTTPS-handshake stuurt de client een ClientHello naar de server: een pakket met de TLS-versies, ciphersuites, extensies, elliptische curves en meer die hij ondersteunt. De precieze volgorde en inhoud van deze velden verschillen per client (Chrome 124 vs. Firefox 123 vs. curl vs. Python requests), en de fingerprint die daaruit ontstaat, staat in de branche bekend als ja3 / ja4.

Sites kunnen de ja3- / ja4-fingerprint van elke bezoeker vastleggen en vergelijken met de User-Agent — beweert je UA Chrome 124 te zijn, maar komt je ja3-fingerprint overeen met Python requests, dan is het bot- of scriptverkeer. Dit is ook een van de belangrijkste signalen voor anti-botdiensten zoals Cloudflare en Akamai.

Verdediging:

• Gebruik een echte, gangbare browser (Chrome / Firefox / Edge) — draai Selenium / Puppeteer niet kaal, hun ja3-fingerprints zijn extreem herkenbaar
• Is automatisering nodig, gebruik dan undetected-chromedriver / Playwright + curl-impersonate
• Installeer geen “anti-fingerprint”-browserextensies — daardoor wordt je ja3 juist opvallender dan die van een normale Chrome, en markeer je jezelf in feite als iemand die anti-trackingtools gebruikt

④ HTTP- / browserfingerprinting — canvas / WebGL / lettertypen / tijdzone

Fingerprints op de applicatielaag zijn rijker en moeilijker te weren:

Belangrijke valkuil: als je tijdzone / taal / lettertypen niet passen bij het land van je VPN-exit, is dat een extreem sterk signaal dat je “een VPN gebruikt”. Je VPN springt naar de VS, maar de tijdzone van de browser is nog steeds Asia/Shanghai en de taal zh-CN — dat valt meteen op.

Verdediging:

• “Zie er gewoon uit” — installeer geen anti-fingerprintextensies in je browser, want dat is op zich al afwijkend. De gewone Chrome-fingerprint van een normale gebruiker is de beste vermomming.
• Scheid toepassingen: gebruik je hoofdbrowser voor je echte identiteit, en een apart browserprofiel / VM / Tails / Whonix voor privacygevoelige activiteiten
• Houd het land van je VPN-exit, de tijdzone van je systeem en de taal van je browser allemaal consistent — laat op zijn minst niet het veelzeggende signaal lekken “ik ben een Chinese gebruiker via een Amerikaanse VPN”
• Tor Browser is speciaal hiervoor ontworpen — elke gebruiker ziet er identiek uit, ten koste van de prestaties

Zelf testen: gebruik onze browserfingerprinttest op /fingerprint om te zien hoe uniek je eigen 14 fingerprintdimensies zijn.

⑤ Fingerprinting op de TCP/IP-laag — initial window / TTL / MTU

Nog voordat de applicatielaag in beeld komt, bestaan er al fingerprints op de netwerklaag. De TCP/IP-stack van elk besturingssysteem is net iets anders geïmplementeerd:

• Initiële TTL: Windows gebruikt standaard 128, Linux 64, macOS 64, iOS 64
• TCP Initial Window Size: Windows 64 KB, Linux 14600, macOS 65535
• Volgorde van TCP-opties: verschillende besturingssystemen sturen de opties MSS / SACK / Timestamp in een andere volgorde
• MTU: gewone thuisbreedband 1500, PPPoE 1492, VPN-tunnels doorgaans 1380-1450

De tool p0f (passieve OS-fingerprinting) maakt precies van deze velden gebruik en bepaalt het besturingssysteem van de peer zonder ook maar één probe-pakket te sturen. Sites kunnen deze informatie verzamelen en vergelijken met de UA die je opgeeft — zegt je UA Mac Safari, maar is de TTL 128 en past het initial window bij Windows, dan draai je eigenlijk Windows met een vervalste Mac-UA.

Ook de MTU kan laten uitlekken dat “je een VPN gebruikt” — omdat VPN-tunnels doorgaans een MTU onder 1500 hebben, wijkt het verkeer merkbaar af van gewone breedband.

Verdediging:

• Gebruik een VPN in TUN-modus: de eigen stack van de VPN-server neemt het over, dus de TCP/IP-fingerprint die sites zien, is die van de VPN-server en niet die van je client
• OpenVPN / WireGuard gebruiken standaard de TUN-modus; HTTP/SOCKS-proxy's niet — dat is het belangrijkste verschil
• Forceer de MTU van de tunnel niet naar 1500 om “minder op een VPN te lijken” — de tunnelinkapseling kost zelf al tientallen bytes, en te hoog instellen leidt tot fragmentatie of een PMTUD-black hole (grote pakketten blijven hangen, pagina's laden maar half). Houd de standaardwaarde van je client aan (WireGuard 1420, OpenVPN automatisch)

⑥ Gedragsanalyse — timing van verkeer + invoergewoonten

Dit is de moeilijkst te verdedigen dimensie, omdat ze helemaal niet afhangt van een technische fingerprint, maar volledig op machine learning steunt:

• Verdeling van toegangstijden: zijn je dagelijkse online-uren over meerdere accounts gelijk, dan is het dezelfde persoon
• Muisbewegingen / scrollsnelheid / toetsaanslagritme: uniek per persoon, en verzameld door banken / antifraudesystemen
• Sessieduur / navigatiepatronen: je surfgedrag is uniek
• Kenmerken van tekstinvoer: je foutpercentage bij het typen, je woordkeuze en je grammatica

Verdediging:

• Scheid de gebruikstijden van je accounts strikt — log niet tegelijk in op “account A + account B”; laat er enkele uren tussen
• Heb je echt anonimiteit nodig, wissel dan van apparaat (van laptop naar telefoon / tablet)
• Volledig verdedigen is onmogelijk, maar je kunt correlatie wel flink lastiger maken

⑦ Logs van VPN-providers + jurisdictie

Dit is bij een VPN de erfzonde. Je vertrouwt erop dat de VPN-provider geen logs bewaart, maar in werkelijkheid:

• Commerciële VPN-providers kunnen worden overgenomen (Avast werd overgenomen door NortonLifeLock → het privacybeleid veranderde)
• Een provider kan stiekem logs verzamelen (in 2017 gaf PureVPN gebruikerslogs aan de FBI, terwijl het eerder beweerde “no-log” te zijn)
• Gerechtelijke dagvaardingen kunnen medewerking afdwingen — de VS / het VK / Canada / Australië / Nieuw-Zeeland (Five Eyes) werken allemaal mee aan grensoverschrijdend onderzoek
• Nine Eyes = Five Eyes + Denemarken / Frankrijk / Nederland / Noorwegen
• Fourteen Eyes = Nine Eyes + Duitsland / België / Italië / Spanje / Zweden

Selectiecriteria:

Een zelfgehoste VPN geeft je meer controle — maar VPS-providers (Vultr / Hetzner / DigitalOcean) houden hun eigen logs bij en werken mogelijk ook mee aan onderzoeken. Echte anonimiteit vereist een VPS kopen met contant geld / cryptovaluta plus registratie onder een valse identiteit, en dat is een flinke technische klus.

⑧ Correlatie tussen accounts — meerdere accounts met dezelfde cookies / fingerprints

Na het inloggen op account A slaat de browser cookies / localStorage / cache op. Wissel je in dezelfde browser naar account B, dan ziet de site meteen dat je dezelfde persoon bent.

• Zelfde fingerprint + binnen korte tijd inloggen op meerdere accounts = correlatie tussen accounts
• Cross-site tracking via cookies (al beginnen moderne browsers dit te beperken)
• Trackingscripts van derden (Google Analytics / Facebook Pixel) die activiteit over sites heen koppelen

Verdediging:

• De Firefox-extensie Multi-Account Containers: elk account krijgt eigen, gescheiden cookies / opslag
• Meerdere profielen in Chrome (avatar rechtsboven → profiel toevoegen)
• Extreme maatregel: draai verschillende accounts in aparte virtuele machines, waarbij elke VM een andere VPN-exit gebruikt

Overzichtstabel van verdedigingsstrategieën

Praktisch advies: hoe anoniem moet je eigenlijk zijn?

Voordat je bepaalt hoe ver je verdediging moet gaan, zoek je eerst uit wie je eigenlijk volgt:

• Adverteerders + databrokers (lage intensiteit): uBlock Origin + cookies van derden weigeren + een gewone VPN volstaat voor het overgrote deel van de dagelijkse situaties
• Antifraudesystemen (gemiddelde intensiteit): het bovenstaande + consistente VPN-DNS + passende tijdzone/taal + gescheiden browserprofielen
• Zakelijke concurrenten / webscrapers (gemiddelde tot hoge intensiteit): het bovenstaande + TUN-modus + een echte browser (geen Selenium-sporen) + achtergebleven cookies wissen
• Overheid / grensoverschrijdend onderzoek (extreme intensiteit): alles hierboven is slechts de basis. Je hebt Tor / Whonix / Tails / een contant betaalde VPS + XMR + volledig gescheiden apparaten nodig

De meeste mensen hebben genoeg aan niveau 1-2; niveau 3 en hoger is terrein voor specialisten. Belast je dagelijkse gebruik niet met anonimiteit die je eigenlijk niet nodig hebt.