Guías

Kill switch y fugas: DNS, WebRTC, IPv6

Un kill switch bloquea todo el tráfico de internet en el instante en que el túnel VPN se cae, para que las apps no puedan volver en silencio a tu conexión normal. Sin él, hasta una desconexión de dos segundos expone tu IP real. E incluso con el túnel activo, las consultas DNS, el WebRTC del navegador y el tráfico IPv6 pueden escapársele. Cada fuga tiene una prueba sencilla y un arreglo.

🛡️

Un túnel caído falla en abierto

Cuando la conexión VPN se rompe, el sistema operativo enruta el tráfico sin decir nada por la interfaz normal. Las apps siguen funcionando y nada te avisa. Un kill switch convierte el fallo abierto en fallo cerrado: sin túnel, no hay tráfico.

🌍

Hay fugas con el túnel activo

Las consultas DNS pueden ir al resolutor de tu operadora por fuera del túnel, WebRTC puede entregar tus direcciones a las webs, e IPv6 puede saltarse un túnel solo-IPv4 — todo mientras el icono de la VPN dice «conectado».

🔑

Toda fuga se puede probar

No tienes que fiarte de las pantallas de ajustes. Un test de fugas muestra qué direcciones y resolutores ven de verdad las webs, y romper el túnel a propósito muestra si el kill switch aguanta.

Qué pasa en el momento en que el túnel se cae

La conexión falla en abierto. Una VPN añade rutas que dirigen el tráfico a una interfaz de red virtual. Cuando el proceso del túnel muere o caduca, esas rutas desaparecen, mientras que la ruta por defecto por Wi-Fi o Ethernet permanece — así que el sistema sigue entregando paquetes, ahora directamente por tu operadora. Las apps reconectan sus sockets en segundos, enviando tráfico desde tu IP real, sin ningún cuadro de error en ninguna parte.

Las caídas son rutina. Pasar del Wi-Fi a los datos móviles, un portátil que despierta de la suspensión, una red de hotel caprichosa o el reinicio de un servidor VPN rompen el túnel por un momento. Lo que cueste ese momento depende de si algo tiene permiso para salir de tu dispositivo mientras el túnel está caído.

Qué hace realmente un kill switch

Un kill switch es un conjunto de reglas de cortafuegos, no magia. La versión estricta solo permite dos tipos de tráfico saliente: los paquetes que entran a la interfaz del túnel y los paquetes cifrados del propio cliente VPN hacia el servidor. Si el túnel se cae, el tráfico de las aplicaciones sencillamente no tiene adónde ir hasta que vuelva.

Esto cambia el modo de fallo, no evita los fallos. Con kill switch, una caída se convierte en una conexión en pausa que notas; sin él, en tráfico desde tu dirección real que no notas. Las redes son imperfectas y el túnel se romperá igualmente — el fallo cerrado hace inofensivos esos momentos.

Kill switch del sistema o dentro de la app

La diferencia está en qué pasa cuando muere la propia app. Un kill switch dentro de la app es código del cliente VPN que vigila el túnel y bloquea el tráfico cuando cae. Solo funciona mientras el cliente corre: si el cliente se cuelga o lo mata un optimizador de batería, su protección muere con él — justo en el momento en que el túnel desaparece.

Un kill switch a nivel de sistema instala reglas en el cortafuegos del propio sistema operativo, que inspecciona cada paquete saliente corran las apps que corran. Android lo trae de serie: VPN siempre activa más bloquear conexiones sin VPN hace que el propio sistema rechace el tráfico fuera del túnel, incluso antes de que la app arranque tras un reinicio. La forma bruta de distinguirlos: fuerza el cierre de la app de VPN mientras navegas — si las páginas siguen cargando, el interruptor vive en la app.

Fugas DNS: consultas que se saltan el túnel

Una fuga DNS significa que tus resoluciones de nombres van al resolutor que asignó tu red local — normalmente el de tu operadora —, aunque el tráfico en sí viaje por el túnel. Las webs ven la dirección de la VPN, pero el resolutor recibe el nombre de cada sitio que abres, lo que equivale a un registro de navegación. Windows es el infractor clásico: con varias interfaces activas puede consultarlas todas en paralelo y quedarse con la que responda primero.

El arreglo tiene dos partes, y un buen cliente hace ambas: apuntar el sistema al resolutor de dentro del túnel y bloquear el DNS en todas las demás interfaces, para que una consulta extraviada no tenga adónde ir. Luego verifica: pasa un test de fugas y mira los resolutores que lista — si alguno pertenece a tu operadora, las consultas se están fugando.

Fugas WebRTC: el navegador regala direcciones

WebRTC es la tecnología del navegador detrás de las videollamadas, y cualquier web puede invocarla con unas líneas de JavaScript. Para montar conexiones directas recopila todas las direcciones por las que se podría llegar a tu máquina: las locales y, preguntando a un servidor STUN, la pública. Una página puede leer esos candidatos sin que intervengas.

Con un túnel de dispositivo completo, la petición STUN viaja dentro del túnel, así que descubre la dirección de la VPN. Los montajes peligrosos son los parciales: un proxy solo de navegador o un split tunneling que deja el navegador fuera — ahí los paquetes UDP de WebRTC salen directos y revelan tu IP real.

Pruébalo en vez de razonarlo: nuestro comprobador gratuito en /webrtc-leak-test/ muestra qué direcciones revela tu navegador ahora mismo. Si aparece la real, pásate a un túnel de dispositivo completo o desactiva WebRTC en los ajustes del navegador.

Fugas IPv6: el túnel solo cubre IPv4

Muchas configuraciones VPN transportan solo IPv4. Si tu operadora también da IPv6 — la mayoría de las redes móviles lo hacen —, el sistema conserva una ruta IPv6 funcional fuera del túnel, y los sistemas modernos prefieren IPv6 cuando un sitio ofrece ambos. El resultado es una exposición selectiva: los sitios sin IPv6 ven la dirección de la VPN, los que lo tienen ven la tuya real, y un test solo-IPv4 dice que todo está bien.

Hay dos arreglos limpios. El mejor es una VPN que maneje IPv6 como es debido — tunelizándolo junto al IPv4 o instalando una ruta de bloqueo para que los paquetes IPv6 se descarten en vez de salir directos. El recurso bruto es desactivar IPv6 en el dispositivo o el router. En cualquier caso, verifica: el test de fugas no debe mostrar ninguna dirección IPv6 que no sea de la VPN.

Cómo probar tu montaje como es debido

Haz las comprobaciones en las condiciones en que usas la VPN de verdad — el Wi-Fi de casa, el móvil con datos, la red de una cafetería —, porque las fugas dependen de la configuración DNS y la disponibilidad de IPv6 de cada red. La rutina lleva unos cinco minutos:

  • Apunta tu IP real con la VPN apagada, conecta y confirma que las direcciones visibles IPv4 e IPv6 han cambiado — nuestro /data-leak-checker/ muestra IP, resolutores DNS y WebRTC de una pasada
  • Revisa la lista de resolutores: todos los servidores DNS mostrados deben ser de la VPN, ninguno de tu operadora
  • Rompe el túnel a propósito — apaga el Wi-Fi o fuerza el cierre de la app — y mira si las páginas cargan antes de que reconecte
  • Repite tras actualizar el sistema o la app de VPN, porque ambos pueden resetear en silencio los ajustes de red

Preguntas habituales

¿Necesito un kill switch si mi conexión es estable?
Sí — las caídas que importan son las que no anticipas: despertar el portátil, cambiar entre Wi-Fi y datos móviles, un reinicio del lado del servidor. La estabilidad reduce cuántas veces se rompe el túnel, no lo que pasa cuando se rompe. El interruptor no cuesta nada mientras el túnel está activo y solo actúa ante el fallo.
¿Por qué el test de fugas muestra la IP de mi VPN pero los DNS de mi operadora?
Eso es la fuga DNS clásica: el tráfico va por el túnel, pero las resoluciones de nombres siguen yendo al resolutor que asignó tu red local. O el cliente no consiguió sobrescribir el resolutor del sistema, o el sistema consulta varias interfaces en paralelo. Activa la protección DNS del cliente, reconecta y vuelve a probar.
¿Puede WebRTC filtrar mi dirección incluso con la VPN conectada?
Con un túnel de dispositivo completo, en general no: el tráfico de descubrimiento de WebRTC viaja dentro del túnel y encuentra la dirección de la VPN. Las fugas aparecen en montajes parciales: proxies de navegador, extensiones o split tunneling que deja el navegador fuera. Un test de WebRTC lo zanja en segundos.
¿Y si desactivo IPv6 del todo?
Funciona como arreglo bruto, y en redes donde tu VPN no sabe manejar IPv6 es la opción pragmática: prácticamente todos los servicios siguen siendo accesibles por IPv4. La respuesta más limpia es una VPN que tunelice o bloquee IPv6 por sí misma, manteniendo la protección sin retoques en cada dispositivo.
¿El kill switch me cortará internet cuando desconecte a propósito?
Un cliente bien hecho retira sus reglas de bloqueo cuando pulsas desconectar, así que el tráfico normal vuelve al instante; el bloqueo está pensado para las caídas inesperadas. Algunos clientes ofrecen además un modo más estricto en el que no fluye tráfico salvo con el túnel activo, útil en un dispositivo que nunca deba saltárselo.
¿Cada cuánto debería repetir los tests de fugas?
Prueba después de cualquier cosa que toque la red: una actualización del sistema, una actualización de la app de VPN, un navegador nuevo, una red desconocida, cambios en el router. Cada una puede resetear el comportamiento DNS o reactivar IPv6. Una pasada completa lleva cinco minutos, así que prueba en cada red nueva y tras las actualizaciones, más que por calendario.

Sigue leyendo

Prueba Aurora

Garantía de devolución de 14 días. Hasta 7 dispositivos con una sola suscripción.

Proteger mis dispositivos