Gilt ein Browser-Proxy auch für WebRTC?
Ein normaler Web-IP-Test und eine WebRTC-Verbindung nutzen unterschiedliche Wege. Prüfen Sie das Echtzeit-Kommunikationsverhalten des Browsers gesondert.
Die HTTP-Proxy-Einstellung eines Browsers gilt nicht automatisch für WebRTC. Eine normale IP-Prüfseite misst eine Webanfrage; ein Anruf kann für Verbindung und Adressermittlung andere Wege nutzen.
SOCKS5 hebt diesen Unterschied nicht auf. Die in Chromium eingebaute SOCKS5-URL-Proxy-Implementierung unterstützt TCP, keine allgemeine UDP-Assoziation. Das Protokoll bietet mehr Möglichkeiten als diese Browser-Schnittstelle.
Browser bieten eigene WebRTC-Netzwerkeinstellungen. Chrome stellt über seine Datenschutz-Erweiterungs-API eine Richtlinie zur IP-Behandlung bereit, darunter disable_non_proxied_udp; auch Mozilla dokumentiert WebRTC-Einstellungen zum Netzwerkdatenschutz. Der Chrome-Wert ist eine API-Richtlinie, kein allgemeingültiges Kontrollkästchen und keine Garantie, jede Adresse zu verbergen.
Prüfen Sie den normalen Web-Ausgang und anschließend das WebRTC-Verhalten in der tatsächlich verwendeten Konferenzanwendung. Nutzen Sie eine Diagnose, deren Ergebnisfelder Sie verstehen. Lokale Adressen, Relay-Adressen und öffentlich beobachtete Adressen beschreiben verschiedene Teile einer Verbindung. Halten Sie Browser und Testbedingungen fest: Richtlinien, Erweiterungen, Datenschutzverhalten und verfügbare Wege beeinflussen das Ergebnis. Weder „leckt immer“ noch ein erfolgreicher Web-IP-Test reicht deshalb als Schlussfolgerung aus.
Wenn Sie einen WebRTC-Weg einschränken, testen Sie die benötigten Anrufe erneut. Weniger Adressoffenlegung kann auch verhindern, dass ein Anruf zustande kommt. Diese Abwägung ist von der Frage getrennt, ob ein HTTP-Proxy-Endpunkt online ist.