O kill switch bloqueia o servidor VPN antes de qualquer tráfego fluir
Que etapa um kill switch bloqueia: resolução do endpoint, rota externa, caminho de volta e exceções de pares obsoletas — com contadores em vez de suposições.
Os kill switch falham numa direção que as pessoas não esperam: são feitos para bloquear tráfego enquanto o túnel está em baixo, e os pacotes que constroem o túnel são eles próprios tráfego. É todo o erro. Um conjunto de regras que descarta tudo o que não sai pelo túnel também descarta o handshake que deveria levantá-lo, por isso o cliente tenta novamente em ciclo e o erro é atribuído à etapa que é verificada primeiro. Antes de alargar uma firewall, descubra qual das três etapas está a ser negada: a resolução do nome, o pacote exterior para o par ou a resposta que regressa.
Como o túnel e o seu próprio transporte dependem um do outro
Leia um cliente VPN como dois estados de rede que partilham um único caminho de socket. Antes de o túnel existir, o cliente abre um socket no adaptador físico e envia tramas cifradas para o endereço e a porta do par. Só depois de essa troca ter êxito é que cria o dispositivo de túnel e instala as rotas. Um kill switch é uma política sobre o segundo estado, escrita de forma tão ampla que se aplica aos dois.
As regras baseadas na interface são a forma habitual: aceite o que sai por tun0 ou wg0, descarte o resto do caminho de saída. Essa formulação não consegue isentar a própria ligação do cliente ao servidor, por isso uma implementação correta acrescenta essa exceção explicitamente, e você também o faz quando escreve regras à mão. As regras por aplicação no Windows e no macOS evitam parte disto ao corresponder a um processo em vez de uma interface, mas o processo continua a ter de sair antes de o túnel existir.
Três etapas, na ordem em que acontecem
A primeira etapa é a resolução. Quando o perfil guarda um nome de host em vez de um endereço literal, o cliente precisa de uma resposta DNS antes de poder enviar seja o que for. Um perfil que aponta o DNS para o resolver do túnel cria um impasse: o resolver só é alcançável através do túnel que a consulta deveria ativar. Resolver fora do túnel, ou fixar o endpoint a um endereço, elimina a ambiguidade.
A segunda etapa é o pacote exterior, que tem de sobreviver primeiro ao encaminhamento e depois à firewall, nessa ordem. O wireguard-tools trata da metade de encaminhamento disto para o WireGuard, marcando os seus próprios pacotes e acrescentando uma regra de política para que saltem a rota predefinida que acabou de instalar; a página de manual do wg-quick descreve essa regra e a tabela que utiliza. Reconstrua esse encaminhamento à mão, ou deixe uma segunda ferramenta reescrever as regras, e os pacotes marcados podem ser enviados de volta para o túnel que deveriam estabelecer.
A terceira etapa é o caminho de volta. Um handshake sem resposta não é prova de um descarte de saída; é igualmente compatível com uma regra de entrada do servidor ou com um dispositivo NAT que esqueceu o mapeamento. Separe isso antes de tocar no cliente.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Os clientes registam o sintoma que detetam, não a etapa que falhou, por isso a tabela costuma ser mais rápida do que o registo.
Os contadores decidem mais depressa do que os registos
No Linux, nft list ruleset ou iptables -vnL OUTPUT imprime um contador de pacotes por regra. Ligue-se uma vez, deixe falhar e volte a ler os contadores. Uma regra cujo contador se moveu é uma regra que o handshake atingiu; se nada se moveu em lado nenhum, o pacote nunca chegou à firewall. Já vi um conjunto de regras descartar o seu próprio handshake, e só os contadores o disseram.
Para distinguir nunca chegou à firewall de nunca saiu do host, observe a própria interface. ip -s link show dev wlan0 reporta os pacotes enviados, e tcpdump -ni wlan0 udp port 51820 mostra as tramas. Se ficar plano enquanto o cliente tenta novamente, a falha está acima do netfilter: falta uma rota do par, uma regra de política aponta para um dispositivo que ainda não existe, ou há um erro de socket que o cliente engole.
Teste as exceções com endereços de documentação como 203.0.113.10, para que um lapso não possa sondar o host de outra pessoa.
Uma exceção de endpoint obsoleta lê-se como uma falha do servidor
A versão mais enganadora aparece depois de o endereço do par mudar: um serviço de endereços dinâmicos moveu-o, o host foi reconstruído, ou o endereço de saída da sua rede é diferente. A exceção ainda nomeia o endereço antigo, por isso os pacotes para o novo caem na regra de descarte. A mesma configuração funcionava ontem, e é por isso que as pessoas começam por diagnosticar o servidor.
Um nome de host dentro de uma regra de firewall não o salva. No nftables o nome é resolvido quando o conjunto de regras é carregado, por isso fixa o endereço que existia nesse momento e torna-se obsoleto como um literal. A solução duradoura é atualizar a exceção quando o endpoint muda e mantê-la estreita: um endereço de par, uma porta de transporte. Um intervalo suficientemente largo para sobreviver a uma mudança de endereço também é largo o suficiente para deixar sair tráfego não relacionado.
Quando o kill switch corre no host do servidor
A mesma dependência existe no outro extremo, e aí é mais fácil deixá-la passar. Se a máquina que serve de servidor VPN também executa um cliente de ambiente de trabalho com kill switch, ou um perfil de firewall copiado de um portátil, as suas regras de descarte aplicam-se ao serviço que termina os túneis. As respostas ao handshake de um cliente são descartadas, por isso todos os clientes não conseguem ligar-se enquanto o servidor parece saudável e a sua interface de túnel fica sem uso.
Esse host precisa de três aceitações estreitas antes do descarte: a porta de escuta na interface física, a interface de túnel para o tráfego decifrado e o reencaminhamento do túnel para aquilo que os clientes devem alcançar. Leia o conjunto instalado com nft list ruleset, iptables -S, ou pfctl -sr antes de mudar seja o que for, e lembre-se de que um conjunto de regras guardado sobrevive a um reinício, por isso um erro ali sobrevive ao processo que o fez.
Ordem de recuperação que mantém a máquina fechada
Trabalhe de dentro para fora a partir do perfil. Leia o endereço e a porta do par que o cliente usa, confirme que o nome de host é resolvido sem o túnel e depois acrescente uma exceção para esse endereço e porta apenas no adaptador físico. Volte a ligar-se e observe o contador de envio; um handshake concluído é o sinal de que a segunda etapa está reparada.
Deixe o resto da política de descarte no lugar enquanto testa. Uma verificação inofensiva é tentar uma ligação a um endereço de documentação não relacionado e confirmar que continua a expirar, o que mostra que o kill switch funciona e não que está desligado. Aperte a exceção quando o túnel estiver estável, e não deixe uma autorização permanente de tudo para o binário do cliente só porque é cómodo.
Se o túnel subir e a aplicação continuar a falhar, as etapas restantes não são esta: o DNS dividido, a MTU e o encaminhamento por aplicação produzem cada um um túnel ligado com tráfego quebrado, e cada um tem uma primeira verificação diferente.