Kill switch do app versus kill switch do firewall: o que cada um bloqueia

Um kill switch numa lista de funções não diz quase nada sobre o que acontece quando o túnel cai. Uma implementação fecha processos selecionados, outra instala filtros de pacotes na fronteira do sistema operativo, e uma terceira apenas tenta reconectar-se. A diferença aparece nos segundos após uma falha, não no ecrã de definições. Percorra estas verificações por ordem e pare na primeira a que não consegue responder com honestidade, porque é aí que termina a sua cobertura real.

Nomeie primeiro o mecanismo de aplicação

A terminação de processos é uma função do ciclo de vida da aplicação. Encontra programas selecionados após uma falha de túnel detetada e fecha-os. Tudo o que não é o processo principal sobrevive: serviços auxiliares, sincronização em segundo plano e qualquer aplicação iniciada um segundo depois têm o seu próprio ciclo de vida e o seu próprio momento.

A filtragem de pacotes é uma função do sistema operativo. Recusa o tráfego que não segue o caminho permitido, o que é uma promessa mais forte, mas apenas na medida em que a regra realmente corresponde. A família de endereços, a interface, as aplicações excluídas e as exceções decidem isso, não o rótulo no cliente.

O bloqueio sobrevive ao cliente?

Faça quatro perguntas por esta ordem: o que acontece numa falha súbita, numa saída manual, ao terminar sessão e ao reiniciar. Uma regra mantida pelo próprio cliente é normalmente removida durante um encerramento ordeiro e muitas vezes fica para trás após uma falha súbita. Uma regra instalada no armazém da plataforma pode comportar-se ao contrário: sobreviver tanto ao cliente como, por vezes, à desinstalação.

Feche o cliente a meio de um download longo e observe se a transferência para ou continua.

Procure os buracos habituais

IPv6 é o primeiro. Uma regra escrita para endereços IPv4 deixa o tráfego IPv6 intacto, e muitos clientes só escrevem a metade v4. O segundo é a interface: o tethering USB, um segundo adaptador Wi-Fi e um modem celular podem não estar incluídos numa regra limitada à ligação principal. Aplicações excluídas e as exceções de rede local são o terceiro.

No Windows pode ler as regras instaladas em vez de confiar no interruptor: Get-NetFirewallRule -DisplayName '*VPN*' e netsh wfp show filters mostram ambos o que existe. No Linux, iptables -S, ip6tables -S e nft list ruleset cobrem os casos habituais, e comparar os três é o essencial.

O DNS é a fuga habitual

Bloquear TCP enquanto UDP 53 fica aberto dá-lhe um kill switch muito convincente que continua a responder a cada consulta de nome de anfitrião. O mesmo se aplica quando o DNS é entregue a um resolvedor noutra interface, ou quando o cliente só bloqueia v4 e o resolvedor é acessível por v6.

Com o túnel em baixo, resolva um nome conhecido e veja se volta uma resposta. Se voltar, o tráfego não está totalmente bloqueado, diga o que disser o ícone de estado.

Teste a transição, não o interruptor

Desligar a VPN a partir do seu próprio menu é um encerramento ordeiro, e o caso ordeiro é o que todas as implementações tratam bem. A transição que importa é a brusca: mate o processo do túnel, puxe a rede, deixe o servidor parar de responder. Depois inicie um pedido e veja se falha ou se usa silenciosamente a ligação física.

O resultado de um portátil não se transfere para um telefone ou router. APIs de plataforma diferentes, valores predefinidos diferentes, e no Android a diferença é flagrante: o always-on com bloqueio é imposto pelo sistema e não pelo cliente, por isso continua a funcionar quando o cliente não o faz. O guia de VPN do Android descreve essa separação.

Mantenha um caminho de volta

O bloqueio ao nível do sistema tem o modo de falha oposto. Filtros que sobrevivem ao cliente podem deixar uma máquina sem rede nenhuma após uma desinstalação, o que é um contacto de suporte sem causa óbvia. Antes de ativar qualquer kill switch que escreva regras de plataforma, anote como é removido, e guarde o caminho de reparação do fornecedor onde o possa encontrar.

Se não consegue responder às verificações de falha súbita, IPv6, DNS e transição para o seu cliente, trate-o como um interruptor ao nível da aplicação com buracos conhecidos e planeie em conformidade.