A böngésző proxyja a WebRTC-re is kiterjed?
A szokásos webes IP-ellenőrzés és a WebRTC-kapcsolat eltérő útvonalakat használhat. A böngésző valós idejű kommunikációját külön ellenőrizze.
A böngésző HTTP-proxybeállítása nem terjed ki automatikusan a WebRTC-re. Egy szokásos IP-ellenőrző oldal webes kérést mér; egy hívás külön utakat használhat a kapcsolódáshoz és a címek felderítéséhez.
A SOCKS5 sem szünteti meg ezt a különbséget. A Chromium beépített SOCKS5 URL-proxymegvalósítása TCP-t támogat, nem általános UDP-társítást. A protokoll lehetőségei szélesebbek ennél a böngészőfelületnél.
A böngészők külön hálózati vezérlést adnak a WebRTC-hez. A Chrome az adatvédelmi bővítmény-API-n keresztül tesz elérhetővé IP-kezelési házirendet, többek között az disable_non_proxied_udp értéket; a Mozilla is dokumentál WebRTC hálózati adatvédelmi beállításokat. Ez a Chrome-érték API-házirend, nem általános jelölőnégyzet és nem garancia minden cím elrejtésére.
Ellenőrizze a szokásos webes kilépést, majd a WebRTC viselkedését a ténylegesen használt konferenciaalkalmazásban, olyan diagnosztikával, amelynek jelentett mezőit érti. A helyi, közvetítői és nyilvánosan megfigyelt címek a kapcsolat különböző részeit írják le. Jegyezze fel a böngészőt és a tesztfeltételeket: a házirendek, bővítmények, adatvédelmi működés és elérhető utak befolyásolják az eredményt. Sem a „mindig szivárog”, sem egy sikeres webes IP-ellenőrzés nem elegendő következtetés.
Ha korlátoz egy WebRTC-útvonalat, próbálja ki újra a szükséges hívásokat. A címek felfedésének csökkentése a hívás létrejöttét is megakadályozhatja. Ez a kompromisszum külön kérdés attól, hogy egy HTTP-proxyvégpont elérhető-e.