Kill switch de la aplicación frente a kill switch del cortafuegos: qué bloquea cada uno

Un kill switch en una lista de funciones no dice casi nada sobre lo que ocurre cuando cae el túnel. Una implementación cierra procesos seleccionados, otra instala filtros de paquetes en el límite del sistema operativo y una tercera simplemente intenta reconectarse. La diferencia se ve en los segundos posteriores a un fallo, no en la pantalla de ajustes. Recorra estas comprobaciones en orden y deténgase en la primera que no pueda responder con sinceridad, porque ahí termina su cobertura real.

Nombre primero el mecanismo de ejecución

La terminación de procesos es una función del ciclo de vida de la aplicación. Encuentra programas seleccionados tras un fallo de túnel detectado y los cierra. Todo lo que no es el proceso principal sobrevive: servicios auxiliares, sincronización en segundo plano y cualquier aplicación iniciada un segundo después tienen su propio ciclo de vida y su propio momento.

El filtrado de paquetes es una función del sistema operativo. Rechaza el tráfico que no sigue la ruta permitida, que es una promesa más fuerte, pero solo abarca aquello a lo que la regla realmente se ajusta. La familia de direcciones, la interfaz, las aplicaciones excluidas y las excepciones deciden eso, no la etiqueta del cliente.

¿El bloqueo sobrevive al cliente?

Haga cuatro preguntas en este orden: qué ocurre en un cierre inesperado, en una salida manual, al cerrar sesión y al reiniciar. Una regla mantenida por el propio cliente suele eliminarse durante un cierre ordenado y a menudo queda atrás tras un cierre inesperado. Una regla instalada en el almacén de la plataforma puede comportarse al revés: sobrevivir tanto al cliente como, en ocasiones, a la desinstalación.

Cierre el cliente en mitad de una descarga larga y observe si la transferencia se detiene o continúa.

Busque los agujeros habituales

IPv6 es el primero. Una regla escrita para direcciones IPv4 deja el tráfico IPv6 sin tocar, y muchos clientes solo escriben la mitad v4. El segundo es la interfaz: el tethering USB, un segundo adaptador Wi-Fi y un módem celular pueden no estar incluidos en una regla limitada a la conexión principal. Aplicaciones excluidas y las excepciones de red local son el tercero.

En Windows puede leer las reglas instaladas en lugar de confiar en el interruptor: Get-NetFirewallRule -DisplayName '*VPN*' y netsh wfp show filters muestran ambos lo que existe. En Linux, iptables -S, ip6tables -S y nft list ruleset cubren los casos habituales, y comparar los tres es la clave.

El DNS es la fuga habitual

Bloquear TCP mientras UDP 53 queda abierto le da un kill switch muy convincente que sigue respondiendo a cada consulta de nombre de host. Lo mismo se aplica cuando el DNS se entrega a un resolutor en otra interfaz, o cuando el cliente solo bloquea v4 y el resolutor es accesible por v6.

Con el túnel caído, resuelva un nombre conocido y vea si vuelve una respuesta. Si vuelve, el tráfico no está bloqueado del todo, diga lo que diga el icono de estado.

Pruebe la transición, no el interruptor

Apagar la VPN desde su propio menú es un cierre ordenado, y el caso ordenado toda implementación lo maneja bien. La transición que importa es la brusca: mate el proceso del túnel, retire la red, deje que el servidor deje de responder. Luego inicie una petición y observe si falla o usa en silencio el enlace físico.

El resultado de un portátil no se traslada a un teléfono ni a un router. API de plataforma distintas, valores por defecto distintos, y en Android la diferencia es enorme: el modo always-on con bloqueo lo impone el sistema y no el cliente, así que sigue funcionando cuando el cliente no lo hace. La guía de VPN de Android describe esa separación.

Mantenga una vía de vuelta

El bloqueo a nivel de sistema tiene el modo de fallo contrario. Los filtros que sobreviven al cliente pueden dejar una máquina sin red alguna tras una desinstalación, lo que es una llamada al soporte sin causa evidente. Antes de activar cualquier kill switch que escriba reglas de plataforma, anote cómo se elimina y tenga la vía de reparación del fabricante donde pueda encontrarla.

Si no puede responder a las comprobaciones de cierre inesperado, IPv6, DNS y transición para su cliente, trátelo como un interruptor de nivel de aplicación con huecos conocidos y planifique en consecuencia.