Een proxy dekt vaak HTTP-verkeer af, terwijl WebRTC via STUN/ICE over UDP kandidaatadressen uitwisselt. Dit artikel legt uit wanneer lokale en privéadressen zichtbaar kunnen worden en hoe je netwerkuitgang en browseromgeving consistent houdt.
Je hebt een proxy ingesteld en een IP-controlepagina toont de verwachte regio en provider. Je netwerkidentiteit lijkt op orde. Maar zodra je een lektest opent, staat het WebRTC-gedeelte rood en verschijnt het adres van je echte internetverbinding.
Vervang de proxy niet meteen. Meestal ligt het probleem niet aan de kwaliteit van de proxy, maar aan verkeer dat buiten zijn bereik valt.
De proxy verwerkt HTTP, WebRTC neemt een andere route
Een proxy werkt op de netwerklaag. Of hij nu als browserextensie of als systeemtunnel is ingericht, hij verwerkt HTTP/HTTPS-verzoeken en stuurt dat verkeer via de proxy-uitgang.
WebRTC werkt anders. Het is een realtimecommunicatiefunctie die in de browser is ingebouwd. Om voor audio-/videogesprekken en P2P-overdracht een geschikte route te vinden, kan de browser actief STUN-verzoeken naar externe servers sturen — in feite met de vraag: “Welk adres zie je voor mij?” — en de antwoorden vervolgens als ICE-kandidaten aan de webpagina doorgeven. Deze verzoeken gebruiken UDP en lopen dus via een kanaal dat losstaat van de HTTP-tunnel.
Zo ontstaat een verschil: webverzoeken gaan via de proxy, terwijl de browser tegelijk een lokaal adres kan melden. Aannemen dat een ingestelde proxy automatisch betekent dat de volledige netwerkidentiteit schoon is, is het meest voorkomende vertrekpunt van dit probleem.
Niet alleen het openbare IP-adres kan worden prijsgegeven
ICE-kandidaten bevatten doorgaans twee soorten adressen. Het ene is het openbare adres, oftewel de uitgang van je echte internetprovider. Het andere is een lokaal adres, bijvoorbeeld een privéadres dat met 192.168 begint, en soms ook een adres van een virtuele netwerkadapter.
Een privénetwerkadres zegt op zichzelf weinig; vrijwel elke computer heeft er een. Maar het kan stabiel genoeg zijn dat herhaaldelijk overlappende kandidaatadressen van meerdere accounts een platform extra aanwijzingen geven om ze aan hetzelfde apparaat te koppelen. Een openbaar adres is directer: het wijst naar de werkelijke provider en een globale geografische locatie. Hoe nauwkeurig die informatie wordt, hangt van het platform af, maar de richting is duidelijk: hoe echter het adres, hoe eenvoudiger de koppeling.
Wanneer kan een website het echt uitlezen?
Niet elke website probeert dat. Voor de adresuitwisseling moet de pagina actief een RTCPeerConnection-object aanmaken, iets wat gewone inhoudspagina’s doorgaans niet nodig hebben.
Sites die dit wel doen vallen meestal in enkele groepen: diensten die realtimecommunicatie nodig hebben, zoals videobellen, online klantenservice en sommige livestreams; sites die sterk leunen op advertenties of fraudepreventie; en platforms met uitgebreide risicocontroles. Het uitlezen gebeurt buiten het zichtbare deel van de interface, en nadat de gegevens zijn verzameld krijg je meestal geen melding over hoe ze verder worden gebruikt.
Er is ook een situatie die losstaat van de website. In het korte moment waarin de proxy opnieuw verbinding maakt of van node wisselt, kan een STUN-verzoek van de browser via het lokale netwerk lopen. Dat venster is klein, maar lang genoeg om één waarneming vast te leggen.
Drie veelvoorkomende faalscenario’s
Proxy’s als browserextensie nemen meestal alleen HTTP/HTTPS-verzoeken over. UDP valt buiten hun bereik, en een optie “globaal” aanvinken in de interface verandert daar niets aan.
Een systeembrede proxy lijkt vollediger omdat hij het verkeer van het hele apparaat dekt. Het verzamelen van kandidaatadressen kan echter rechtstreeks aan een lokale netwerkinterface worden gekoppeld en de routeringstabel van het systeem omzeilen, waardoor de tunnel op dit punt een lek houdt.
Het derde probleem is niet uitsluitend technisch, maar heeft ook met veranderende controles te maken. Risicosystemen gebruiken WebRTC-adressen steeds vaker als een van meerdere signalen om accounts aan elkaar te koppelen. Gegevens die vroeger niet werden gemeten of eenvoudig werden genegeerd, kunnen nu in de beoordeling meetellen.
Het doel is een consistente uitgang, niet alleen één schakelaar uitzetten
Er zijn verschillende algemene benaderingen. Als een workflow helemaal geen realtimecommunicatie nodig heeft, is WebRTC uitschakelen de eenvoudigste optie. Het nadeel is dat functies zoals videobellen en online klantenservice dan ook niet meer werken.
Als die functies behouden moeten blijven, is een veelgebruikte aanpak om het adres dat op WebRTC-niveau wordt teruggegeven te laten overeenkomen met de proxy-uitgang. Nog robuuster is om ook STUN-verzoeken via het proxykanaal door te sturen, zodat de interface het lokale adres niet blootlegt. Voor toepassingen die P2P of videobellen nodig hebben, moet al het UDP-verkeer via de proxy lopen en niet alleen de HTTP-laag.
Een veelgemaakte fout is denken dat alleen WebRTC uitschakelen de omgeving al schoon maakt. Het gaat om onderlinge consistentie tussen netwerkuitgang, DNS-resolutie, IP-eigendom en ASN, tijdzone en taal, en apparaatkenmerken. Elke afwijking kan een afwijkend signaal opleveren; WebRTC is slechts een van de onderdelen die het gemakkelijkst over het hoofd worden gezien.
Controleren is eenvoudig. Test eenmaal na het wisselen van node en nogmaals voordat je de omgeving normaal gaat gebruiken: open een lektest en kijk of WebRTC de proxy-uitgang, een lokaal adres of het echte openbare adres toont. Een gewone IP-controle laat dit niet zien.
Omgevingsisolatie op het niveau van de browserengine kan voor elke omgeving een apart WebRTC-adresbeleid instellen en dat koppelen aan de netwerkuitgang van die omgeving. PurpleMark biedt dit soort mogelijkheden. Als meerdere omgevingen één uitgang delen of hun adresbeleid niet met elkaar overeenstemt, neemt de waarde van de isolatie sterk af.
Dit is uitsluitend een technische uitleg. Gebruik relevante hulpmiddelen in overeenstemming met platformregels en lokale wetgeving.
