Qué es un kill switch de VPN

Un kill switch de VPN bloquea todo el tráfico de internet cuando el túnel VPN cae. El punto es que tu IP real no se filtre durante los segundos (o más) que toma reconectar. Cada VPN dice tener uno. La mayoría no lo tiene, en el sentido que importa.

La diferencia es dónde vive el kill switch.

Kill switches a nivel de app: el tipo falso

La mayoría de los kill switches de VPN viven dentro de la app de VPN. La app monitorea el túnel; cuando ve que el túnel cae, bloquea el tráfico. Suena razonable.

El problema es el timing. La app se entera de que el túnel cayó después de que el SO ya enrutó paquetes. Los heartbeats corren cada 10-60 segundos, dependiendo del protocolo. Hay una ventana de 200 ms a varios segundos donde el SO piensa que el túnel sigue arriba — pero no lo está, y los paquetes regresan a la interfaz subyacente y filtran tu IP real.

Para cuando la app reacciona, tu navegador ya envió la siguiente solicitud. Los servicios de streaming ya registraron tu IP. Tu ISP ya vio la consulta DNS en texto claro que debería haber sido tunelizada.

Los kill switches a nivel de userland se activan después de la fuga. Eso es la mayoría de los kill switches de VPN de consumo.

Kill switches a nivel kernel: el tipo real

Un kill switch a nivel kernel vive en el stack de red del SO. En Windows eso es Windows Filtering Platform (WFP) — la misma API de firewall que usa Windows Defender Firewall. En macOS es Network Extension. En Linux es nftables/iptables con hooks PF_INET.

Tres propiedades lo hacen funcionar:

1. Se dispara antes de que el handshake VPN se complete. Cuando haces clic en Conectar, los filtros del kill switch se instalan primero. El handshake pasa a través de un agujero abierto específicamente para el endpoint VPN. Si el handshake falla, nada más sale.
2. Sobrevive a los crashes de la app. Si el proceso VPN muere, el kill switch sigue bloqueando. Los kill switches de userland mueren con su app — y Windows alegremente restaura el enrutamiento normal tan pronto como la app sale.
3. Sobrevive al sleep, resume, y cambios de red. Wi-Fi a ethernet, cierre de tapa, hibernación, cambio de hotspot — todos son eventos que un kill switch en la app debe manejar como cambios de estado separados. Las reglas WFP están debajo.

Lee el deep dive para el mecanismo completo.

Lo que el kill switch no arregla

Un kill switch cierra la brecha durante las transiciones del túnel. No:

• Protege contra endpoints comprometidos. El malware en tu laptop ve el tráfico antes que el kernel.
• Detiene las fugas DNS por sí solo — esa es una capa separada (NRPT en Windows, forzar DNS por el túnel en la configuración del protocolo).
• Previene las fugas WebRTC. WebRTC opera sobre la capa de red; el navegador conoce tu IP real sin importar lo que la red vea.

Estos necesitan arreglos separados. No confíes en una VPN que los junta todos bajo "protección de kill switch."

Cómo Fexyn lo maneja

A nivel kernel vía WFP. Se dispara antes del handshake. Sobrevive a los crashes. Por defecto encendido, sin toggle para olvidar. Permite loopback para que los servidores de desarrollo locales sigan funcionando. Lee más en la página de soporte o pruébalo en el caso de uso de Wi-Fi público donde más importa.

Prueba Fexyn gratis por 7 días — el kill switch está encendido por defecto.