¿Qué hacer cuando el navegador anti-detección muestra una fuga de WebRTC? Guía de diagnóstico y reparación con MostLogin

Resumen del contenido: Cuando al realizar comprobaciones de negocio WebRTC muestra una fuga, debe detener inmediatamente el inicio de sesi\u00f3n o las operaciones con cuentas importantes, cerrar el entorno actual y luego verificar la conexi\u00f3n del proxy, el modo WebRTC, IPv6 y las reglas de omisi\u00f3n del proxy. Para los usuarios de MostLogin, el procedimiento habitual es: confirmar que la detecci\u00f3n del proxy fue exitosa, configurar WebRTC del entorno en Private (Privado); si el negocio no requiere audio/v\u00eddeo en la web ni comunicaci\u00f3n punto a punto, tambi\u00e9n puede elegir Disabled (Deshabilitado); adem\u00e1s, active la regla de protecci\u00f3n que impide abrir el entorno cuando el proxy falla.

Es importante tener en cuenta que la aparici\u00f3n de m\u00faltiples direcciones en la p\u00e1gina de prueba no necesariamente indica una fuga. Solo cuando la p\u00e1gina expone su IPv4 p\u00fablica real, su IPv6 p\u00fablica real, o aparecen salidas de red que no deber\u00edan estar asociadas con ese entorno, se trata de un problema de alto riesgo que requiere acci\u00f3n inmediata.

\u00bfQu\u00e9 es WebRTC? \u00bfPor qu\u00e9 puede evadir la configuraci\u00f3n normal del proxy?

WebRTC son las siglas de Web Real-Time Communication, es decir, \u00abcomunicaci\u00f3n en tiempo real a trav\u00e9s de la web\u00bb. Permite que los navegadores realicen llamadas de voz, videoconferencias, uso compartido de pantalla y transmisi\u00f3n de datos punto a punto directamente. Muchas herramientas de reuniones en l\u00ednea, atenci\u00f3n al cliente y colaboraci\u00f3n lo utilizan.

Para encontrar una ruta de conexi\u00f3n viable entre dos dispositivos, WebRTC utiliza ICE para recopilar m\u00faltiples \u00abcandidatos\u00bb. Estos candidatos pueden incluir direcciones de interfaces de red del dispositivo, direcciones p\u00fablicas mapeadas descubiertas mediante servidores STUN y direcciones retransmitidas por servidores TURN. La documentaci\u00f3n de MDN sobre los tipos de candidatos ICE indica que los candidatos host representan direcciones directas del dispositivo, los candidatos srflx se generan mediante la interacci\u00f3n STUN/TURN, y los candidatos relay se retransmiten a trav\u00e9s de TURN. Documentaci\u00f3n de MDN sobre conectividad WebRTC

Esta es la raz\u00f3n fundamental por la que se producen las fugas de WebRTC: la p\u00e1gina web crea una conexi\u00f3n WebRTC mediante JavaScript y lee los candidatos ICE. Si el navegador no restringe correctamente estas direcciones, la informaci\u00f3n de red que ve la p\u00e1gina puede no coincidir con la salida del proxy. MDN tambi\u00e9n se\u00f1ala claramente que las direcciones de los candidatos ICE pueden revelar informaci\u00f3n sobre la ubicaci\u00f3n del dispositivo y la topolog\u00eda de red m\u00e1s all\u00e1 de lo que el usuario espera, y pueden utilizarse para la creaci\u00f3n de huellas digitales del navegador. Notas de seguridad de MDN sobre RTCIceCandidate

Explicaci\u00f3n sencilla: las solicitudes web normales pueden pasar por el proxy, pero WebRTC busca adicionalmente rutas de comunicaci\u00f3n en tiempo real. Cuando ambas rutas no est\u00e1n unificadas, el sitio web puede ver simult\u00e1neamente la \u00abIP del proxy\u00bb y \u00abotro conjunto de direcciones de red\u00bb.

\u00bfQu\u00e9 se considera exactamente una fuga de WebRTC?

Para determinar si hay una fuga, no basta con ver si aparecen direcciones IP en la p\u00e1gina de prueba; hay que comparar \u00ablo que muestra la p\u00e1gina\u00bb con \u00blo que deber\u00eda mostrar el entorno\u00bb.

Los navegadores modernos pueden sustituir las IP de la red local por nombres de host mDNS, por lo que ver resultados con cadenas aleatorias seguidas de .local en la p\u00e1gina de prueba no equivale a que se haya expuesto su IP p\u00fablica real. Lo que realmente debe preocuparle es si aparecen direcciones ISP p\u00fablicas reales que haya encontrado fuera del entorno del navegador.

\u00bfQu\u00e9 consecuencias tiene una fuga de WebRTC?

1. Conflicto entre la identidad del proxy y la identidad de red real

Supongamos que un entorno de MostLogin est\u00e1 configurado con un proxy de Nueva York, EE. UU., y las solicitudes web tambi\u00e9n muestran la IP de Nueva York, pero WebRTC expone la IP p\u00fablica de la red local del usuario. La plataforma no ve un entorno de navegaci\u00f3n natural y estable, sino dos se\u00f1ales de conexi\u00f3n con ubicaciones geogr\u00e1ficas o proveedores de red en conflicto.

Esto no demuestra autom\u00e1ticamente qui\u00e9n es el usuario, pero debilita el efecto de aislamiento del proxy y puede convertirse en una de las se\u00f1ales de riesgo an\u00f3malo, verificaci\u00f3n adicional o revisi\u00f3n de la sesi\u00f3n.

2. Diferentes entornos del navegador pueden quedar vinculados por la misma IP real

Un equipo crea m\u00faltiples entornos independientes para distintos proyectos de prueba, cada uno con un proxy diferente. Si todos estos entornos exponen la misma IP p\u00fablica de la oficina a trav\u00e9s de WebRTC, el sitio web podr\u00eda obtener una se\u00f1al de correlaci\u00f3n repetida entre entornos. Aunque las cookies, Canvas y WebGL est\u00e9n aislados, la aparici\u00f3n repetida de la misma salida de red real reduce la independencia entre los entornos.

3. Exposici\u00f3n de la ubicaci\u00f3n aproximada, el proveedor de red y la estructura de red

Las IP p\u00fablicas suelen utilizarse para determinar el pa\u00eds, la regi\u00f3n a nivel de ciudad y el proveedor de red; las direcciones de red local, IPv6 o las distintas interfaces de red pueden revelar a\u00fan m\u00e1s caracter\u00edsticas de la topolog\u00eda de red. Por lo general, una IP no puede determinar por s\u00ed sola una direcci\u00f3n exacta o una identidad real, pero puede combinarse con cuentas, cookies, huellas digitales del dispositivo y datos de comportamiento.

4. Las videoconferencias y llamadas web pueden plantear un dilema entre privacidad y usabilidad

Deshabilitar WebRTC directamente puede reducir la superficie de exposici\u00f3n, pero las videoconferencias, la atenci\u00f3n al cliente por voz, el uso compartido de pantalla o la transferencia directa de archivos que dependen de WebRTC podr\u00edan dejar de funcionar. Por lo tanto, lo correcto no es desactivarlo en todos los escenarios, sino elegir entre Private y Disabled seg\u00fan las necesidades del negocio.

Primeros 6 pasos tras detectar una fuga de WebRTC en el navegador anti-detecci\u00f3n

Paso 1: Detenga las operaciones sensibles en el entorno actual

Si la p\u00e1gina de detecci\u00f3n ya muestra su IP p\u00fablica real, no contin\u00fae iniciando sesi\u00f3n, realizando pagos, publicando contenido ni cambiando cuentas importantes. Primero registre los resultados de la prueba, incluyendo:

• La direcci\u00f3n mostrada por la detecci\u00f3n normal de IP;
• Las IPv4 e IPv6 mostradas por la detecci\u00f3n de WebRTC;
• La direcci\u00f3n del proxy y el pa\u00eds/regi\u00f3n configurados en MostLogin;
• La hora de la prueba, el nombre del entorno y si se utiliz\u00f3 VPN.

Registrar la informaci\u00f3n sirve para localizar el problema; no se recomienda conservar en las capturas de pantalla contrase\u00f1as del proxy, cookies de cuentas u otras credenciales.

Paso 2: Establezca una comparaci\u00f3n entre \u00abIP real \u2014 IP del proxy \u2014 IP de WebRTC\u00bb

Realice tres grupos de comprobaciones sin abrir las cuentas de negocio:

1. En un navegador normal y sin proxy, consulte la IPv4 e IPv6 p\u00fablicas actuales como l\u00ednea base de la red real.
2. En la pesta\u00f1a Proxy de MostLogin, haga clic en la comprobaci\u00f3n de IP del proxy y registre la salida esperada.
3. Abra el entorno correspondiente y lea los candidatos en la p\u00e1gina de prueba de WebRTC.

Si el resultado de WebRTC es igual al primer grupo de l\u00ednea base, pero no al segundo grupo de salida del proxy, se puede confirmar b\u00e1sicamente que existe una fuga. Si el resultado coincide con la IP del proxy, es m\u00e1s probable que se trate de una presentaci\u00f3n normal de candidatos WebRTC.

Paso 3: Repare primero el proxy, luego ajuste WebRTC

La configuraci\u00f3n de WebRTC no puede remediar un proxy que ya est\u00e1 desconectado, ha fallado la autenticaci\u00f3n o est\u00e1 mal configurado. Vaya a la p\u00e1gina de edici\u00f3n del entorno de destino, abra la pesta\u00f1a Proxy, verifique el protocolo, host, puerto, usuario y contrase\u00f1a, y luego ejecute la comprobaci\u00f3n de IP del proxy. La gu\u00eda oficial de creaci\u00f3n de entornos de MostLogin indica que actualmente se pueden configurar direct, http, https y socks5, y se puede verificar el resultado de la conexi\u00f3n mediante \u00abCheck proxy IP\u00bb. MostLogin: Crear un nuevo entorno

Solo contin\u00fae con el siguiente paso cuando la comprobaci\u00f3n del proxy sea exitosa y el pa\u00eds y la ciudad mostrados coincidan con lo esperado.

Paso 4: Seleccione el modo WebRTC adecuado en MostLogin

La ruta de operaci\u00f3n suele ser:

Profiles (Lista de entornos) \u2192 Seleccionar entorno objetivo \u2192 Edit (Editar) \u2192 Fingerprint (Huella digital) \u2192 WebRTC

La documentaci\u00f3n oficial actual de MostLogin muestra el men\u00fa desplegable de configuraci\u00f3n de WebRTC, donde Private se utiliza para ocultar la IP real manteniendo la funcionalidad de WebRTC, y tambi\u00e9n puede ofrecer Public y Disabled. MostLogin: Instrucciones de configuraci\u00f3n de huella digital WebRTC

Para entornos proxy normales, se recomienda empezar con Private. Solo cuando el negocio no dependa de WebRTC, o el modo Private no satisfaga los requisitos de aislamiento, pruebe Disabled. No asuma que hay una fuga simplemente porque la p\u00e1gina de prueba muestre \u00abWebRTC enabled\u00bb; lo importante es qu\u00e9 direcci\u00f3n devuelve.

Paso 5: Active la protecci\u00f3n ante fallos del proxy y revise la lista de omisi\u00f3n del proxy

Vaya a la configuraci\u00f3n global o a las preferencias del entorno en MostLogin y active las siguientes protecciones:

• No abrir el entorno cuando haya errores de red del proxy;
• No abrir el entorno cuando cambie la IP del proxy;
• No abrir el entorno cuando cambie el pa\u00eds o regi\u00f3n de la IP del proxy;
• No abrir el entorno cuando falle la sincronizaci\u00f3n del entorno.

MostLogin describe oficialmente estos ajustes como protecciones previas al inicio. La protecci\u00f3n ante errores de red del proxy impide que se exponga accidentalmente la IP real del ISP cuando el proxy falla. MostLogin: Profile preferences

Tambi\u00e9n debe revisar Settings \u2192 Proxy bypass. Los dominios a\u00f1adidos a la lista de omisi\u00f3n utilizar\u00e1n directamente la red local en lugar del proxy del entorno actual. La documentaci\u00f3n oficial de MostLogin tambi\u00e9n indica claramente que los dominios omitidos se acceden mediante conexiones locales reales. MostLogin: Proxy bypass Si el sitio de prueba, los dominios de autenticaci\u00f3n o sus dominios de API/CDN est\u00e1n aqu\u00ed, elimine las excepciones innecesarias y guarde.

Paso 6: Cierre completamente el entorno, vuelva a abrirlo y realice pruebas cruzadas

Despu\u00e9s de guardar la configuraci\u00f3n, cierre todo el entorno del navegador y vuelva a iniciarlo; no se limite a actualizar la p\u00e1gina de detecci\u00f3n. Utilice al menos dos p\u00e1ginas de detecci\u00f3n independientes para comprobar:

• La IP p\u00fablica normal que muestra el navegador;
• La IPv4 entre los candidatos de WebRTC;
• La IPv6 entre los candidatos de WebRTC;
• Si DNS, zona horaria, idioma y ubicaci\u00f3n geogr\u00e1fica son coherentes con la regi\u00f3n del proxy.

El criterio de aprobaci\u00f3n de la prueba cruzada es: la p\u00e1gina de detecci\u00f3n ya no muestra IPv4/IPv6 p\u00fablicas reales del ISP; las direcciones p\u00fablicas mostradas por WebRTC deben coincidir con el proxy, la salida de retransmisi\u00f3n o el comportamiento esperado del producto; los resultados deben seguir siendo estables tras reiniciar el entorno.

Ejemplo de uso de MostLogin: Entorno con proxy de Nueva York detecta IPv6 real

Escenario

Un equipo de QA de sitios web multirregionales cre\u00f3 un entorno de MostLogin llamado US-NewYork-QA-01. La comprobaci\u00f3n del proxy HTTP muestra IPv4 de Nueva York, EE. UU. Al abrir la p\u00e1gina de prueba, la IP normal sigue siendo la de Nueva York, pero el \u00e1rea de WebRTC muestra una IPv6 p\u00fablica del proveedor de red local.

Diagn\u00f3stico

Se trata de una fuga real, no de un caso normal de \u00abaparici\u00f3n de m\u00faltiples IP\u00bb. La raz\u00f3n es que el proxy HTTP cubre las solicitudes web IPv4, pero la ruta de red IPv6 del host no se gestiona de igual manera, y los candidatos WebRTC a\u00fan pueden exponer esa direcci\u00f3n.

Soluci\u00f3n

1. Cierre el entorno para evitar continuar con las pruebas de inicio de sesi\u00f3n.
2. Compruebe si el servicio proxy admite expl\u00edcitamente IPv6; si no lo hace, utilice una soluci\u00f3n proxy que cubra completamente IPv4/IPv6, o desactive la ruta IPv6 no protegida a nivel de red del sistema.
3. Edite el entorno y seleccione Private en Fingerprint \u2192 WebRTC.
4. Active \u00abNo abrir el entorno cuando haya errores de red del proxy\u00bb.
5. Revise la lista de omisi\u00f3n del proxy y elimine los dominios de excepci\u00f3n relacionados con el sitio de prueba.
6. Vuelva a abrir el entorno y realice la prueba cruzada para confirmar que la IPv6 real ya no aparece.

En este escenario, cambiar solo el modo de WebRTC podr\u00eda eliminar temporalmente la detecci\u00f3n, pero la cobertura de IPv6 por el proxy sigue siendo el problema fundamental, por lo que ambos deben revisarse.

Ejemplo de uso de MostLogin: La p\u00e1gina de prueba muestra .local, pero la IP p\u00fablica coincide con el proxy

Escenario

Un usuario utiliza un proxy del Reino Unido; tanto la IP normal como las direcciones p\u00fablicas de WebRTC muestran el Reino Unido; la p\u00e1gina de prueba tambi\u00e9n muestra una cadena aleatoria que termina en .local, lo que le lleva a pensar err\u00f3neamente que se ha producido una fuga.

Evaluaci\u00f3n

.local suele ser la forma en que el navegador oculta las direcciones de la red local mediante nombres mDNS. Siempre que no aparezcan IPv4/IPv6 p\u00fablicas reales del ISP y los candidatos p\u00fablicos coincidan con el proxy del Reino Unido, no se puede determinar que haya una fuga de IP real bas\u00e1ndose \u00fanicamente en .local.

Soluci\u00f3n

Mantenga la configuraci\u00f3n Private actual, registre los resultados y verifique de forma cruzada con otra p\u00e1gina de prueba. En este punto, cambiar frecuentemente de proxy, aleatorizar huellas digitales o reconstruir el entorno podr\u00eda, de hecho, introducir m\u00e1s variaciones en un entorno de prueba que deber\u00eda ser estable.

Ejemplo de uso de MostLogin: Las videoconferencias no pueden conectarse tras desactivar WebRTC

Escenario

Un equipo de soporte remoto configur\u00f3 WebRTC en Disabled y las llamadas de atenci\u00f3n al cliente web y el uso compartido de pantalla no pudieron establecer conexi\u00f3n.

Soluci\u00f3n

Cambie el entorno a Private, mantenga la conexi\u00f3n normal del proxy y vuelva a probar las direcciones WebRTC. Si la IP real ya no aparece y el audio/v\u00eddeo se restablece, habr\u00e1 logrado combinar funcionalidad y aislamiento de red. Si en modo Private a\u00fan hay fuga, debe investigar el protocolo del proxy, IPv6, la divisi\u00f3n de VPN y los dominios de omisi\u00f3n, en lugar de elegir Public simplemente para restablecer las llamadas.

\u00bfD\u00f3nde puede estar el problema si la fuga persiste tras la reparaci\u00f3n?

Si MostLogin ya est\u00e1 configurado en Private pero la prueba sigue mostrando la IP p\u00fablica real, puede continuar verificando en el siguiente orden:

1. El proxy no est\u00e1 realmente conectado. Cuando las credenciales son incorrectas, el nodo ha caducado o el servidor proxy est\u00e1 fuera de l\u00ednea, el navegador puede no obtener la salida esperada.
2. IPv6 no est\u00e1 cubierta. El proxy solo gestiona IPv4, y el host a\u00fan puede acceder a la red a trav\u00e9s de IPv6 real.
3. Reglas de omisi\u00f3n del proxy. El sitio de prueba o subdominios relacionados est\u00e1n configurados para conexi\u00f3n directa.
4. Divisi\u00f3n de VPN o conflictos de enrutamiento del sistema. El uso simult\u00e1neo de VPN, proxy del sistema y proxy del entorno puede generar diferentes rutas de red.
5. El proceso del entorno anterior sigue ejecut\u00e1ndose. Si no se cerr\u00f3 completamente el entorno tras guardar la configuraci\u00f3n, el proceso anterior sigue utilizando la configuraci\u00f3n original.
6. Las extensiones del navegador alteran el comportamiento de la red. Las extensiones de VPN, proxy, privacidad o WebRTC pueden entrar en conflicto con la configuraci\u00f3n del entorno.
7. Falso positivo o cach\u00e9 de la p\u00e1gina de detecci\u00f3n. Utilice una segunda p\u00e1gina de prueba y reinicie el entorno para verificar; no saque conclusiones bas\u00e1ndose en un \u00fanico resultado.

Si dos p\u00e1ginas de prueba independientes muestran de forma estable la misma direcci\u00f3n p\u00fablica real, guarde capturas de pantalla sin credenciales sensibles, el n\u00famero de versi\u00f3n de MostLogin, el sistema operativo, el protocolo del proxy y los pasos de reproducci\u00f3n, y luego contacte con el soporte de MostLogin o con el proveedor del servicio proxy.

Lista de verificaci\u00f3n anti-fugas WebRTC

Despu\u00e9s del primer uso de cada nuevo entorno, tras un cambio de proxy, una actualizaci\u00f3n del cliente o un cambio de red, realice una vez la siguiente comprobaci\u00f3n:

•  La comprobaci\u00f3n de IP del proxy de MostLogin fue exitosa;
•  WebRTC est\u00e1 configurado en Private, o en Disabled cuando no se necesita comunicaci\u00f3n en tiempo real;
•  La IP p\u00fablica normal coincide con la salida esperada del proxy;
•  WebRTC no muestra la IPv4 p\u00fablica real del ISP;
•  WebRTC no muestra la IPv6 p\u00fablica real del ISP;
•  DNS, zona horaria e idioma no presentan conflictos evidentes con la ubicaci\u00f3n del proxy;
•  Las protecciones de error de proxy y cambio de IP est\u00e1n activadas;
•  Proxy bypass no contiene dominios de conexi\u00f3n directa innecesarios;
•  Los resultados de la comprobaci\u00f3n siguen siendo coherentes tras reiniciar el entorno.

Preguntas frecuentes

\u00bfSignifica que hay una fuga si la prueba WebRTC muestra m\u00faltiples IP?

No necesariamente. Los m\u00faltiples resultados pueden provenir de IPv4, IPv6, interfaces de red local, mapeo STUN, retransmisi\u00f3n TURN o mDNS. Solo debe considerarse una fuga de alto riesgo cuando aparezcan IP p\u00fablicas reales del ISP, salidas de red no relacionadas o direcciones p\u00fablicas que entren en conflicto evidente con la ubicaci\u00f3n del proxy.

\u00bfQu\u00e9 IP deber\u00eda mostrar WebRTC tras usar un proxy?

Lo ideal es que la p\u00e1gina web no vea su IP p\u00fablica real del ISP. Seg\u00fan el navegador y la pol\u00edtica del producto, la p\u00e1gina de prueba podr\u00eda mostrar la direcci\u00f3n del proxy, direcciones de retransmisi\u00f3n, candidatos locales ocultos o no mostrar direcciones disponibles. El criterio no es \u00absolo debe aparecer una IP\u00bb, sino \u00abno debe aparecer ninguna salida p\u00fablica real que deba estar aislada\u00bb.

\u00bfDeber\u00eda elegir Private o Disabled en MostLogin?

Cuando se necesita audio/v\u00eddeo web, llamadas de atenci\u00f3n al cliente o uso compartido de pantalla, elija Private como prioridad y vuelva a probar; cuando no se utilicen en absoluto las funciones de WebRTC, puede elegir Disabled. Disabled puede afectar al funcionamiento del sitio web, por lo que no es la soluci\u00f3n \u00f3ptima predeterminada para todos los entornos.

\u00bfPuede una fuga de WebRTC revelar el nombre real y la direcci\u00f3n exacta?

Normalmente, una IP por s\u00ed sola no puede revelar un nombre real o una direcci\u00f3n exacta, pero la IP p\u00fablica puede indicar la regi\u00f3n aproximada y el proveedor, y puede combinarse con cuentas, cookies, huellas digitales del navegador y registros de comportamiento para formar se\u00f1ales de correlaci\u00f3n m\u00e1s s\u00f3lidas.

\u00bfEs suficiente con reparar la configuraci\u00f3n tras una fuga?

La reparaci\u00f3n solo impide una exposici\u00f3n posterior; no puede retirar los datos que el sitio web ya recibi\u00f3. Para negocios importantes, debe verificar el per\u00edodo en que se produjo la fuga, los entornos afectados y los registros de inicio de sesi\u00f3n; si es necesario, cierre las sesiones anteriores, actualice las credenciales y observe si la plataforma presenta verificaciones an\u00f3malas.

Conclusi\u00f3n

El n\u00facleo de las fugas de WebRTC no es \u00absi WebRTC est\u00e1 activado\u00bb, sino si expone direcciones p\u00fablicas reales que no son coherentes con el entorno proxy actual. Tras detectar una anomal\u00eda, debe detener primero las operaciones sensibles y luego completar la comparaci\u00f3n con los tres grupos de datos: IP real, IP del proxy e IP de WebRTC. Los usuarios de MostLogin normalmente pueden resolver el problema verificando la conexi\u00f3n del proxy, seleccionando WebRTC Private, activando la protecci\u00f3n ante fallos del proxy, eliminando reglas de omisi\u00f3n innecesarias y verificando la ruta IPv6.

Incluir la comprobaci\u00f3n de WebRTC en el proceso fijo antes de poner en marcha un nuevo entorno es m\u00e1s fiable que intentar reparar despu\u00e9s de detectar anomal\u00edas en la cuenta. Volver a probar tras cada cambio de proxy, red o versi\u00f3n del cliente garantiza que la salida de red y la huella digital del navegador se mantengan coherentes a largo plazo.