Fexyn
Fexyn
All posts

Qué hace realmente un kill switch VPN

Fexyn Team··6 min read

Un kill switch VPN es una función que bloquea todo el tráfico de internet cuando la conexión VPN cae, así tu IP real no se filtra mientras el cliente está reconectando. Cada VPN dice tener uno. La mayoría son inútiles.

El problema es dónde vive el kill switch. Si vive en la app VPN misma, sólo puede reaccionar después de que la app nota la caída. Eso es código en userland, corriendo contra un SO que ya ruteó tus paquetes.

La brecha de 200ms de la que nadie habla

Aquí está lo que pasa cuando un túnel VPN cae sin un kill switch a nivel kernel:

  1. El endpoint remoto deja de responder. Tal vez un servidor reinicia, tal vez la red cambió, tal vez un flap de routing.
  2. Tu cliente no lo nota por algún tiempo entre 200ms y varios segundos. La mayoría de los clientes usan un health check tipo heartbeat. WireGuard hace ping cada 25 segundos por defecto. El keepalive de OpenVPN es configurable pero comúnmente 10–60 segundos.
  3. Durante esa brecha, tu sistema operativo todavía piensa que el túnel está arriba. Sigue ruteando tráfico a la interfaz del túnel.
  4. La interfaz del túnel suelta los paquetes — pero en algunas configuraciones, el routing de fallback patea y los paquetes salen por tu interfaz real. Tu navegador sigue mandando solicitudes, tu cliente de correo sigue haciendo poll, tus clientes de IM mantienen sus sesiones TCP vivas.
  5. Los servidores de destino loguean tu IP real. El servicio de streaming actualiza su registro de sesión. Tu ISP ve la consulta DNS en cleartext que el resolver in-tunnel se suponía manejaba — mira qué es una filtración DNS para la categoría más amplia de fallas aquí.

Para cuando el cliente VPN despierta y dispara su kill switch en userland, la filtración ya pasó.

Esto es la mayoría de los kill switches VPN. Se activan después del hecho.

Dónde vive un kill switch real

Un kill switch a nivel kernel se sienta en el stack de red del sistema operativo, no en el proceso del cliente VPN. En Windows, eso es Windows Filtering Platform — la misma API de firewall que usa Windows Defender. En macOS, es el framework Network Extension. En Linux, son reglas nftables / iptables con hooks PF_INET.

Tres propiedades lo hacen funcionar:

Se activa antes de que el handshake VPN termine. Cuando haces click en Conectar, el kill switch instala sus filtros primero. El handshake pasa por un agujero que el kill switch talla para el endpoint VPN específico. Si el handshake falla, ningún tráfico sale jamás.

Sobrevive a crashes del cliente. Si el proceso de la app VPN muere, el kill switch sigue bloqueando. Los kill switches en userland mueren con su app — y Windows felizmente restaura el routing normal en el momento que la app sale.

Sobrevive a cambios de red, suspensión y resume. Pasar de Wi-Fi a ethernet, cerrar la tapa, hibernar, cambiar hotspot — todos estos son eventos que un kill switch in-app ve como cambios de estado separados que manejar. Las reglas WFP están debajo de todo eso. Sólo se quedan en su lugar hasta que un proceso privilegiado las remueva explícitamente.

Cómo lo implementa Fexyn

El cliente Windows de Fexyn se divide en dos piezas: una UI con derechos de usuario y un helper service a nivel SYSTEM. El helper service es lo único que posee los filtros WFP. Cuando haces click en Conectar:

  1. El helper service instala filtros WFP que bloquean todo el tráfico saliente excepto (a) loopback, (b) el endpoint:puerto VPN específico y (c) DHCP/DNS a tu gateway local para fines de handshake.
  2. El handshake VPN corre por ese agujero tallado.
  3. Una vez que el túnel está arriba, la tabla de routing manda todo a través de la interfaz del túnel. Los filtros WFP se quedan en su lugar; sólo no ven la mayor parte del tráfico ahora porque el túnel es la ruta de menor resistencia.
  4. Si el túnel cae, la tabla de routing pierde la ruta del túnel. El tráfico cae al fallback de la interfaz default. Los filtros WFP lo bloquean. Tu navegador muestra un error de "no internet". Tu IP real se queda oculta.
  5. Cuando el helper reconecta exitosamente, el nuevo endpoint del túnel puede diferir. El helper actualiza el agujero tallado y el tráfico fluye de nuevo.

El usuario nunca desactiva nada. La UI nunca pide admin. El kill switch nunca depende de que la UI esté viva.

Cómo se ve esto en la práctica

Abre Wireshark y pon tu laptop en una caída forzada de VPN (desconecta la red, cambia de red Wi-Fi, suspende y resume). Con un kill switch en userland verás paquetes seguir fluyendo en la interfaz subyacente por alguna ventana después de la caída — usualmente 200ms a unos segundos. Con un kill switch basado en WFP no verás nada hasta que o el túnel reconecte o desactives explícitamente el kill switch.

Lo último es lo que quieres.

Cosas que "kill switch" no es

Los kill switches resuelven un problema específico: filtraciones de tráfico durante una transición del túnel. No:

  • Protegen un endpoint comprometido. Si tu laptop está infectada, el malware ve tu tráfico antes que el kernel.
  • Detienen filtraciones DNS por sí solos. La prevención de filtración DNS es una capa separada (reglas NRPT en Windows, configuración para forzar DNS por el túnel en el protocolo). Un kill switch solo no arreglará una ruta DNS mal configurada.
  • Previenen filtraciones WebRTC. WebRTC del navegador opera por encima de la capa de red; el navegador conoce tu IP real sin importar lo que vea la red. Solución totalmente distinta.

Qué buscar

Si estás evaluando el kill switch de una VPN, las preguntas son:

  1. ¿Se activa antes de que termine el handshake, o sólo después?
  2. ¿Sobrevive al crash del cliente VPN?
  3. ¿Es una regla de firewall a nivel kernel, o un loop de reconexión en userland?
  4. ¿Permite loopback para que tus servidores de dev locales sigan funcionando?

Las respuestas honestas usualmente aparecen en la documentación del producto en vez del copy de marketing. El copy de marketing siempre dirá "kill switch" sin especificar de qué tipo.

Para Fexyn:

  • Basado en WFP, a nivel kernel
  • Se activa antes del handshake
  • Sobrevive a crash del helper-service, sleep, resume, cambio de red
  • Permite loopback (127.0.0.0/8 y ::1) y link-local

Relacionado

Prueba Fexyn gratis 7 días. El kill switch está activo por defecto; no tienes que activarlo.

Qué hace realmente un kill switch VPN | Fexyn VPN