Túnel completo do WireGuard: AllowedIPs 0.0.0.0/0 não basta

Colocar 0.0.0.0/0, ::/0 nos AllowedIPs de um par é o passo que todos lembram, e ele só decide qual tráfego o par pode transportar. Esses prefixos não criam rotas, não encaminham nada do outro lado e deixam o resolvedor de cada aplicação exatamente onde estava. Quatro coisas separadas precisam valer ao mesmo tempo para que um túnel completo seja completo, e o melhor é verificá-las na ordem abaixo, porque uma verificação posterior não pode salvar uma anterior. Cada verificação abaixo é um fato que pode ser lido de uma máquina, não um ajuste que você espera que tenha sido aplicado.

O que o prefixo do par seleciona, e o que não seleciona

AllowedIPs é ao mesmo tempo um seletor e uma autorização. Diz ao lado local quais destinos podem ser enviados a este par, e diz ao lado receptor quais endereços de origem este par pode apresentar. Esse é todo o trabalho. Nada nessa descrição cria uma rota no host, ativa o encaminhamento no lado remoto nem toca na resolução de nomes.

Por isso uma configuração pode parecer completa e se comportar como um túnel dividido. O prefixo diz que o par aceitaria tudo; a tabela de rotas do host decide o que realmente chega lá, e a gateway decide se algo sai. Nenhuma dessas três decisões mora na seção do par.

Rotear o cliente, não apenas a lista de pares

Gestores como wg-quick programam a tabela de rotas do host por você, e é por isso que dois arquivos de configuração idênticos se comportam de forma diferente conforme a interface subiu. Um perfil mínimo é curto o bastante para ler de uma vez:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Dois detalhes carregam o trabalho. O campo Address é um único prefixo de host em vez de uma sub-rede que o cliente acredita possuir, e é o gestor que converte os AllowedIPs padrão em uma rota padrão real. Suba o mesmo arquivo com ip link e wg setconf e não aparecerá nenhuma rota, o que parece um túnel quebrado e na verdade é um túnel saudável com o passo de roteamento pulado. O manual do wg-quick documenta o roteamento e o Table comportamento que esses gestores adicionam.

Leia o resultado em vez do arquivo: ip route get 1.1.1.1 deveria nomear a interface do túnel, e wg show deveria relatar um handshake recente com um contador de transferência que se move. Um handshake sem rota significa que o gestor nunca rodou, e editar o perfil de novo não vai corrigir isso. Inicie a interface como o usuário vai iniciá-la, ou o teste mede o seu shell em vez da implantação.

Manter o endpoint fora do túnel

Um túnel completo captura cada destino, incluindo aquele com que precisa falar para existir. Os gestores resolvem isso adicionando uma rota de host para o endpoint através da gateway original, e é por isso que uma configuração correta quase sempre contém uma exceção deliberada. Aplicar metade da configuração com um gestor e a outra metade à mão é a forma habitual de essa exceção se perder.

Se o endpoint é um nome de host que resolve para vários endereços, ou para uma família que você não transporta, a exceção envelhece mal e o túnel pode falhar após uma reconexão que parecia rotineira. Fixe o endpoint a um endereço que você controla, ou confirme que o gestor o reavalia, e releia a rota de host após cada mudança de rede.

O mesmo mecanismo explica por que um túnel completo e um portal cativo brigam. O portal espera interceptar o tráfego que o seu túnel agora captura, então em redes de hotel e aeroporto você sobe o túnel após o login no portal, nunca antes.

Encaminhamento e caminho de volta na gateway

Na gateway, ative o encaminhamento para a família que você transporta, permita a cadeia forward nos dois sentidos quando traduz, e confirme o caminho de volta com uma consulta específica da origem. Nada disso decorre de um handshake bem-sucedido, porque um handshake só prova que os dois pares podem trocar UDP. Ele não diz nada sobre o que acontece depois com o pacote desencapsulado.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

A consulta roda na gateway e não no cliente, ou você lerá outra tabela de rotas. Se ela nomear a interface errada, ou informar que não há rota, então nenhuma mudança no lado do cliente produzirá saída para a internet. Quando a gateway traduz os endereços dos clientes na saída, a resposta depende desse estado de tradução, então a regra precisa existir para os dois sentidos do fluxo e não apenas para o de saída.

DNS e o estado de falha, testados separadamente

O protocolo em si não configura o resolvedor de nenhuma aplicação. wg-quick aplica a linha DNS por meio da integração do resolvedor da distribuição, contêineres e navegadores com suas próprias pilhas podem ignorá-la, e por isso um nome pode falhar enquanto o túnel transporta pacotes perfeitamente. Teste com um nome de host em vez de um endereço, e anote qual servidor respondeu em vez de supor que foi o do perfil.

As famílias de endereços são um teste separado com uma resposta separada. Uma rota padrão v4 não diz nada sobre o que a conexão v6 de uma aplicação fará, e um túnel que vaza silenciosamente a segunda família é pior do que um que falha ruidosamente. Consulte um nome por cada família, leia a interface usada por cada pedido, e verifique os contadores de tradução antes e depois, porque uma regra que não corresponde a nada parece idêntica a uma regra ausente.

Por fim, teste o estado que você quer quando o túnel para. Um túnel completo deve falhar fechado para o tráfego que reivindica: se a interface cai e as aplicações continuam em silêncio pelo link físico, o desenho é um túnel dividido com passos extras. Escreva o comportamento de falha pretendido, verifique-o de propósito, e termine registrando as quatro respostas — qual gestor sobe a interface, qual rota carrega a padrão, quem encaminha e traduz na gateway, e qual resolvedor responde.