Geldt een browserproxy ook voor WebRTC?
Een gewone web-IP-test en een WebRTC-verbinding kunnen andere routes volgen. Controleer de realtimecommunicatie van de browser afzonderlijk.
De HTTP-proxyinstelling van een browser geldt niet automatisch voor WebRTC. Een gewone IP-testpagina meet een webverzoek; een gesprek kan eigen routes gebruiken voor de verbinding en het ontdekken van adressen.
SOCKS5 neemt dat onderscheid niet weg. De ingebouwde SOCKS5-URL-proxyimplementatie van Chromium ondersteunt TCP, geen algemene UDP-associatie. Het protocol kan meer dan deze browserinterface biedt.
Browsers hebben aparte netwerkopties voor WebRTC. Chrome biedt via zijn privacy-extensie-API beleid voor IP-afhandeling, waaronder disable_non_proxied_udp; Mozilla documenteert ook instellingen voor WebRTC-netwerkprivacy. Die Chrome-waarde is API-beleid, geen universeel selectievakje of garantie dat elk adres verborgen blijft.
Controleer de gewone webuitgang en bekijk daarna het WebRTC-gedrag in de vergaderapp die je echt gebruikt, met een diagnose waarvan je de gerapporteerde velden begrijpt. Lokale adressen, relayadressen en publiek waargenomen adressen beschrijven verschillende delen van een verbinding. Noteer browser en testomstandigheden: beleid, extensies, privacygedrag en beschikbare routes beïnvloeden het resultaat. Zowel ‘lekt altijd’ als een geslaagde web-IP-test schiet daarom tekort als conclusie.
Beperk je een WebRTC-route, probeer dan de benodigde gesprekken opnieuw. Minder blootstelling van adressen kan ook verhinderen dat een gesprek verbinding maakt. Die afweging staat los van de vraag of een HTTP-proxyendpoint online is.