Kill switch da aplicación fronte a kill switch da devasa: que bloquea cada un

Un kill switch nunha lista de funcións non di case nada sobre o que ocorre cando cae o túnel. Unha implementación pecha procesos seleccionados, outra instala filtros de paquetes no límite do sistema operativo e unha terceira simplemente tenta reconectarse. A diferenza vese nos segundos posteriores a un fallo, non na pantalla de axustes. Percorra estas comprobacións en orde e detéñase na primeira que non poida responder con sinceridade, porque é alí onde remata a súa cobertura real.

Nomee primeiro o mecanismo de execución

A terminación de procesos é unha función do ciclo de vida da aplicación. Atopa programas seleccionados tras un fallo de túnel detectado e péchaos. Todo o que non é o proceso principal sobrevive: servizos auxiliares, sincronización en segundo plano e calquera aplicación iniciada un segundo despois teñen o seu propio ciclo de vida e o seu propio momento.

O filtrado de paquetes é unha función do sistema operativo. Rexeita o tráfico que non segue a ruta permitida, que é unha promesa máis forte, pero só abrangue aquilo ao que a regra realmente se axusta. A familia de enderezos, a interface, as aplicacións excluídas e as excepcións deciden iso, non a etiqueta do cliente.

O bloqueo sobrevive ao cliente?

Faga catro preguntas nesta orde: que ocorre nun peche inesperado, nunha saída manual, ao pechar a sesión e ao reiniciar. Unha regra mantida polo propio cliente adoita eliminarse durante un peche ordenado e a miúdo queda atrás tras un peche inesperado. Unha regra instalada no almacén da plataforma pode comportarse ao revés: sobrevivir tanto ao cliente como, ás veces, á desinstalación.

Pecha o cliente no medio dunha descarga longa e observa se a transferencia se detén ou continúa.

Busque os buratos habituais

IPv6 é o primeiro. Unha regra escrita para enderezos IPv4 deixa o tráfico IPv6 sen tocar, e moitos clientes só escriben a metade v4. O segundo é a interface: o tethering USB, un segundo adaptador Wi-Fi e un módem celular poden non estar incluídos nunha regra limitada á conexión principal. Aplicacións excluídas e as excepcións de rede local son o terceiro.

En Windows pode ler as regras instaladas en lugar de confiar no interruptor: Get-NetFirewallRule -DisplayName '*VPN*' e netsh wfp show filters mostran ambos o que existe. En Linux, iptables -S, ip6tables -S e nft list ruleset cobren os casos habituais, e comparar os tres é a clave.

O DNS é a fuga habitual

Bloquear TCP mentres UDP 53 queda aberto dálle un kill switch moi convincente que segue respondendo a cada consulta de nome de host. O mesmo se aplica cando o DNS se entrega a un resolutor noutra interface, ou cando o cliente só bloquea v4 e o resolutor é accesible por v6.

Co túnel caído, resolva un nome coñecido e vexa se volve unha resposta. Se volve, o tráfico non está bloqueado de todo, diga o que diga a icona de estado.

Probe a transición, non o interruptor

Apagar a VPN desde o seu propio menú é un peche ordenado, e o caso ordenado toda implementación o manexa ben. A transición que importa é a brusca: mate o proceso do túnel, retire a rede, deixe que o servidor deixe de responder. Logo inicie unha petición e observe se falla ou usa en silencio a ligazón física.

O resultado dun portátil non se traslada a un teléfono nin a un router. API de plataforma distintas, valores por defecto distintos, e en Android a diferenza é enorme: o modo always-on con bloqueo impono o sistema e non o cliente, así que segue funcionando cando o cliente non o fai. A guía de VPN de Android describe esa separación.

Manteña unha vía de volta

O bloqueo a nivel de sistema ten o modo de fallo contrario. Os filtros que sobreviven ao cliente poden deixar unha máquina sen rede algunha tras unha desinstalación, o que é unha chamada ao soporte sen causa evidente. Antes de activar calquera kill switch que escriba regras de plataforma, anote como se elimina e teña a vía de reparación do fabricante onde poida atopala.

Se non pode responder ás comprobacións de peche inesperado, IPv6, DNS e transición para o seu cliente, tráteo como un interruptor de nivel de aplicación con buratos coñecidos e planifique en consecuencia.