WebRTC-lektest: is je echte IP zichtbaar ondanks je VPN?

Testresultaat

Deze test gebruikt een publieke STUN-server (die van Google, gratis en zonder sleutel — het is het WebRTC-protocol zelf dat dit vereist om een publiek adres te ontdekken, er wordt geen enkele externe library geladen). Geen enkele informatie die deze test verzamelt, wordt naar onze server gestuurd: de vergelijking gebeurt volledig in je browser.

Het resultaat kan een status « hier niet detecteerbaar » tonen in plaats van een duidelijk verdict: dat is bewust zo. Safari en Brave in strikte bescherming blokkeren soms stilzwijgend de WebRTC-verzameling, zonder ze ooit af te ronden — in plaats van in dat precieze geval een vals geruststellend « geen lek » te tonen, maakt de test expliciet onderscheid tussen « de verzameling is afgerond zonder iets te vinden » en « de verzameling is nooit voltooid », twee heel verschillende situaties.

Deze test draait volledig lokaal — nuttig als je VRT MAX probeert te ontgrendelen vanuit het buitenland en de detectie blijft aanhouden ondanks de VPN. Zie onze gids VRT MAX vanuit het buitenland voor de overige mogelijke oorzaken en de volledige methode.

Wat is WebRTC, en waarom lekt het

WebRTC (Web Real-Time Communication) is een technologie die nativief in zo goed als alle moderne browsers is ingebouwd, bedoeld om audio-, video- of datacommunicatie rechtstreeks tussen twee toestellen mogelijk te maken — videoconferentie in de browser is het meest voorkomende gebruik, zonder dat je iets hoeft te installeren.

Om deze rechtstreekse verbinding tussen twee toestellen tot stand te brengen, gebruikt WebRTC een adresontdekkingsprotocol (ICE) dat een STUN-server bevraagt om te bepalen welke IP-adressen écht bereikbaar zijn. Elke site kan dit mechanisme activeren met een paar regels JavaScript, zelfs zonder ooit een videofunctie te tonen — en afhankelijk van de precieze configuratie van browser en VPN kan deze adresontdekking een ander netwerkpad volgen dan de VPN-tunnel, waardoor het echte IP dat je internetprovider toekende wordt onthuld.

Concreet in België: zelfs verbonden met een VPN kan een WebRTC-lek zowel je lokale IP op je thuisnetwerk (meestal in het formaat 192.168.x.x) als je echte publieke IP van Proximus, VOO of Telenet onthullen — beide gegevens die je VPN geacht wordt te verbergen. De test hierboven filtert bewust de lokale adressen uit zijn verdict (ze bewijzen op zich niets, elk gewoon thuisnetwerk onthult er altijd één), maar vergelijkt wél je standaard publieke IP met wat WebRTC blootgeeft.

Hoe te verhelpen, per browser

• Chrome: geen eenvoudige native instelling is beschikbaar in de instellingen voor het grote publiek. Google zelf publiceert een officiële extensie, "WebRTC Network Limiter", beschikbaar op de Chrome Web Store, die WebRTC beperkt tot de publieke IP-adressen die horen bij de netwerkinterface die écht voor het surfen wordt gebruikt.
• Firefox: open een nieuw tabblad, typ about:config, aanvaard de waarschuwing, zoek naar media.peerconnection.enabled en zet de waarde op "false". Deze optie schakelt WebRTC volledig uit — zie de aparte vraag in de FAQ hieronder als je sites gebruikt die ervan afhangen (videoconferentie in het bijzonder).
• Brave: beheert deze instelling nativief onder "WebRTC IP handling policy" (Instellingen > Privacy en beveiliging). De optie "Disable non-proxied UDP" is het strengst en wordt automatisch geactiveerd zodra Brave's strikte anti-fingerprintingbescherming actief is.
• Safari: biedt geen eenvoudige instelling in de Voorkeuren voor het grote publiek — de plaats van eventuele geavanceerde opties (Ontwikkelaarsmenu) verschilt per macOS/Safari-versie, rechtstreeks te controleren in jouw versie. Safari past standaard een vervaging van lokale adressen via mDNS toe, een native bescherming die al een deel van het risico beperkt zonder handmatige instelling.
• Edge: gebaseerd op Chromium, dezelfde extensies als Chrome werken. Browsereigen alternatief: open edge://flags, zoek naar « Anonymize local IPs exposed by WebRTC » en activeer de optie — ze anonimiseert de lokale IP-adressen die WebRTC blootgeeft zonder gangbare toepassingen zoals Teams te breken.

Welke VPN's beschermen op app-niveau

Sommige VPN's bieden bescherming tegen WebRTC-lekken rechtstreeks in hun app (vaak via een aparte browserextensie, of een instelling die UDP-verkeer buiten de tunnel blokkeert). Wij volgen dit precieze kenmerk nog niet op in onze database van aanbieders ( zie onze methodologie) — we zeggen dat liever eerlijk dan die bescherming toe te schrijven aan de ene of de andere aanbieder zonder ze zelf te hebben geverifieerd. In afwachting daarvan blijft de hierboven beschreven instelling op browserniveau de betrouwbaarste methode, ongeacht welke VPN je gebruikt.

Wat degelijke VPN's doorgaans doen, zonder dat dit per aanbieder in onze database gedocumenteerd is: de STUN-aanvragen dwingen om via de versleutelde tunnel te lopen (het onthulde IP is dan dat van de VPN-server, niet het jouwe), of deze aanvragen gewoonweg blokkeren op netwerkniveau. Een VPN-extensie die rechtstreeks in de browser is geïnstalleerd, heeft op dit precieze punt vaak een voordeel ten opzichte van een systeem-app: ze kan WebRTC onderscheppen op het niveau van de browser zelf, in plaats van op netwerkniveau — in ruil daarvoor beschermt ze enkel die browser, niet de andere apps op je systeem.

Het resultaat zelf controleren, via de ontwikkelaarsconsole

De automatische test hierboven doet het werk in de overgrote meerderheid van de gevallen, maar als je het mechanisme live wil observeren: open de ontwikkelaarstools van je browser (F12-toets op Chrome/Firefox, tabblad « Netwerk ») terwijl de test draait. Je zou een UDP-aanvraag naar de STUN-server van Google moeten zien, en geen enkel HTTP-verzoek naar beste-vpn.be dat aan dit resultaat gelinkt is — het bewijs dat er niets naar onze server wordt gestuurd. Voor meer technisch gebruik laat het tabblad « Console » ook toe om handmatig een RTCPeerConnection aan te maken en de teruggegeven ICE-kandidaten één voor één te observeren — precies wat deze test voor jou automatiseert.