La configuració de servidor intermediari HTTP del navegador no cobreix WebRTC automàticament. Una pàgina habitual de comprovació d’IP mesura una petició web; una trucada pot fer servir camins separats per connectar-se i descobrir adreces.

SOCKS5 no elimina aquesta distinció. La implementació de servidor intermediari d’URL SOCKS5 integrada a Chromium admet TCP, no una associació UDP genèrica. El protocol ofereix més possibilitats que aquesta interfície del navegador.

Els navegadors proporcionen controls de xarxa separats per a WebRTC. Chrome exposa una política de tractament d’IP mitjançant l’API d’extensions de privadesa, incloent-hi disable_non_proxied_udp; Mozilla també documenta opcions de privadesa de xarxa de WebRTC. Aquest valor de Chrome és una política d’API, no una casella universal ni una garantia d’amagar totes les adreces.

Comprova la sortida web habitual i després examina WebRTC a l’aplicació de conferències que realment fas servir, amb un diagnòstic del qual entenguis els camps. Les adreces locals, de retransmissió i públiques observades descriuen parts diferents de la connexió. Anota el navegador i les condicions de prova: polítiques, extensions, comportament de privadesa i camins disponibles influeixen en el resultat. Ni «sempre filtra» ni una comprovació d’IP web reeixida són prou per concloure.

Si restringeixes un camí WebRTC, torna a provar les trucades que necessites. Reduir l’exposició d’adreces també pot impedir que una trucada es connecti. Aquest compromís és independent que un punt final de servidor intermediari HTTP estigui en línia.

Articles relacionats