Wat is een WebRTC-lek
WebRTC is de ingebouwde realtimecommunicatie van de browser, gebruikt voor videovergaderingen, spraakoproepen, P2P-bestandsoverdracht en vergelijkbare toepassingen. Om een peer-to-peerverbinding op te zetten, achterhaalt de browser via een STUN-server zijn eigen publieke adres. Dat gebeurt meestal via UDP, en gewone HTTP- / SOCKS-proxy's onderscheppen UDP niet per se.
Als het STUN-verzoek de proxy omzeilt en rechtstreeks vanaf het lokale netwerk vertrekt, kan een script op een webpagina je echte publieke IP-adres achterhalen. Daarvoor is meestal geen toestemming voor camera of microfoon nodig en verschijnt er geen extra bevestigingsvenster; daarom wordt het vaak gebruikt om te controleren of een proxy realtimecommunicatie echt afdekt.
Hoe deze tool het detecteert
De pagina voert WebRTC-metingen uit tegen meerdere STUN-servers, verzamelt de teruggegeven publieke adressen en vergelijkt ze met het HTTP-exit-IP. Komt het teruggegeven adres overeen met de huidige uitgang, dan wordt het UDP-pad waarschijnlijk door de proxy afgehandeld; geeft het een adres van je lokale provider terug, dan is dat het onderzoeken waard.
- Controleren of UDP via de proxy-uitgang gaat
- Detecteren of IPv4 en IPv6 elk afzonderlijk lekken
- Kijken of verschillende STUN-doelen verschillende routeringsregels raken
De rol van STUN en UDP
UDP is een verbindingsloos transportprotocol dat veel wordt gebruikt voor spraak, video, games en realtimecommunicatie. De taak van STUN is eenvoudig: je stuurt een UDP-pakket naar de server, en de server vertelt je welk bron-IP hij zag. WebRTC gebruikt dat resultaat om een verbinding op te zetten, dus het adres dat STUN ziet, is het belangrijkste bewijs om een lek te beoordelen.
Zo lees je de resultaten
Geen lek gedetecteerdHet publieke IP-adres dat WebRTC teruggeeft, komt overeen met je huidige proxy-uitgang (bij IPv6: hetzelfde /64). Komt er helemaal geen publiek IP-adres terug, dan kreeg de test simpelweg geen antwoord; dat is geen bewijs dat alles veilig is.
Vermoedelijk lekWebRTC gaf een ander publiek IP-adres terug, en de locatie, provider of het ASN daarvan wijst naar je echte lokale netwerk.
Normale routering volgens regelsMeerdere STUN-servers gaven verschillende proxy-uitgangen terug, maar die uitgangen passen bij de routering of regels die je zelf hebt ingesteld.
Wat te doen als je een lek vindt
- Zet je proxyclient in de TUN-modus, zodat ook het UDP-verkeer van WebRTC via de proxy-uitgang gaat.
- Chrome / Edge: stel het bedrijfsbeleid <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code> in; Firefox: schakel <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code> in via <code>about:config</code>. Verwijder WebRTC niet helemaal, want een browser zonder WebRTC is op zichzelf al herkenbaar.
- Brave: stel het beleid voor WebRTC-IP-afhandeling in op “Disable non-proxied UDP”.
- Heb je vergaderingen of spraakoproepen nodig, corrigeer dan eerst de UDP- / STUN-routeringsregels in je proxyclient.
Meerdere exit-IP's zijn niet per se een lek
Als je routering op basis van regels hebt ingesteld, kunnen verschillende STUN-servers via verschillende knooppunten lopen — bijvoorbeeld de STUN van Google via een uitgang in de VS en de STUN van Cloudflare via een uitgang in Hongkong. Dat is niet per se gevaarlijk; het gaat erom of het overeenkomt met hoe je je regels hebt opgezet. Waar je echt op moet letten, is wanneer alle WebRTC-adressen naar je fysieke locatie of je lokale provider wijzen.
DNS-lekken zijn net zo belangrijk
Een WebRTC-lek geeft “je echte IP-adres” prijs; een DNS-lek geeft prijs “welke domeinen je hebt opgevraagd”. Als DNS-verzoeken niet via de proxy gaan, kan je lokale provider of upstream-resolver nog steeds zien welke sites je hebt bezocht.
De DNS-lekdetectie op deze pagina gebruikt een echte meting: CleanIP.io draait twee gezaghebbende NS'en, één in Utah, VS (ns1) en één in Los Angeles, VS (ns2), voor de zone dp.cleanip.io. Bij elke detectie worden 8 onafhankelijke subdomeinen <uuid>.dp.cleanip.io opgevraagd; die query's gaan via de stub-resolver van je systeem -> provider / VPN / publieke recursieve resolver en komen uiteindelijk bij onze gezaghebbende NS uit, die het IP van de opvragende resolver en (indien aanwezig) het EDNS Client Subnet vastlegt en aan jou teruggeeft om te vergelijken.
Let op twee signalen: ① ECS-subnet — als de recursieve resolver je clientsubnet heeft doorgestuurd (gebruikelijk bij Google 8.8.8.8), is dat subnet onomstotelijk bewijs van je clientidentiteit; ② land van de resolver — grensoverschrijdende anycast bij publieke recursieve resolvers (1.1.1.1 / 8.8.8.8) is normaal; het gaat erom of de resolver, wanneer je denkt dat je VPN aanstaat, in hetzelfde land ligt als je HTTP-uitgang.
Waarom proxymodus en TUN-modus verschillende resultaten geven
HTTP- / SOCKS-proxy's verwerken meestal alleen TCP, dus het UDP-verkeer dat STUN nodig heeft, wordt mogelijk niet verzonden en de pagina kan “geen lek” tonen. Dat betekent niet dat UDP veilig via de proxy loopt — alleen dat UDP de STUN-server nooit heeft bereikt. De TUN-modus vangt zowel TCP als UDP op de virtuele netwerkadapter af en geeft dus een beter beeld van het werkelijke UDP-uitgangspad.
ModusSTUN UDPBetekenis
HTTP- / SOCKS-proxyWordt mogelijk niet verzonden“Geen lek” kan ook betekenen dat UDP is geblokkeerd
TUN / virtuele adapterWordt echt verzondenBeter geschikt om UDP-uitgang en routeringsregels te controleren