¿Qué pasa cuando tu VPN se desconecta?

El trabajo de un kill switch VPN es simple de describir: cuando la conexión VPN se cae, evitar que el tráfico se filtre fuera del túnel. Las implementaciones entre proveedores VPN varían ampliamente, y las diferencias importan. Un kill switch con una ventana de fuga de varios segundos durante una caída de VPN derrota el propósito entero de tener un kill switch.

Esta es la versión técnica. Qué hacen realmente los kill switches, los dos patrones principales de implementación, por qué importa el nivel kernel, y cómo testear que el tuyo funciona.

Qué significa realmente "kill switch"

Cuando tu cliente VPN establece un túnel, tu tráfico pasa por él. Cuando el túnel se rompe (falla del servidor, cambio de red, ciclo de sleep/wake, interrupción a nivel protocolo), la pregunta es qué le pasa al tráfico durante el corte.

Tres comportamientos posibles:

El tráfico continúa por tu conexión real. Tu IP real se vuelve visible para los destinos. La encriptación que se suponía estuviera prendida está apagada. Cualquiera observando la red ve lo que estás haciendo. Esto es lo que pasa sin kill switch alguno.
El kill switch a nivel aplicación detecta la caída y detiene el tráfico. El daemon del cliente VPN nota que el túnel está caído, luego toma acción para bloquear el tráfico. La detección tiene latencia (el daemon hace polling; el stack de red reporta caídas con delay; la acción tarda en aplicarse). La ventana de fuga es típicamente 1-30 segundos.
El kill switch a nivel kernel bloquea todo el tráfico excepto el túnel VPN desde el inicio. Las reglas de firewall a nivel kernel del SO bloquean todo lo que no esté en el túnel VPN. Cuando la VPN se cae, las reglas siguen ahí bloqueando todo; el tráfico nuevo no puede salir hasta que la VPN reconecte. No hay latencia de detección porque no hay nada que detectar: las reglas bloquean por defecto y sólo permiten tráfico VPN.

La mayoría de los proveedores VPN implementan algo. La pregunta es cuál.

Cómo se caen las conexiones VPN

Vale entender porque moldea lo que el kill switch tiene que manejar. Las caídas pasan por varias razones:

Fallas del lado del servidor. El servidor VPN crashea, reinicia, o su interfaz de red flapea. Recuperación: el cliente reconecta, posiblemente a un servidor distinto.

Cambios de red en el cliente. Cambiar de Wi-Fi a Ethernet. Cambiar de redes Wi-Fi. Suspender la laptop y despertarla. El túnel VPN se rompe porque la red subyacente cambia; el cliente tiene que re-establecer.

Problemas a nivel protocolo. Timeout de handshake WireGuard (el peer no responde dentro de 90 segundos del último handshake). Falla de keep-alive de OpenVPN. Timeout de sesión TLS de VLESS Reality.

Interferencia activa. Un operador de red o sistema DPI bloquea la conexión VPN en medio de la sesión. La conexión cae y el cliente no puede re-establecer hasta que la red cambie o el protocolo cambie.

Crashes del cliente. El proceso del cliente VPN muere por cualquier razón.

Ventanas de boot / shutdown. El sistema tiene acceso a red antes de que el cliente VPN arranque (boot) y después de que el cliente VPN se cierre (shutdown). Durante estas ventanas, el tráfico puede filtrar aunque el kill switch esté de otro modo sólido.

Un kill switch completo maneja todos estos. Una implementación a nivel aplicación los maneja con latencia de detección en cada evento. Una implementación a nivel kernel los maneja por defecto-bloqueando todo lo que no esté en el túnel.

Kill switch a nivel aplicación: cómo funciona

La mayoría de los clientes VPN implementan esto:

El cliente establece el túnel.
El cliente hace polling del estado del túnel en un timer (típicamente intervalo de 1-5 segundos).
Cuando el polling detecta un túnel caído, el cliente le dice al SO que detenga el tráfico, usualmente cambiando la tabla de routing o emitiendo system calls para bloquear conexiones específicas.
Cuando el túnel reconecta, el cliente deshace el bloqueo.

Las ventanas de fuga:

Entre la caída y la detección. Si el intervalo de polling es 5 segundos, la ventana de fuga puede ser hasta 5 segundos.
Entre la detección y la acción. Las llamadas al SO toman tiempo. Los cambios en la tabla de routing se propagan. El sistema tiene tiempo de mandar paquetes por la interfaz incorrecta durante este gap.
Entre el crash del cliente y la recuperación a nivel SO. Si el proceso del cliente VPN muere, el SO no tiene nada diciéndole bloquear el tráfico. Sin otras garantías, el tráfico fluye libremente hasta que el cliente reinicie y re-establezca el kill switch.
En boot antes de que arranque el cliente. Mismo problema: el tráfico puede fluir libremente antes de que el cliente VPN esté arriba.

Algunas implementaciones a nivel aplicación son más robustas que otras: recuperan crashes limpiamente, aplican bloqueos a nivel adaptador de red en lugar de a nivel tabla de routing, integran con las notificaciones de estado de red del SO. El kill switch de NordVPN, el Network Lock de ExpressVPN, el kill switch de Surfshark todos tienen distintos grados de sofisticación. Ninguno es basado en filtros a nivel kernel en todas las plataformas.

Kill switch a nivel kernel: cómo funciona

Un enfoque distinto: instalar reglas de firewall a nivel kernel del SO que bloqueen todo el tráfico excepto el tráfico al endpoint VPN y el tráfico en el túnel VPN. Las reglas son persistentes entre crashes del cliente, reinicios, sleep/wake.

En Windows, esto significa filtros del Windows Filtering Platform (WFP). WFP es el subsistema de filtrado de paquetes a nivel kernel que Windows usa para su firewall incorporado y para productos de seguridad de terceros. Los filtros en la capa WFP aplican a cada paquete que entra o sale del stack de red, sin importar qué aplicación los manda.

En macOS, el equivalente son las reglas pf (packet filter).

En Linux, las reglas iptables o nftables a nivel kernel.

El patrón en los tres:

El cliente VPN (o su instalador) registra reglas a nivel kernel que bloquean todo el tráfico excepto:
- Tráfico a los endpoints del servidor del proveedor VPN (para que la VPN pueda conectarse)
- Tráfico en el túnel VPN (para que el tráfico real del usuario fluya)
Las reglas persisten entre crashes del cliente, reinicios, sleep/wake.
Cuando el cliente VPN establece un túnel, el tráfico fluye. Cuando el túnel se cae, el tráfico se detiene porque las reglas siguen bloqueando todo lo que no esté en el túnel.
No hay gap de detección-y-acción porque no hay nada que detectar: el estado por defecto es "bloqueado excepto por túnel."

El kill switch de Fexyn en Windows está basado en WFP. Las reglas de filtro WFP las instala el helper service (un servicio con privilegios SYSTEM que tiene los derechos para instalar filtros a nivel kernel) y persisten entre boots. Cuando el usuario inicia el cliente VPN, el helper service levanta el túnel y el tráfico fluye. Cuando el túnel se cae, las reglas WFP siguen bloqueando todo; ningún tráfico sale hasta que el túnel vuelva.

Persistencia de boot

El problema más difícil: ¿qué pasa durante el boot, antes de que el cliente VPN haya arrancado?

Sin persistencia de boot, el sistema tiene acceso a internet durante el boot (para conectarse a redes corporativas, descargar actualizaciones de Windows, sincronizar tiempo con servidores NTP) antes de que el cliente VPN arranque. Durante esta ventana, cualquier cosa que se auto-lance en boot puede comunicarse sobre la conexión no encriptada.

Los kill switches con persistencia de boot instalan reglas WFP que sobreviven a los reinicios. Las reglas bloquean todo el tráfico durante el boot hasta que el cliente VPN arranque y levante el túnel. El cliente VPN al inicio le señala a las reglas WFP que permitan tráfico de túnel; hasta esa señal, el sistema no tiene acceso a internet.

Esto es más agresivo que lo que la mayoría de los usuarios quieren: tu laptop genuinamente no puede alcanzar internet durante el boot hasta que la VPN esté arriba. Pero para usuarios con requisitos fuertes de privacidad (periodistas, activistas, ciertos usuarios corporativos), la persistencia de boot es la única forma de prevenir fugas de la ventana de boot.

Fexyn soporta persistencia de boot como opción configurable. El default es apagado (porque confunde a usuarios nuevos cuando su laptop parece "rota" en el boot antes de que se den cuenta de que la VPN no arrancó todavía). Habilitarlo es un toggle en las settings de la app.

Cómo testear tu kill switch

El test honesto:

Iniciá tu VPN. Verificá que esté conectada (chequeá la IP en ipleak.net o un servicio similar; debería mostrar la IP de salida VPN).
Abrí un cliente de torrent o cualquier aplicación que mande tráfico continuo. Notá tu IP real en ipleak.net.
Deshabilitá tu adaptador de red (o desconectá Ethernet, o apagá Wi-Fi). La conexión VPN se cae porque la red se fue.
Esperá 30 segundos. Los intentos de reconexión de la VPN van a fallar porque la red se fue.
Re-habilitá tu adaptador de red. Notá qué pasa.

Lo que querés ver: el tráfico no empieza a fluir inmediatamente cuando la red vuelve. El tráfico sólo empieza a fluir una vez que la VPN reconectó. Corré ipleak.net otra vez: la IP mostrada debería ser la salida VPN, no tu IP real.

Lo que NO querés ver: el tráfico fluye inmediatamente cuando la red vuelve, tu IP real es visible en ipleak.net, la VPN reconecta en segundo plano pero sólo después de que algo de tráfico ya salió.

Un kill switch a nivel kernel pasa este test. Un kill switch a nivel aplicación con un loop de detección rápido usualmente pasa. Un kill switch a nivel aplicación con un loop de detección lento falla.

Por qué importa para casos de uso específicos

Para la mayoría de los usuarios (privacidad casual, trabajo ocasional en Wi-Fi público, geo-bypass para streaming) los kill switches a nivel aplicación están usualmente bien. Las ventanas de fuga son segundos, no minutos; el tráfico que filtra es poco probable que sea sensible suficiente como para importar.

Para casos de uso específicos, el nivel kernel importa más:

Torrenting. Un cliente de torrent corriendo por horas puede experimentar caídas de VPN sin que el usuario lo note. Una IP real apareciendo en logs de swarm por aunque sean unos segundos es suficiente para que agentes de titulares de derechos la loguéen. Los kill switches a nivel kernel previenen la fuga.

Periodismo, activismo, trabajo de disidencia. Las comunicaciones que necesitan confidencialidad por razones de seguridad no pueden tolerar ni siquiera fugas cortas. Nivel kernel + persistencia de boot es la configuración correcta.

Uso impulsado por compliance (HIPAA, ABA 477R). Una VPN cayéndose en medio de la sesión y exponiendo datos de cliente sobre una conexión no encriptada es la postura de compliance que estás tratando de prevenir. El kill switch a nivel kernel es el control técnico que hace defendible el reclamo de compliance.

Entornos corporativos. Los kill switches que sobreviven ciclos de sleep/wake importan para laptops que entran y salen de bolsos durante viajes.

Qué proveedores usan qué

El cuadro en 2026:

Fexyn: A nivel kernel basado en WFP en Windows (producción) y Android (enviado); los clientes de macOS, Linux, e iOS vienen pronto
Mullvad: a nivel kernel en Windows, macOS, Linux. Entre las implementaciones de kill switch más robustas disponibles.
NordVPN: a nivel aplicación en la mayoría de las plataformas con varias mejoras; features a nivel kernel en su cliente Windows más nuevo. Variable dependiendo de la versión.
Network Lock de ExpressVPN: a nivel aplicación con implementación propietaria; funcionalmente robusto en Windows y macOS pero no estrictamente basado en filtros a nivel kernel
Surfshark: kill switch a nivel aplicación
ProtonVPN: a nivel kernel en la mayoría de las plataformas
IVPN: a nivel kernel en la mayoría de las plataformas
AirVPN: a nivel kernel

El patrón: los proveedores enfocados en privacidad técnica (Mullvad, ProtonVPN, IVPN, AirVPN, Fexyn) tienden hacia el nivel kernel. Los proveedores enfocados en mercado masivo de consumo (NordVPN, ExpressVPN, Surfshark) históricamente usaron nivel aplicación con mejoras a lo largo del tiempo.

Preguntas frecuentes

¿Mi VPN tiene kill switch?

Casi cada VPN reputada afirma tener uno. Si efectivamente funciona del modo que necesitás es una pregunta para verificar, no asumir. El test descrito arriba (deshabilitar la red en medio de sesión, observar qué pasa cuando la red vuelve) es la respuesta práctica.

¿Por qué no toda VPN usa kill switches a nivel kernel?

Costo de implementación. El nivel kernel requiere código específico de plataforma: filtros WFP en Windows, reglas pf en macOS, integración de networking de kernel en Linux. Cada plataforma requiere ingeniería separada. Las implementaciones a nivel aplicación funcionan en cada plataforma con el mismo código. Para proveedores VPN sirviendo mercados de consumo amplios, la inversión de ingeniería en nivel kernel históricamente no ha sido la prioridad.

¿La persistencia de boot va a romper mi computadora?

Va a evitar que tu computadora alcance internet durante el boot hasta que la VPN arranque. Para la mayoría de los usuarios esto es molesto pero no roto: la VPN arranca, el sistema alcanza internet. Para usuarios en redes corporativas donde los procesos de boot necesitan acceso a internet (uniéndose a dominios corporativos, sincronizando con servidores de tiempo corporativos, descargando actualizaciones de mirrors internos), la persistencia de boot puede interferir. Testeá antes de habilitar.

¿Qué hay sobre kill switch para apps específicas solamente?

Algunos clientes VPN te permiten configurar el kill switch para aplicar a apps específicas en lugar de a todo el tráfico. Útil cuando querés que algo del tráfico vaya por la VPN con protección kill-switch (apps de trabajo) y otro tráfico vaya alrededor de la VPN (streaming). Fexyn no soporta actualmente kill switch por app; enviamos el enfoque todo-o-nada. Mullvad y ProtonVPN tienen opciones más granulares por app.

¿Puedo confiar en un "kill switch" que no puedo testear?

Testealo. El costo de testear son minutos; el costo de un kill switch que no funciona realmente es lo que sea que el tráfico filtrado expuso. Cualquier kill switch que no pueda ser testeado por el usuario es un reclamo de marketing, no una feature verificada.

Probá Fexyn gratis 7 días: kill switch a nivel kernel basado en WFP en Windows, con persistencia de boot opcional. VPN para torrenting y VPN para abogados cubren los casos de uso donde esto importa más.

Última revisión 2026-05-09.