Menú

Inicio

Todas las páginas

Apariencia

Ubicación:🇺🇸 Estados Unidos
Sitio principal gistwillan.top
Volver al blog
Fugas · 4 min

Dos pruebas de fuga que todos deberíamos hacer: WebRTC y DNS

Una VPN puede ocultar tu dirección y dejar dos puertas abiertas. Ambas se miden en el navegador y casi siempre están mal configuradas.

Conector RJ45 conectado con la luz de enlace encendida
Someone's Moving Castle · CC BY-SA 3.0 Wikimedia Commons

Se habla de "fuga de IP" como si fuera un solo fallo. Son al menos dos, en capas distintas, con arreglos distintos. Puedes cerrar uno por completo y seguir expuesto por el otro, y que tu navegador muestre la dirección de la VPN en una página de prueba no demuestra nada sobre ninguno de los dos.

Dos puertas que un navegador deja abiertas
Ambas deben coincidir para decir "sin fuga evidente"; limpio no significa no identificable.

1. Primero decide qué observador te importa

Toda pregunta sobre fugas es en realidad "quién se entera de qué". El sitio que visitas conoce la dirección que llega hasta él. Tu red local conoce qué nombres resuelves. La pila de red del navegador conoce tus direcciones locales y se las contará encantada a un par. Una VPN promete cambiar lo primero; no dice nada de lo segundo ni de lo tercero salvo que esté configurada para ello.

2. WebRTC: el navegador entrega direcciones a los pares

WebRTC existe para que dos navegadores se conecten directamente y transmitan audio, vídeo y datos. Para eso reúne candidatos ICE —direcciones locales y direcciones públicas descubiertas por STUN— y se los envía al otro extremo. Si tu cliente VPN no enruta ese tráfico por el túnel, la petición STUN sale por tu red física y la lista de candidatos contiene tu dirección pública real. El sitio puede leer esa lista desde JavaScript sin pedir permiso.

La firma es simple: una dirección distinta de la que el sitio reportó para tu petición HTTP, o un rango privado como 192.168.x.x junto a una pública. Lo primero significa que el tráfico web va por el túnel y WebRTC no. Lo segundo no filtra nada a internet por sí mismo, pero confirma que la recogida de candidatos no está restringida.

3. DNS: tu resolutor conoce cada sitio que abres

Antes de cualquier conexión, un nombre tiene que convertirse en dirección. Esa consulta suele salir de tu máquina en claro hacia el resolutor que eligió el sistema operativo, y la forma de elegir es un lío de opciones DHCP, ajustes por interfaz, systemd-resolved, scripts del cliente VPN y DoH del navegador. El que gana rara vez es el que el usuario pretendía.

La prueba honesta tiene que ser más lista que "preguntar a un sitio": pide un nombre único y haz que el servidor autoritativo registre qué resolutor consultó en tu nombre. Esa dirección, y la red que la opera, es la única respuesta fiable. Un resolutor en el mismo país que tu IP de salida y del mismo proveedor es normal en conexión directa. Uno en otro país significa que tu tráfico sale por un sitio y tus consultas por otro: la definición de fuga de DNS.

4. Leer ambos resultados juntos

  • IP de salida y resolutor en el mismo país, ambos del ISP: sin VPN, sin fugas, todo como se espera.
  • IP de salida en el extranjero, resolutor todavía en casa: la VPN enruta el tráfico pero no el DNS. La mala configuración más común.
  • Salida y resolutor en el extranjero pero de proveedores distintos: no es una fuga, pero tus dos rutas van por caminos diferentes, y el resolutor lo ve todo aunque la VPN no.
  • Resolutor de Cloudflare, Google o Quad9: hay DNS cifrado. Tu ISP ya no ve las consultas; esa empresa sí, y las ve todas.

5. Arreglarlo sin romper nada

Para WebRTC, la solución fiable es un cliente VPN con enrutado de túnel completo y kill switch que cubra UDP, no solo TCP. Desactivar WebRTC funciona —Firefox expone media.peerconnection.enabled en about:config— pero rompe las videollamadas legítimas, así que casi todo el mundo debería preferir un cliente que proxifique STUN por el túnel antes que apagar la función.

Para DNS, impón el resolutor a nivel de túnel y verifícalo, porque un ajuste del navegador o del sistema puede anular tu intención en silencio. Si el cliente VPN tiene un interruptor de "protección contra fugas DNS", ese interruptor está haciendo el trabajo que debería hacer tu configuración; vuelve a probar tras cada actualización, porque las rutas se reescriben. En redes que controlas, monta tu propio resolutor, repártelo por DHCP y apunta su upstream por DoT.

6. Lo que ninguna de las dos pruebas mide

Ninguna mide si eres identificable. Tu huella TLS, las fuentes instaladas, la zona horaria, el tamaño de pantalla y tu forma de escribir siguen siendo tuyos, y un proxy no cambia ninguno. Una prueba de fugas limpia significa que las puertas obvias están cerradas, no que la habitación esté vacía.

ipbox.one ejecuta ambas comprobaciones en la página de inicio: los candidatos WebRTC que expone tu navegador y el resolutor que respondió de verdad, junto a la dirección que vio Cloudflare, para compararlos de un vistazo en lugar de deducirlos.

Sigue leyendo