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