Por que um kill switch corta o tráfego quando você troca de servidor

Você escolhe um servidor que parece mais perto, clica em conectar, e o navegador para de carregar antes de o novo túnel subir. O ícone muda para um estado de conexão e fica ali enquanto cada aba expira. Essa pausa costuma ser o kill switch funcionando como projetado: o tráfego fica bloqueado enquanto o cliente não tem um túnel por onde enviá-lo. Se a pausa é aceitável depende do que o cliente faz nesses segundos e de o bloqueio ser removido quando ele diz que é.

O que o cliente faz entre dois servidores

Trocar de ponto de extremidade são vários passos, não um interruptor. O cliente desmonta o túnel atual, atualiza as regras de bloqueio, resolve e alcança o novo ponto de extremidade fora do túnel, e então instala as novas rotas e levanta o bloqueio. A lacuna que você sente fica entre o primeiro e o último passo.

A ordem importa mais que a velocidade aqui. Se as regras de bloqueio entrarem antes da exceção para o novo ponto de extremidade, o cliente não consegue completar o handshake e fica em conectando até um tempo limite. Se a exceção for uma cópia do endereço do servidor antigo, o novo handshake parece qualquer outro pacote de saída e é descartado. Os dois casos parecem iguais no navegador, e por isso uma troca que se recupera em seis segundos e outra que nunca se recupera podem compartilhar a mesma causa.

O novo ponto de extremidade precisa de um furo no bloqueio

Para construir o túnel, o cliente precisa enviar pacotes ao endereço e à porta do novo servidor pela interface física, por exemplo UDP 51820 num perfil típico de WireGuard ou 1194 e 443 para OpenVPN, seja o que for que o seu perfil especifique. Esse tráfego não está dentro do túnel que está prestes a ser criado, então um bloqueio para o dispositivo inteiro o engole, a menos que exista uma regra de permissão correspondente.

Perfis baseados em nome de host acrescentam um segundo requisito: a própria consulta. Se o cliente resolve o ponto de extremidade antes de o bloqueio subir, pode usar um endereço em cache, mas quando o perfil troca os endereços ou a entrada de cache fica velha, o handshake vai para um endereço que a regra de permissão não cobre. O IPv6 torna isso visível, porque um ponto de extremidade de pilha dupla pode publicar tanto um registro A quanto um AAAA, e uma regra de permissão que só cobre o endereço v4 deixa o cliente tentando de novo contra um endereço v6 bloqueado.

Os nomes das opções e os valores padrão variam conforme o cliente e a versão, então leia a lista documentada do seu em vez de adivinhar por capturas de tela. A referência de configurações do OpenVPN Connect em openvpn.net/connect-docs/app-settings-windows é um exemplo de como um cliente descreve suas opções de bloqueio e de túnel dividido.

Fail-closed é uma máquina de estados, não um interruptor

A maioria dos clientes expressa o bloqueio como política de firewall em três estados: túnel no alto, com o tráfego passando pelo túnel e sem bloqueio; túnel em baixo, com o bloqueio ativo; e transição, com o bloqueio ativo mais exceções temporárias para o ponto de extremidade. É no terceiro estado que os bugs moram, porque ele precisa mudar duas vezes em poucos segundos, e não sair dele parece exatamente um bloqueio permanente.

O mecanismo varia conforme a plataforma, e a falha também. Os filtros do Windows Filtering Platform têm pesos, então um filtro de bloqueio que supera a sua permissão continua descartando pacotes mesmo que a permissão exista, e os filtros deixados por um processo de cliente morto podem manter a máquina sem conexão depois que o aplicativo some. Os clientes de macOS costumam escrever regras pf num anchor, onde a ordem das regras e as decisões rápidas decidem qual regra se aplica. Os clientes de Linux costumam gerenciar uma cadeia nftables ou iptables com política drop e permissões explícitas para o ponto de extremidade, a interface do túnel e o loopback. A VPN sempre ativa do Android com a opção de bloquear conexões sem VPN é a mais rígida do grupo, porque o sistema aplica o bloqueio ao dispositivo inteiro e não por aplicativo.

O WireGuard merece uma nota própria, porque AllowedIPs é um seletor de roteamento, não um bloqueador. Ele decide quais destinos entram no túnel; não faz nada para impedir que um pacote ainda sem túnel saia pelo Wi-Fi. Numa configuração só com WireGuard e sem regra de firewall, o kill switch é na verdade a ausência de uma rota, e depois de um handshake descartado um pacote real pode sair pela interface física.

Meça a lacuna em vez de olhar o ícone

Observe os pacotes, não a luz de status. No Linux, inicie um ping lento contra um endereço público num terminal e capture a porta de transporte do túnel na interface física em outro:

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

Troque de servidor no cliente enquanto os dois rodam. Três coisas importam: quanto tempo os pings param, se a captura mostra o handshake chegando ao novo ponto de extremidade e se o tráfego volta antes ou depois de o estado do cliente mudar para conectado. Se a lacuna dos pings terminar primeiro, ou o bloqueio foi removido cedo demais ou o túnel já está no alto antes de o indicador admitir isso. Se a lacuna terminar depois, o indicador é otimista demais.

No Windows, netsh wfp show state grava um instantâneo em que você pode procurar filtros de bloqueio que ainda existem enquanto o cliente afirma estar desconectado. No macOS, sudo pfctl -sr lista as regras carregadas e a ordem delas. Combine qualquer um dos instantâneos com o log do próprio cliente; a linha do tempo do seu ping diz se o bloqueio terminou tarde ou nunca terminou.

Apagão normal contra bloqueio travado

Alguma interrupção é o propósito do recurso, então faça a triagem antes de mudar qualquer ajuste:

Se você cair na segunda ou na quinta linha, não desative o kill switch para testar, porque isso transforma um bug de roteamento em vazamento. Reinicie o serviço do cliente, ou reinicie a máquina onde os filtros sobrevivem à morte do processo, e veja se o bloqueio se limpa. Se limpar, a falha está na limpeza durante a troca e não no bloqueio em si.

Antes da próxima troca, confirme quatro coisas: a permissão do ponto de extremidade cobre cada família de endereços que o seu perfil resolve, o log do cliente mostra a transição concluída, seu teste de ping mede a lacuna e não o ícone, e fechar o cliente restaura a conectividade normal. Um kill switch que segura durante a troca e solta depois faz o trabalho dele. Um que solta cedo, ou nunca, vale a pena depurar.