Explicación de la prueba de fuga de VPN — WebRTC vs DNS vs IP (Lo que las páginas web pueden ver)

Una fuga de VPN es frustrante porque rompe la expectativa de que todo el tráfico salga mágicamente por otro lugar bajo una sola dirección IP. En la práctica, las fugas se dividen en tres categorías sobre las que los analistas discuten constantemente: la visibilidad de la IP en transportes HTTP, las rutas UDP expuestas a través de WebRTC ICE y las búsquedas DNS que eluden el resolvedor del túnel. Saber qué pueden diagnosticar las páginas ordinarias te ayuda a priorizar tus esfuerzos: el JavaScript del navegador destaca en señales HTTPS e ICE, pero tiene dificultades con las pruebas de DNS autoritativas.

Tu navegador muestra rutinariamente la dirección que ven los servidores durante las peticiones conectadas por TLS. Ese dato, a veces complementado con encabezados de CDN, es la columna vertebral de los widgets genéricos de "¿cuál es mi IP?".

Qué recopila WebRTC y por qué es importante srflx

Las conexiones entre pares (peer connections) negocian rutas de medios o datos utilizando el Establecimiento de Conectividad Interactiva (ICE). Cada candidato es una ruta potencial: direcciones del host local o privadas (host), resultados reflexivos de NAT simétrico por la interacción con STUN (srflx), superposiciones de retransmisión a través de TURN (relay) y rutas visibles del par aprendidas (prflx).

Las líneas srflx son importantes para la búsqueda de fugas porque construirlas envía sondas UDP a una infraestructura STUN cooperativa. Los valores de IP reflexiva deberían alinearse con el endpoint público que tu NAT ascendente (o túnel) expone para UDP saliente — que no es necesariamente idéntico al de la dirección visible por TCP en HTTPS, especialmente cuando los routers tratan las pilas de forma diferente —, pero las grandes divergencias ameritan inspección.

Los navegadores modernos exponen progresivamente contenedores de candidatos tipados; las cadenas SDP siguen siendo la alternativa de compatibilidad (marcador typ srflx más IPv4 incrustada). Los fragmentos SDP que contienen IPv6 pueden ser más difíciles de identificar sin un análisis más completo; combina la comparación automática con los conjuntos de pruebas de fugas de los proveedores cuando la ambigüedad de IPv6 sea importante.

Heurística práctica de comparación

Ejecuta una recopilación breve de ICE junto con la línea base de HTTPS:

Fugas de DNS: la brecha de infraestructura

Históricamente, las fugas de DNS significaban que "el resolvedor de mi ISP seguía consultando a servidores autoritativos para obtener nombres de host del túnel". Probar la identidad del resolvedor requiere etiquetas únicas delegadas en dominios de medición, algo que las páginas pasivas no pueden inventar mágicamente sin la cooperación de operadores de DNS.

Las directrices responsables siguen siendo importantes: exige interruptores de bloqueo de DNS / resolvedor exclusivo en tu VPN, mantén una buena higiene en el cortafuegos para la salida 53/tcp/udp, audita las opciones de DHCP, revisa capturas de systemd-resolved (Linux) y evita exclusiones de túnel dividido que dejen accidentalmente a Slack o las actualizaciones del navegador en texto plano.

No obstante, las herramientas basadas únicamente en el navegador pueden enseñar búsquedas de DNS sobre HTTPS controladas para que compares conscientemente las respuestas visibles del resolvedor; por ejemplo, utilizando nuestra página complementaria ¿Cuál es mi DNS? después de configurar DoH deliberadamente. Ese flujo instructivo es independiente de una certificación exhaustiva de fugas.

Por qué los interruptores de apagado (kill switches) complementan las sondas de JavaScript

Los interruptores de apagado a nivel de sistema operativo cortan la salida que no es de VPN cuando los túneles caen, cerrando ventanas de oportunidad donde el DNS o el tráfico UDP perdido se escapan. Los scripts no pueden modificar las tablas de enrutamiento del host; combinar las comprobaciones de interfaz automatizadas con los probadores nativos del proveedor sigue siendo la mejor práctica en el modelado de amenazas, no solo la comodidad para el usuario.

Fragmento de código: estructura mínima de ICE (educativo)

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }],
});
pc.createDataChannel("probe");
pc.onicecandidate = (evt) => {
  const cand = evt.candidate;
  if (!cand) return;
  console.log(cand.type, cand.candidate ?? cand.address);
};
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

El código de producción añade temporizadores delimitados, alternativas de SDP cuando se omite address, protecciones de concurrencia, textos de privacidad concisos y un lenguaje calibrado ("posible señal" en lugar de un aprobado/reprobado binario).

Cuando una marca de verificación verde sigue mintiendo

El NAT simétrico a veces produce ningún srflx en unos pocos segundos a pesar de que tu VPN está funcionando correctamente; la ausencia de datos ICE es inconcluyente, no una prueba de seguridad. Las empresas pueden usar proxies para HTTPS mientras dejan UDP libre, lo que distorsiona las comparaciones a menos que controles la política. Las rutas IPv6 pueden divergir de IPv4; si tu cliente VPN maneja solo una familia, debes inspeccionar ambas explícitamente.

Las exclusiones del túnel dividido (juegos, videoconferencias, IP de SaaS corporativos) se enrutan a propósito fuera del túnel; llamar a eso un "fallo" ignora la intención. Los lectores deben correlacionar los hallazgos del navegador con el panel de la VPN, los registros del cortafuegos o las capturas de paquetes cuando lo que está en juego es importante (periodismo, asuntos legales, acceso remoto regulado).

Los identificadores del navegador (fingerprinters) enlazan pistas de IP con señales no relacionadas (WebGL, fuentes, audio), por lo que reforzar WebRTC por sí solo no elimina el riesgo de seguimiento. Combina las comprobaciones de fugas con las guías de protección del navegador y los hábitos de la era HTTPS Everywhere (hoy en día mayormente predeterminados).

Abre ¿Cuál es mi VPN / Tengo fugas? para una comparación inmediata de HTTPS vs WebRTC en este dominio, navega por ¿Cuál es mi IP? / ¿Cuál es mi ISP? / ¿Cuál es mi latencia? / Prueba de velocidad de internet para el contexto de transporte, y utiliza ¿Cuál es mi DNS? cuando desees realizar consultas directas al resolvedor; teniendo en cuenta que la identidad de tu DNS aún requiere herramientas nativas de VPN para pruebas autoritativas.