La versión corta: una conexión VPN no es un estado permanente — es una sesión de red que puede caerse. Los cambios de Wi-Fi, las transiciones entre torres de telefonía móvil, los reinicios del servidor, los picos de pérdida de paquetes, las suspensiones de aplicaciones y los ciclos de suspensión del sistema operativo interrumpen el túnel de forma habitual. Cuando el túnel cae, la regla de enrutamiento predeterminada del sistema operativo dice «si no hay una ruta específica, usa la interfaz física» — lo que significa que tu tráfico vuelve a tu conexión real, enviando tu IP real a lo que fuera que estabas contactando. Un kill switch es el mecanismo que dice «no, simplemente deja de enviar tráfico hasta que el túnel vuelva a estar activo». Conceptualmente sencillo. En la implementación, el término se ha utilizado para referirse a al menos tres cosas bastante distintas, con modos de fallo muy diferentes.
Por qué existen los kill switches — el problema del fallback silencioso
Considera lo que ocurre sin un kill switch. Estás en una cafetería con la VPN conectada. Estás leyendo correo electrónico a través de un cliente de webmail. El Wi-Fi tiene una breve interrupción — quizás dos segundos. El cliente VPN intenta reconectarse, pero la red subyacente no está disponible, así que la reconexión falla. Después de 30 segundos la red vuelve. Lo que ocurre a continuación depende del comportamiento del cliente VPN:
- Sin kill switch — en el momento en que el Wi-Fi vuelve, la ruta predeterminada del sistema operativo revierte a la interfaz Wi-Fi. El cliente VPN todavía está intentando reconectarse, pero las aplicaciones no esperan. La sincronización en segundo plano del webmail envía la siguiente solicitud a través del Wi-Fi sin protección, usando tu IP real, con el resolver DNS que la red te haya asignado. Para cuando la VPN termina de reconectarse (5-20 segundos después), la filtración ya ha ocurrido.
- Con kill switch — cuando la VPN se desconecta, el kill switch instala una regla de firewall que bloquea todo el tráfico que no pasa por el túnel. Incluso cuando el Wi-Fi vuelve, las aplicaciones no pueden enviar nada hasta que la sesión VPN esté completamente restaurada. La solicitud de sincronización del webmail falla con un error de red (la aplicación reintenta), pero ningún tráfico sale de tu dispositivo a través de la interfaz sin protección.
El problema del fallback silencioso es el asunto central que los kill switches están diseñados para resolver. No se trata de «la VPN se cayó y ahora estoy navegando sin protección» — es el caso mucho más sutil en el que la VPN está brevemente no disponible, las aplicaciones no lo saben, y filtran en ese intervalo.
Los tres tipos de kill switch
Cuando los proveedores dicen «kill switch», pueden referirse a cualquiera de estas tres arquitecturas. Las diferencias importan porque los modos de fallo son distintos.
1. Kill switch a nivel del sistema (basado en firewall)
El modelo más robusto. El cliente VPN instala una regla de firewall en el sistema operativo — usando pf en macOS, la Windows Filtering Platform en Windows, iptables o nftables en Linux, o una extensión de red del sistema en iOS/Android — que descarta todo paquete saliente que no vaya destinado a la IP del servidor VPN. Cuando la VPN está activa, el propio túnel enruta el tráfico hacia el servidor VPN, por lo que los paquetes pasan. Cuando la VPN está caída, nada coincide con la regla «permitir», así que todo queda bloqueado. La regla de firewall permanece en vigor incluso si el cliente VPN se bloquea, porque el firewall del sistema operativo es independiente de la aplicación que instaló la regla.
2. Kill switch a nivel de aplicación (por aplicación)
En lugar de bloquear todo el tráfico, el kill switch solo bloquea las aplicaciones específicas que hayas añadido a una lista. Cuando la VPN cae, esas aplicaciones pierden conectividad de red hasta que la VPN vuelve; las demás aplicaciones siguen funcionando con normalidad. Esto es útil para escenarios muy concretos — proteger un navegador específico, un cliente IRC o un cliente BitTorrent — pero es más débil como defensa general porque deja una gran superficie de ataque (las aplicaciones en la barra del sistema, los servicios en segundo plano, los componentes del sistema operativo y las aplicaciones que olvidaste añadir a la lista).
3. Firewall a nivel de red (VPN siempre activa)
En Android concretamente, existe un mecanismo más robusto que los kill switches que implementan las propias aplicaciones VPN: el ajuste «VPN siempre activa» a nivel del sistema con «Bloquear conexiones sin VPN» habilitado. Es el propio sistema operativo quien aplica la regla — Android se niega a enrutar cualquier tráfico sin VPN, independientemente de qué aplicación lo solicite. Incluso si la aplicación VPN se bloquea, el sistema operativo mantiene la restricción. Este es el comportamiento de kill switch más robusto disponible en dispositivos móviles y es estrictamente superior a los kill switches implementados por las aplicaciones.
Cómo funciona cada tipo a nivel del sistema operativo
Los detalles de implementación importan porque predicen los modos de fallo. Un kill switch basado en firewall falla cuando la API del firewall tiene errores. Un kill switch basado en aplicaciones falla cuando la aplicación se bloquea. Un kill switch siempre activo aplicado por el sistema operativo prácticamente no falla, a menos que reinicies en modo seguro.
Implementación en iOS — NetworkExtension y reglas bajo demanda
iOS no expone una API «kill switch» literal a las aplicaciones VPN de terceros. Lo que sí expone es el mecanismo de «reglas bajo demanda» del framework NetworkExtension: reglas que dicen «cada vez que alguna aplicación intente hacer una conexión de red que no coincida con una excepción, forzar primero la conexión VPN». Si la VPN no puede establecerse, la solicitud de conexión queda en espera. Desde la perspectiva del usuario, esto se comporta como un kill switch — pero en realidad es una regla de «forzar VPN activa» en lugar de una regla de «bloquear todo si la VPN está caída». El resultado funcional es similar; la implementación es diferente.
La API NetworkExtension también admite el indicador includeAllNetworks (añadido en iOS 14), que convierte la VPN en un filtro de red a nivel del sistema — incluso el tráfico del kernel y los servicios del sistema se fuerza a través de la VPN. Con ese indicador activado, la VPN realmente funciona como un kill switch completo, con el sistema operativo garantizando que ningún tráfico escapa fuera del túnel. No todos los proveedores de VPN lo habilitan; el indicador tiene implicaciones de compatibilidad.
Implementación en Android — VPN siempre activa + Bloquear conexiones sin VPN
El comportamiento de kill switch más robusto de Android se encuentra en Ajustes, luego Red e internet, luego VPN, luego el icono de engranaje junto a tu VPN, y luego los dos interruptores: «VPN siempre activa» y «Bloquear conexiones sin VPN». Cuando ambos están activados, es el propio sistema Android — no la aplicación VPN — quien se niega a enrutar tráfico hasta que la VPN esté conectada. La aplicación VPN puede bloquearse, forzarse a cerrar o desinstalarse, y la regla persiste. La documentación oficial para desarrolladores de Android describe el mecanismo en detalle. Este es el estándar de oro para el comportamiento de kill switch en dispositivos móviles de consumo.
Implementación en macOS — extensiones de red del sistema
macOS 11 (Big Sur) y versiones posteriores ejecutan las VPN a través del framework System Extension — la misma arquitectura que soporta los filtros de contenido y los filtros de red a nivel del sistema. El kill switch se implementa habitualmente como una regla de filtro de paquetes (pf) instalada por el cliente VPN, combinada con una extensión de red que gestiona la modificación de la tabla de rutas. Cuando la VPN cae, la regla pf permanece en vigor y continúa bloqueando el tráfico hasta que la VPN se restablece. Si el propio cliente VPN se bloquea, el comportamiento depende de si la extensión del sistema está configurada para permanecer cargada — los clientes bien diseñados mantienen las reglas en su lugar; los mal diseñados las eliminan al bloquearse y filtran.
Implementación en Windows — Windows Filtering Platform
Las VPN de Windows suelen implementar el kill switch instalando reglas de filtro de la Windows Filtering Platform (WFP) que bloquean el tráfico en el adaptador físico mientras permiten el tráfico en el adaptador VPN virtual. Los filtros persisten entre reinicios del proceso del cliente VPN (son propiedad de la capa de filtro del kernel, no de la aplicación en espacio de usuario), así que incluso si la aplicación VPN se bloquea, el filtro permanece. El riesgo es que algunos clientes VPN usan estrategias de reglas de firewall de menor calidad — por ejemplo, manipular el Firewall de Windows Defender mediante PowerShell o netsh — que pueden ser eludidas por otras reglas de firewall o por una configuración incorrecta.
Cuándo fallan los kill switches — filtraciones que debes conocer
Un kill switch no es una garantía perfecta. Existen condiciones bien documentadas en las que el tráfico puede filtrarse incluso con un kill switch habilitado. Cada proveedor de VPN las gestiona de forma diferente; algunas se resuelven con una implementación cuidadosa, otras son inevitables sin la colaboración del sistema operativo.
Envenenamiento de DNS durante el arranque de la conexión
Para conectarse al servidor VPN, el cliente VPN primero tiene que resolver el nombre de host del servidor. Si el kill switch está aplicando «sin tráfico sin VPN», pero el propio cliente VPN necesita hacer una consulta DNS para encontrar el servidor VPN, tiene que haber una excepción — y esa excepción es una pequeña superficie de filtración. Una red local maliciosa podría envenenar la respuesta DNS y redirigir el cliente VPN a un servidor falso. La mayoría de los clientes lo gestionan usando una IP fija para el servidor VPN, o fijando el certificado TLS para que un servidor redirigido no valide. Los clientes VPN baratos a veces omiten este paso.
Filtraciones de IPv6
Si tu red tiene conectividad IPv6 pero el kill switch del cliente VPN solo bloquea el tráfico IPv4, tu tráfico IPv6 puede salir por la interfaz sin protección incluso cuando el kill switch está «activo». Este es uno de los modos de filtración más comunes en el mundo real. La solución es que el cliente VPN instale reglas de firewall de IPv6 equivalentes. Muchos clientes más antiguos no lo hacen. Siempre comprueba las filtraciones de IPv6 después de habilitar un kill switch ejecutando un test de filtraciones.
Portales cautivos (páginas de inicio de sesión en Wi-Fi)
Las cafeterías, aeropuertos y hoteles suelen requerir que inicies sesión a través de un portal cautivo antes de poder acceder a internet — incluyendo el servidor VPN. Un kill switch estricto no te dejará acceder al portal cautivo porque este no es el servidor VPN. La mayoría de los clientes VPN tienen un modo de «pausar kill switch para portal cautivo» que tienes que habilitar manualmente. Mientras está en pausa, no estás protegido, así que no navegues nada sensible hasta que el kill switch vuelva a estar activo. La VPN siempre activa nativa del sistema operativo en Android gestiona esto de forma algo más elegante mediante la detección de portales cautivos del sistema, pero la contrapartida es la misma.
Carreras de suspensión y reinicio en segundo plano de aplicaciones
En dispositivos móviles, el sistema operativo puede suspender la aplicación VPN para ahorrar batería. Cuando la aplicación se reanuda, hay una pequeña ventana en la que el túnel se está restableciendo. Si el kill switch se implementa a nivel del sistema operativo (mediante includeAllNetworks en iOS o VPN siempre activa en Android), no hay filtración. Si el kill switch se implementa únicamente en la aplicación, puede haber una breve ventana en la que el sistema operativo ha reanudado las aplicaciones pero la VPN no se ha reconectado, y las aplicaciones que hagan llamadas de red durante esa ventana filtrarán.
Carrera en el momento de arranque
En escritorio, el período entre el arranque y el inicio del cliente VPN no está protegido. Las aplicaciones con conciencia de red que se inician automáticamente (Mail, Slack, Steam, comprobaciones de actualizaciones del sistema) suelen establecer conexiones antes de que la VPN esté activa. Un kill switch robusto instala su regla de firewall como una regla persistente en el arranque para que, incluso al iniciar el sistema, el tráfico esté bloqueado hasta que la VPN se conecte. La mayoría de los clientes VPN de consumo no hacen esto; la regla solo se aplica después de que el cliente se inicia.
Comparativa de tipos de kill switch
| Tipo | Qué bloquea | Compatibilidad con SO | Modos de fallo habituales |
|---|---|---|---|
| Firewall a nivel del sistema | Todo el tráfico no VPN a nivel del kernel | macOS, Windows, Linux; iOS mediante includeAllNetworks | Filtraciones de IPv6 si las reglas son solo para IPv4; carrera en el arranque; excepción de arranque DNS |
| A nivel de aplicación (lista de bloqueo por aplicación) | Solo el tráfico de las aplicaciones de la lista | Windows, algunos clientes macOS | Las aplicaciones que no están en la lista siguen filtrando; los componentes del SO filtran; los servicios del sistema filtran |
| VPN siempre activa aplicada por el SO | Todo el tráfico a nivel del SO, independientemente del bloqueo de la aplicación | Android (VPN siempre activa + Bloquear sin VPN), iOS (NetworkExtension bajo demanda) | El inicio de sesión en el portal cautivo queda bloqueado hasta que pausas; muy pocos modos de fallo adicionales |
| Monitor de aplicaciones (la forma débil) | Nada directamente; solo cierra las aplicaciones especificadas cuando cae la VPN | Algunos clientes de Windows todavía lo incluyen | La carrera entre detección y cierre provoca filtraciones; no es realmente un kill switch |
Qué te da realmente «VPN siempre activa» que un kill switch a nivel de aplicación no ofrece
La distinción más importante en 2026 es entre kill switches implementados por el proveedor y la VPN siempre activa aplicada por el SO. Por qué la versión aplicada por el SO es significativamente más robusta:
- Sobrevive a los bloqueos de la aplicación VPN. Si la aplicación VPN se bloquea por cualquier motivo, un kill switch a nivel de aplicación desaparece con ella. La regla de firewall que instaló puede o no persistir dependiendo de la implementación. Una regla aplicada por el SO la mantiene el propio sistema operativo y continúa siendo aplicada.
- Sobrevive a los reinicios. Muchos kill switches a nivel de aplicación instalan reglas al iniciarse la aplicación y las eliminan al cerrarse, dejando un hueco en el arranque. Los ajustes de siempre activa a nivel del SO se respetan desde el primer paquete de red que el SO enruta tras el arranque.
- Cubre los servicios del sistema. La sincronización en la nube, las comprobaciones de actualizaciones del SO, los daemons de notificaciones push y otros servicios a nivel del SO no pasan por el enrutamiento normal del cliente VPN. La siempre activa a nivel del SO los cubre; un kill switch a nivel de aplicación puede no hacerlo.
- No puede eludirse por error del usuario. Un kill switch a nivel de aplicación tiene un interruptor en la interfaz de la aplicación. Un usuario (u otra aplicación con permisos) puede desactivarlo. La siempre activa a nivel del SO está en los ajustes del sistema y es más difícil de desactivar accidentalmente.
En Android, prefiere la versión aplicada por el SO: activa «VPN siempre activa» y «Bloquear conexiones sin VPN» en los ajustes del sistema, y trata el kill switch propio del cliente VPN como un complemento. En iOS, busca clientes VPN que activen includeAllNetworks; ese es el indicador equivalente y proporciona garantías similares.
Qué hace Casper — la respuesta honesta
Casper's Cloak usa un kill switch integrado en el SO en cada plataforma — includeAllNetworks en iOS para que sea el propio SO quien aplique la regla de no filtración, los ajustes de VPN siempre activa en Android, y reglas de filtro de paquetes a nivel del kernel en macOS. El comportamiento es el mismo en las tres plataformas: cuando el túnel cae, todo el tráfico se detiene, incluido IPv6 e incluidos los servicios a nivel del SO. Cuando el túnel vuelve, el tráfico se reanuda. No hay ningún interruptor que olvidar, ninguna lista por aplicación que mantener, ninguna excepción para IPv6.
Combinamos esto con protección contra amenazas y escudo de amenazas para el filtrado activo contra dominios maliciosos conocidos, de modo que el túnel no es solo una capa de enrutamiento — está rechazando activamente las conexiones a phishing, C2 de malware e infraestructura conocida como peligrosa. El kill switch es la garantía de capa inferior de que nada elude el filtrado cuando el túnel cae brevemente. El efecto combinado: incluso en redes hostiles como las descritas en nuestro artículo sobre ataques en Wi-Fi público, no se produce esa «ventana de dos segundos de texto en claro» que deja abierta un kill switch únicamente a nivel de aplicación.
Nuestra posición sobre los kill switches en general: es una expectativa básica, no una función premium. Cualquier VPN de consumo que no ofrezca uno en 2026 carece de un mecanismo de seguridad fundamental. Para el contexto de modelado de amenazas sobre por qué esto importa a nivel del sistema, la guía de la NSA sobre la selección y fortalecimiento de VPN de acceso remoto cubre el razonamiento arquitectónico en detalle, con una recomendación a favor de las arquitecturas de túnel completo respaldadas por aplicación a nivel del kernel.
Conclusión
«¿Tiene esta VPN un kill switch?» es la pregunta equivocada. Las preguntas correctas son: dónde en la pila se aplica el kill switch (aplicación, sistema o SO), si cubre IPv6, si persiste entre bloqueos de la aplicación y reinicios, y si está activado por defecto. Si las respuestas son «nivel del SO», «sí», «sí» y «sí», el kill switch está cumpliendo su función. Si las respuestas son «solo a nivel de aplicación», «no», «depende» y «desactivado por defecto», tienes un kill switch de nombre pero no de protección.
La práctica sencilla: en Android, activa la VPN siempre activa a nivel del sistema con «Bloquear conexiones sin VPN». En iOS, usa un cliente VPN que active includeAllNetworks. En escritorio, verifica tras la instalación ejecutando un test de filtraciones, luego desconecta brevemente el servidor VPN (o desenchufa el cable de red) y confirma que el tráfico realmente se detiene. Si el test de filtraciones sigue mostrando tu IP real, el kill switch no está funcionando como se anuncia — investiga antes de confiar en él.