Arakatzailearen proxyak WebRTC ere estaltzen al du?
Webeko ohiko IP-egiaztapenak eta WebRTC konexioak bide desberdinak erabil ditzakete. Egiaztatu arakatzailearen denbora errealeko komunikazioa bereizita.
Arakatzailearen HTTP proxy-ezarpenak ez du WebRTC automatikoki estaltzen. IPa egiaztatzeko ohiko orriak web-eskaera bat neurtzen du; deiak bide bereiziak erabil ditzake konektatzeko eta helbideak aurkitzeko.
SOCKS5ek ez du bereizketa hori desagerrarazten. Chromiumek barnean duen SOCKS5 URL proxyaren inplementazioak TCP onartzen du, ez UDP elkarketa orokor bat. Protokoloaren ahalmenak arakatzailearen interfaze horrenak baino zabalagoak dira.
Arakatzaileek WebRTC-rako sare-kontrol bereiziak dituzte. Chromek IPak kudeatzeko politika eskaintzen du pribatutasun-hedapenen APIaren bidez, disable_non_proxied_udp barne; Mozillak ere WebRTC sare-pribatutasunaren ezarpenak dokumentatzen ditu. Chrome balio hori API-politika bat da, ez kontrol-lauki unibertsal bat edo helbide guztiak ezkutatzeko bermea.
Egiaztatu webeko ohiko irteera, eta ondoren WebRTC-ren portaera benetan erabiliko duzun konferentzia-aplikazioan, jakinarazten dituen eremuak ulertzen dituzun diagnostiko batekin. Tokiko helbideek, errele-helbideek eta kanpotik behatutako helbide publikoek konexioaren zati desberdinak deskribatzen dituzte. Erregistratu arakatzailea eta probaren baldintzak: politikek, hedapenek, pribatutasun-portaerak eta erabilgarri dauden bideek eragina dute emaitzan. Beraz, ez «beti filtratzen du» esateak ez webeko IP-egiaztapen arrakastatsu batek ez dute ondorio nahikorik ematen.
WebRTC bide bat mugatzen baduzu, probatu berriro behar dituzun deiak. Helbideen agerpena murrizteak deia konektatzea ere eragotz dezake. Oreka hori HTTP proxy-muturraren erabilgarritasunetik apartekoa da.