Abres la página de consulta de IP y ves que la dirección ya es la salida esperada, y es fácil creer que toda la configuración está funcionando. En realidad, eso solo demuestra que esa solicitud web utilizó esa dirección. La resolución de dominios, la comunicación WebRTC y las solicitudes IPv6 no necesariamente siguieron la misma ruta.
La clave para determinar si hay una fuga de IP o DNS no es "cuántas direcciones aparecen en la página", sino si alguna información o tráfico salió por una ruta que esperabas proteger. Ver una dirección interna, un DNS público o un nombre de región distinto a la salida no basta por sí solo para concluir que hay una fuga.
Este artículo es útil para revisar tu propio dispositivo, navegador y configuración de red. Los resultados de las pruebas solo representan el entorno observable en ese momento y no deben interpretarse como una garantía de privacidad para todas las aplicaciones del dispositivo.
Primero define qué tráfico quieres proteger
Antes de empezar a probar, responde una pregunta sencilla: ¿qué configuraste: un proxy de navegador, un proxy del sistema o una VPN que gestiona el enrutamiento de red?
Su cobertura puede variar. Una extensión del navegador no necesariamente gestiona otras aplicaciones; un proxy del sistema tampoco garantiza que todos los protocolos sigan la configuración del proxy. Que una VPN cubra IPv6, DNS y tráfico dividido depende también de la implementación y configuración específicas.
Si intencionalmente dejas que una aplicación se conecte directamente, que use la salida original no es necesariamente un fallo. Pero si esperas que "todo el tráfico saliente use la salida designada", el mismo fenómeno requiere más investigación.
Conviene guardar una línea base: la IPv4 e IPv6 públicas sin la configuración objetivo y los resolvedores observables en las pruebas de DNS. La línea base sirve para comparar antes y después; no es necesario publicarla, especialmente en redes corporativas, donde no debes exponer direcciones internas ni capturas de configuración.
WebRTC: primero distingue las direcciones candidatas y luego evalúa si se expone la salida
WebRTC permite a los navegadores realizar comunicaciones de audio, video y datos en tiempo real. Para establecer conexiones, recopila las rutas de red posibles, es decir, los candidatos ICE.
La documentación de MDN sobre tipos de candidatos distingue entre host, srflx, prflx y relay, entre otros. Para un usuario común, lo más importante es diferenciar la información de la interfaz local, la información observada a través de la traducción de direcciones (NAT) y la dirección del servidor de retransmisión. Que los candidatos se expongan a la página web también depende de la política de privacidad de WebRTC del navegador.
Resultado en la prueba | Interpretación más razonable |
|---|---|
IPv4 privadas como 192.168.x.x, 10.x.x.x | Pueden reflejar información de la LAN; no basta para afirmar que se filtró la salida pública |
Nombres .local | Puede ser el tratamiento de privacidad del navegador para candidatos locales, no equivale a la IP pública real |
Dirección pública que coincide con la salida esperada | Coincide con lo esperado en esta prueba, pero no significa que todo el tráfico esté verificado |
Dirección pública confirmada como perteneciente a la red original | Si debería estar protegida, es una señal de exposición que merece verificación |
Dirección de retransmisión TURN | Indica que los candidatos correspondientes pasan por un relay, no prueba directamente la dirección pública original del usuario |
Que WebRTC exponga la dirección de la red original no es una idea infundada. El RFC 8828 analiza la exposición de información de IP en casos de VPN dividida, múltiples interfaces de red y proxies de aplicaciones. Sin embargo, la implementación del navegador, los permisos y las políticas de red afectan el comportamiento real, y no se pueden aplicar directamente las conclusiones de pruebas en navegadores antiguos a todos los dispositivos.
En la Prueba de fugas WebRTC, si ves una dirección pública que no coincide con lo esperado, compárala primero con la línea base y luego verifica a qué red pertenece. No concluyas algo solo porque 'aparezca una segunda dirección', ni equipares directamente 'no se recopilaron candidatos' con seguridad absoluta: si la comunicación está bloqueada o la prueba no se completó, también puede haber un resultado vacío.
DNS: ¿Qué significa ver el resolvedor de tu operador?
Antes de que el navegador acceda a un dominio, normalmente necesita obtener su dirección correspondiente. La fuga de DNS se centra en si este paso se ejecutó según la política de resolución esperada y si alguna parte que no debería tener acceso a la información de la consulta pudo haberla visto.
Las pruebas comunes de fuga de DNS hacen que el navegador solicite un conjunto de dominios de prueba y luego observan el origen de las consultas desde el lado del DNS autoritativo. Lo que muestra la página suele ser el punto de salida en la cadena de resolución recursiva, no una lectura directa de la configuración de DNS de tu dispositivo.
Esto significa que, tras detectar una dirección DNS, no puedes concluir de inmediato que 'el servidor DNS local es ese'. El reenvío recursivo, los servicios de resolución públicos y el despliegue Anycast pueden hacer que el resultado sea más complejo que lo que muestra la interfaz de configuración del sistema.
En particular, no te fijes solo en el nombre del país: la ubicación en la base de datos del punto de salida DNS es diferente de la del punto de salida web y no basta por sí sola para demostrar una fuga. Debes verificar además el operador del resolvedor, la forma de enrutamiento del servicio y si cumple con tus objetivos de configuración.
Si esperas usar únicamente la ruta de resolución especificada por la VPN, pero la prueba observa de manera constante el punto de salida de resolución del operador de red original, es una señal que debes investigar. Si configuraste activamente un DNS público y detectas ese mismo DNS, no necesariamente es una anomalía.
Puedes usar la Prueba de fugas DNS para comparar antes y después. Cuando aparezcan varios resolvedores, revisa primero si existe solapamiento o uso simultáneo entre el 'DNS seguro' del navegador, el DNS del sistema operativo, el DNS de la VPN y la configuración de división de tráfico.
Si activas DoH, ¿ya no habrá fugas?
DoH resuelve el problema del cifrado en el transporte de las consultas DNS, pero no resuelve automáticamente todos los problemas de enrutamiento y confianza. La documentación de Cloudflare explica cómo encapsular las consultas DNS en HTTPS, pero 'transporte cifrado' no equivale a 'la consulta seguramente pasó por la VPN que especificaste'.
El servicio de resolución seguirá procesando tus consultas. Algunas implementaciones pueden usar EDNS Client Subnet para transmitir información del prefijo de red del cliente en consultas recursivas; este mecanismo y sus implicaciones de privacidad se describen en el RFC 7871. Si una prueba DNS común no proporciona explícitamente este resultado, no asumas que ya comprobó ECS.
IPv6: que la salida IPv4 sea correcta no significa que la otra familia de direcciones también lo sea
Muchas redes ofrecen IPv4 e IPv6 simultáneamente. Si un proxy o VPN solo maneja IPv4 y el dispositivo aún puede usar IPv6 directamente a través de la red original, los servicios de destino que admitan IPv6 podrían observar otra ruta de salida.
Sin embargo, 'las direcciones IPv4 e IPv6 son diferentes' es algo normal. Pertenecen a sistemas de direccionamiento distintos, así que no puedes juzgar si la protección está activa comparando si los textos de las direcciones se parecen.
Lo que debes comparar es: la pertenencia de red de ambos protocolos, si el enrutamiento real cumple lo esperado y si IPv6 sigue apuntando a la red original. El cambio de la dirección temporal IPv6 por sí solo tampoco indica automáticamente una fuga.
En la Comprobación del entorno del navegador, revisa por separado la información disponible de IPv4 e IPv6. Si la prueba de IPv6 no se completó, solo puedes marcarla como no confirmada; eso no es lo mismo que 'se confirmó que IPv6 no está disponible'.
Un orden de verificación que puedes repetir
1. Haz una comparación antes y después en el mismo dispositivo y navegador
Registra la información de salida cuando la configuración objetivo está desactivada y vuelve a probar tras activarla. Durante la prueba evita cambiar a la vez la Wi-Fi, el proxy del navegador y el DNS, de lo contrario será difícil saber qué paso causó el cambio.
2. Revisa por separado la web, WebRTC, DNS e IPv6
Anota los cuatro grupos de resultados por separado: la salida pública observada en la web, los candidatos de WebRTC, el origen de las consultas DNS y la accesibilidad y salida de IPv6. No uses el estado verde de un elemento para sustituir a los demás.
3. Localiza la configuración según la ruta anómala
Si WebRTC expone la dirección pública de la red original, revisa la cobertura del proxy, la política de WebRTC y si la VPN usa división de tráfico. Si el DNS no cumple lo esperado, revisa la configuración de resolución del navegador y del sistema, y el comportamiento de recuperación del DNS tras la desconexión de la VPN. Si IPv6 sigue usando la red original, revisa el soporte IPv6 de la VPN y las rutas relacionadas.
Modifica solo una opción relevante cada vez y vuelve a probar. Si necesitas tratar un problema de negocio a largo plazo, guardar la hora, el estado de configuración y un resumen de resultados suele ser más útil para localizar el problema que solo capturar una 'advertencia roja'.
4. Comprueba el comportamiento tras la reconexión
La reconexión de la red, el despertar del dispositivo tras la suspensión y la reconexión de la VPN pueden cambiar la ruta. Si las condiciones lo permiten, vuelve a comprobar después de estos escenarios de uso normal. Pasar la prueba una vez solo demuestra que el comportamiento observado en ese momento cumplía lo esperado, y no reemplaza la verificación de estabilidad posterior.
No desactives todas las funciones como primera medida
Desactivar WebRTC directamente puede afectar las llamadas y reuniones en el navegador; cerrar IPv6 directamente también puede ocultar problemas de configuración. Si hacerlo depende de tus necesidades reales y la pérdida de funcionalidad aceptable, no solo de que la página de prueba muestre menos líneas.
Un enfoque más prudente es definir primero el alcance de la protección y luego corregir la configuración de enrutamiento, resolución o del navegador correspondiente. Los dispositivos corporativos deben seguir las políticas del administrador y no deben omitir por su cuenta la configuración de red y seguridad establecida.
¿La ventana de incógnito puede evitar estas fugas?
No trates el modo incógnito como un túnel de red. Principalmente cambia la forma en que se gestionan los datos locales de sesión, como el historial de navegación y las cookies, y no se encarga por sí mismo del DNS, WebRTC o el enrutamiento IPv6.
Si no se detecta la IP original, ¿significa que hay anonimato total?
No. La ruta de la IP es solo una parte de la privacidad. El inicio de sesión en cuentas, las cookies, la huella digital del navegador y la información que envíes activamente pueden permitir que un servicio identifique o relacione una visita.
Tras completar este conjunto de comprobaciones, la conclusión razonable debería ser: “En la configuración y condiciones de prueba actuales, la ruta de red observada coincide con lo esperado.” Esto es más preciso y más útil para orientar el uso posterior que una frase sin ámbito de aplicación como “cero fugas, anonimato total”.
Escenario de enrutamiento dividido: cómo interpretar cuatro resultados diferentes en el mismo dispositivo
Supón que has configurado el enrutamiento por dominio, o que tienes activados a la vez una VPN y una salida directa local. En una prueba, la salida HTTP muestra la dirección del nodo proxy A, la prueba DNS muestra la dirección del servidor recursivo B, en los candidatos WebRTC aparecen la IP pública C de la red original y una dirección TURN D, y el IPv6 sigue usando la línea del operador. Este tipo de resultados se puede malinterpretar fácilmente como “cuatro fugas totales”. En realidad, es posible que simplemente cada una tenga una ruta distinta. Lo importante no es cuántas IP aparecen, sino si esas rutas coinciden con lo que esperabas.
En este ejemplo, si solo quieres que el tráfico HTTP de las páginas web pase por el proxy, la salida A puede ser conforme a la configuración; si el DNS debe ir directo hay que confirmarlo por separado. Si en los candidatos WebRTC que la página puede leer aparece la IP pública C de la red original, eso ya indica que la página, en esta prueba, puede conocer C, y no hace falta esperar a que la conexión multimedia la use de verdad para considerarlo una exposición. Que sea una fuga contraria a tus necesidades depende de si exiges ocultar esa dirección a la página.
Los candidatos mDNS requieren especial atención. Los navegadores suelen usar nombres .local generados aleatoriamente para representar las interfaces de red locales, evitando exponer directamente la información real de la red local. Si en una página de detección WebRTC ves entradas como “2f8c…local”, debes interpretarlas como un tratamiento de privacidad del candidato local, no como tu IP pública ni tu nombre de host. Tomarlo como prueba de fuga es un error común. Si además aparece la dirección pública de la red original y esa aplicación debería estar protegida por el túnel, entonces sí es una señal de exposición que merece una verificación a fondo.
Registra también los resultados de IPv6 por separado. Si la conexión IPv4 pasa por el proxy A, pero IPv6 sigue usando la conexión directa del operador, un sitio con doble pila puede ver la dirección IPv6 del operador, en paralelo o como vía preferida. Esto no implica necesariamente un error de configuración: muchos clientes que distribuyen el tráfico según prefijos CIDR o que solo envían IPv4 a través del proxy no gestionan las rutas IPv6 de forma predeterminada. Antes de concluir que existe una «fuga IPv6», confirma si la VPN o el proxy ofrece cobertura para IPv6 y comprueba si la ruta IPv6 predeterminada del dispositivo apunta al túnel.
Las diferencias en el servidor DNS recursivo se pueden analizar de forma auxiliar con la información de ASN y RDAP. Si la dirección de B pertenece a un servicio de resolución público que tú designaste expresamente, aunque sea distinta de la salida HTTP, es un fenómeno normal; si pertenece al operador de la red original y tú querías que el tráfico de resolución entrara en el túnel, entonces es una anomalía que hay que investigar. Los servicios de resolución desplegados con Anycast pueden mostrar nodos distintos según la región, por lo que no se puede concluir que el DNS va directo solo por el cambio de ubicación geográfica. Hay que fijarse en el nombre del operador, la pertenencia del ASN y si el dominio de prueba observa en el lado autoritativo orígenes de consulta no esperados.
Ante esta coexistencia de múltiples salidas, lo primero no es desactivar funciones, sino anotar las “expectativas”. Qué aplicaciones deben ir por el proxy y cuáles directas; quién debe gestionar el DNS; si el IPv6 debe estar cubierto por el túnel o se permite directo; y si WebRTC puede recoger candidatos locales cuando la VPN está activa. Después de completar una medición, compárala con la línea base. Si descubres que algún punto no coincide con lo esperado, vuelve a los ajustes concretos y modifícalos uno a uno. Cambia solo una variable cada vez, por ejemplo primero el DNS y luego repite la prueba, para poder determinar qué regla causó la diferencia.
Mediciones repetidas y recuperación tras desconexión: que los resultados resistan una nueva verificación
Que una prueba pase solo significa que el entorno de ese momento coincidía con lo esperado. La reconexión de la VPN, el despertar del sistema o los cambios de permisos del navegador pueden alterar la ruta. Se recomienda repetir la medición después de escenarios de uso normal: desconecta y vuelve a conectar la VPN, suspende y reanuda el equipo, cambia entre Wi-Fi y red móvil, y en cada caso revisa la salida HTTP, el origen del DNS, los candidatos WebRTC y el estado IPv6. La estabilidad de esos cuatro resultados es más valiosa que un único “todo verde”.
En cada medición mantén solo una variable cambiante. Por ejemplo, si hoy solo modificas ajustes relacionados con WebRTC, deja sin cambios el DNS y la VPN; mañana cambia solo el IPv6 y vuelve a probar los cuatro puntos. Si ajustas a la vez el “DNS seguro” del navegador, el enrutamiento dividido del proxy y el interruptor IPv6 del sistema, y aparecen resultados intermitentes, será muy difícil rastrear qué cambio lo causó. Registrar la hora, el estado de la configuración y un resumen del resultado es más útil para el mantenimiento a largo plazo que una captura de pantalla con una advertencia roja.
Los permisos del navegador afectan directamente a los candidatos WebRTC. Si el sitio no tiene permiso de micrófono o cámara, el navegador puede no recoger candidatos de la interfaz local; en cuanto se autoriza el audio o el vídeo, el alcance de recogida de candidatos puede ampliarse. Por eso hay que probar WebRTC antes y después de conceder permisos para observar los cambios en la lista de candidatos. No creas que no existe una vía de exposición WebRTC solo porque la página no muestre candidatos cuando no se han concedido permisos; eso es confundir “no medido” con “ya protegido”. Del mismo modo, la ventana de incógnito no cambia el enrutamiento de red y no puede considerarse una medida contra fugas.
El IPv6 debe tratarse de forma explícita según las necesidades: si se quiere una protección completa de doble pila, elige y configura un túnel que soporte IPv6 y verifica el enrutamiento real y el cortafuegos; si el producto solo admite IPv4, confirma qué política de bloqueo o derivación tiene para IPv6. Añadir una sola ruta por defecto no garantiza que todas las aplicaciones y el estado de desconexión estén protegidos. Desactivar globalmente el IPv6 también puede afectar a la compatibilidad; primero hay que entender las capacidades del cliente y conservar una configuración recuperable, y luego verificar por separado los estados normal, de reconexión y de desconexión.
La aceptación de la recuperación tras desconexión debe incluir la política de “kill switch”. Si una VPN afirma bloquear todo el tráfico saliente tras la desconexión, hay que comprobar que las consultas DNS también fallen durante la interrupción de red, en lugar de volver al resolvedor de la red original. Algunas implementaciones solo cortan el TCP IPv4, pero permiten que el IPv6 o el DNS sigan usando la línea original; esa “protección parcial” deja una ventana de observación. Se puede confirmar provocando por separado eventos de desconexión y observando el comportamiento de las peticiones HTTP, DNS e IPv6.
Un “no encontrado” en los resultados de la prueba no equivale a “seguro”. Si el IPv6 aparece como no conectable porque la red no lo soporta, solo se puede marcar como “no confirmado”, no interpretarlo como “confirmado sin fuga IPv6”. Una ruta solo puede considerarse verificada en esta prueba cuando la prueba se ha emitido y el resultado coincide con lo esperado. Cada medición debe indicar las condiciones de la prueba, como la versión del navegador, el modo de proxy, el protocolo VPN y el entorno de red, para facilitar la reproducción posterior.
En entornos más complejos, como CGNAT, puede cambiar la correspondencia entre la salida pública y la dirección interna; en ese caso, puedes consultar Cómo saber tu IP pública y comprobar si tienes CGNAT para conocer los niveles de NAT. Algunas herramientas de seguridad pueden informar erróneamente fenómenos normales como características de VPN o proxy; puedes consultar Tu IP aparece como VPN o proxy: cómo revisar un falso positivo para interpretar mejor los resultados de la herramienta. Combinando estos materiales, reducirás los errores de juicio debidos al tipo de dirección o a la lógica de detección.
Finalmente, organiza los resultados de la investigación en un registro de aceptación: si la ruta esperada es clara, si cada tipo de tráfico se comporta según lo esperado en los estados normal, de reconexión y de desconexión, y si los elementos anómalos se han localizado en configuraciones específicas. La conclusión así obtenida —"en las condiciones actuales y el alcance de la prueba, la ruta de red observada cumple con lo esperado"— tiene más valor que cualquier marca verde puntual.
