Esta página compara dos señales que deberían coincidir cuando una VPN funciona como se espera: la dirección IPv4 que nuestro controlador HTTPS ve en /api/ip y los extremos públicos servidor-reflexivo (srflx) que su navegador descubre al realizar una recopilación ICE rápida de WebRTC contra el grupo público STUN de Google (normalmente stun.l.google.com:19302). Añadí esta doble verificación después de que un amigo que usaba una VPN comercial muy conocida viera Londres en todos los sitios web de "cuál es mi IP" y, sin embargo, siguiera filtrando su ASN residencial en una videollamada porque el tráfico UDP a STUN salía fuera del túnel, mientras que el tráfico TCP a los sitios web permanecía dentro. A continuación, explico cómo sucede esto, cómo es un resultado limpio y por qué ninguna pestaña del navegador puede sustituir por completo a un entorno nativo de prueba de fugas de DNS.
Qué comprueba esta herramienta (y qué no puede demostrar)
La fila Línea base HTTP refleja la dirección del cliente que Cloudflare reenvía a nuestro origen (a través de CF-Connecting-IP o equivalente). Esa es la dirección que observan los sistemas de contabilidad, puntuación de fraude y la mayoría de los sitios web para las cargas de página normales sobre TLS. La lista WebRTC srflx recopila las direcciones IPv4 analizadas a partir de candidatos ICE cuyo tipo es srflx, lo que significa que el servidor STUN vio llegar su paquete UDP desde ese extremo público. Cuando ambas rutas utilizan la misma salida de VPN, las direcciones deberían coincidir dentro de cada familia de versiones de IP.
Esta es una heurística, no una certificación. El malware, las reglas de túnel dividido que solo enumeran ciertos ejecutables, los portales cautivos o las fugas exclusivas de IPv6 fuera del túnel pueden producir casos dudosos que la interfaz de usuario etiqueta como inconcluyentes en lugar de un aprobado o suspenso binario. Trate el resultado como una tarea de diagnóstico: si hay discrepancias, realice pruebas con el software nativo de su proveedor de VPN y capture paquetes antes de reportar un error a la VPN.
En qué se diferencian las fugas de WebRTC de las cargas de página habituales
La negociación WebRTC utiliza el algoritmo Establecimiento de Conectividad Interactiva (ICE) definido en RFC 8445. Parte de ICE implica enviar solicitudes de vinculación STUN definidas en RFC 5389 para que los extremos conozcan las direcciones reflexivas a través de NAT. Los navegadores también envían nombres de host mDNS para proteger la privacidad en redes locales; cuando estos están activos, puede ver nombres opacos del tipo .local hasta que lleguen los candidatos srflx. Si su VPN enruta el tráfico web TCP a través del túnel pero deja que UDP recurra a su ISP debido a la falta de una regla en el cortafuegos, srflx puede exponer la dirección de su ISP aunque HTTPS siga mostrando la VPN. Ese es el patrón clásico de fuga de WebRTC del que advierten las guías de privacidad.
Los navegadores modernos continúan reforzando las configuraciones predeterminadas (interfaces silenciadas, solicitud de gestos de usuario para el acceso a la cámara, limitación de candidatos de host), pero la tecnología ICE aún necesita datos reflexivos para funcionar. La solución rara vez es "desactivar WebRTC de forma global", sino enrutar UDP a través de la misma interfaz que TCP o utilizar un cliente VPN que instale un controlador de kernel capaz de capturar todos los protocolos IP.
Fugas de DNS: por qué el navegador no puede verlo todo
Una fuga de DNS significa que las consultas para resolver nombres de dominio se realizan a través de un resolvedor que su VPN no pretendía utilizar (normalmente el de su ISP), mientras que el tráfico cifrado sigue saliendo por la IP de la VPN. Una detección completa suele utilizar subdominios únicos para que un servidor autorizado pueda registrar qué resolvedor realizó la consulta. El JavaScript común de un mismo origen no puede enumerar cada socket de su sistema operativo ni las configuraciones divididas de resolvedores locales. Por eso, este sitio le sugiere utilizar la herramienta ¿Cuál es mi DNS? para búsquedas DoH intencionadas y resolvedores nativos de fugas para obtener respuestas definitivas.
IPv6 sube la apuesta: si su VPN solo tuneliza IPv4 pero su sistema operativo prefiere IPv6 para ciertos destinos, las consultas AAAA y las conexiones TCP posteriores pueden eludir el túnel por completo. La solución suele ser "habilitar IPv6 dentro de la VPN" o "bloquear IPv6 en el cliente hasta que el proveedor ofrezca salidas de pila doble", en lugar de realizar cambios a ciegas en el navegador.
Cómo es un resultado correcto
Espere que la IP de HTTPS y cada dirección IPv4 de srflx coincidan con el rango de salida anunciado por su proveedor de VPN. Espere que las respuestas de DNS (cuando las pruebe intencionadamente) provengan de los nombres de host del resolvedor de su proveedor, no de la marca de su ISP. Espere que WebRTC no muestre ningún srflx dentro del tiempo de espera de recopilación (NAT estricto) o que muestre direcciones srflx que coincidan con la VPN. Las discrepancias merecen capturas de pantalla para el soporte: incluya la marca de tiempo, la ciudad seleccionada y si el túnel dividido está habilitado para "aplicaciones de trabajo".
Soluciones que sobreviven a un reinicio
Comience con el cliente VPN: active el interruptor de apagado (kill switch), desactive el túnel dividido para el navegador con el que realiza las pruebas y active el bloqueo de DNS del proveedor si se ofrece. En Firefox, los usuarios avanzados inspeccionan las claves de about:config como media.peerconnection.ice.default_address_only y parámetros relacionados, pero es preferible seguir las guías del proveedor porque las claves exactas cambian entre versiones. En Windows, verifique que la métrica del adaptador virtual de la VPN sea inferior a la del adaptador Wi-Fi para que las rutas predeterminadas se apliquen correctamente.
Ejemplo de diagnóstico en Firefox (solo lectura; modifique valores únicamente si comprende sus efectos):
about:webrtc
about:networking#dnsLa primera página resume las sesiones activas; la segunda enumera las entradas de caché de DNS visibles para el navegador, lo que ayuda al depurar portales cautivos o registros SRV obsoletos.
Promesas comerciales frente a lo que realmente puede verificar
La política de "no registrar datos" no se puede observar desde el exterior; es una promesa legal y operativa. La jurisdicción importa porque las citaciones judiciales siguen el domicilio social de la empresa. Los servidores que funcionan solo en memoria RAM reducen los residuos forenses, pero no cambian el enrutamiento lógico. Lo que sí puede verificar en casa es la exactitud de las rutas (esta página), la elección del resolvedor (herramienta de DNS), si se cubre IPv6 y si el interruptor de apagado bloquea el tráfico al forzar el cierre del proceso de la VPN. Incluya estas verificaciones en sus rutinas habituales de la misma manera que comprueba los detectores de humo.
Comparativa de tipos de fugas
| Tipo de fuga | Qué se expone | Causa común | Solución práctica |
|---|---|---|---|
| WebRTC / ICE srflx | IPv4/IPv6 pública fuera de la VPN | UDP no enrutado en el túnel; servicio auxiliar de cortafuegos desactivado | Controlador de kernel de VPN; desactivar túnel dividido; actualización del proveedor |
| DNS | Nombres de host visibles para el resolvedor del ISP | El sistema operativo sigue prefiriendo DNS por DHCP; el DNS de la VPN no está configurado como prioritario | Bloqueo de DNS; establecer DoT/DoH exclusivo en la interfaz de la VPN |
| IPv6 | La ruta nativa IPv6 elude el túnel exclusivo IPv4 | El túnel carece de v6; el sistema operativo prefiere registros AAAA | Habilitar la salida dual-stack; o bloquear v6 en el sistema operativo hasta que se solucione |
| Correlación de tráfico | Metadatos de tiempo y volumen de tráfico | Adversario pasivo global presente en ambos extremos de la VPN | Tor o redes de mezcla de mayor latencia; aceptar el impacto en la velocidad |
| Fallo del interruptor de apagado | Ráfagas de tráfico en texto claro durante la reconexión | Cierre inesperado del cliente; conflicto de suspensión/activación; rutas personalizadas | Habilitar reglas de bloqueo a nivel del sistema operativo; realizar pruebas con ping durante la reconexión |
Preguntas frecuentes
¿Qué es una fuga de WebRTC?
Es cualquier caso en el que la tecnología WebRTC ICE revela una IP pública o ruta UDP que difiere de la dirección utilizada por su tráfico HTTPS enrutado. Los candidatos srflx provienen directamente de STUN; de modo que si STUN ve a su ISP mientras el sitio web ve su VPN, su navegador está enrutando de forma dividida en la capa de protocolo.
¿Cómo sé si mi VPN está funcionando realmente?
Realice tres comprobaciones independientes: la IP HTTPS (este sitio), la comparación srflx (esta página) y una prueba de DNS específica del resolvedor (nuestra herramienta de DNS o el panel de su proveedor). Si las tres coinciden en el proveedor de VPN, tiene pruebas sólidas de que la ruta predeterminada se ha desplazado. Si alguna discrepa, examine los registros antes de asumir que la VPN está rota.
¿Por qué mi VPN filtra el DNS?
Porque los sistemas operativos resuelven nombres antes o al mismo tiempo que se establece el túnel, y algunas VPN solo copian rutas para subredes IPv4. Los servidores DNS provistos por DHCP permanecen activos en systemd-resolved, NetworkManager o en las métricas de interfaz de Windows a menos que la VPN configure servidores de reemplazo y aumente la prioridad de la interfaz.
¿Debería desactivar IPv6 para mi VPN?
Trate la desactivación de IPv6 como un paso temporal de diagnóstico, no como un hábito permanente. La solución correcta es una VPN que tunelice ambas familias de direcciones o una configuración del sistema operativo que bloquee AAAA hasta que existan salidas de pila doble. Desactivar IPv6 de forma global puede interferir con sitios web modernos y complicar la resolución de problemas.
¿Filtran más las VPN gratuitas que las de pago?
El precio no es la variable clave; lo es la calidad del desarrollo. Algunas opciones gratuitas son versiones adaptadas de redes de pago con configuraciones agresivas; otras se monetizan registrando y vendiendo sus datos DNS, lo cual es peor que una fuga de enrutamiento visible. Analice el modelo de amenaza: una VPN de navegador gratuita que solo funciona como proxy para el tráfico de la pestaña nunca se comportará como un túnel para todo el sistema, por muy atractiva que sea su interfaz.
Herramientas relacionadas
La identidad básica sin WebRTC está en ¿Cuál es mi IP?. Las etiquetas de ASN y organización están en ¿Cuál es mi ISP?. El comportamiento del resolvedor se encuentra en ¿Cuál es mi DNS?. Para comprobar el RTT a este nodo de red después de cambiar de servidor, ejecute ¿Cuál es mi latencia?.
Fuentes citadas anteriormente
- RFC 5389: Utilidades de cruce de sesión para NAT (STUN)
- RFC 8445: Establecimiento de conectividad interactiva (ICE)
- W3C WebRTC: API del navegador
- RFC 4787: Requisitos de comportamiento de traducción de direcciones de red