O handshake do WireGuard funciona mas não há internet: siga o pacote

O túnel está ativo, o wg show informa um handshake recente, você consegue pingar o endereço do túnel do servidor, e nada além disso responde. O instinto é regenerar as chaves ou compartilhar a configuração de novo. Isso muda justamente a parte do caminho que já está provada como funcional.

Um handshake concluído diz que os dois pares concordam sobre as chaves, que o UDP chega ao endpoint e que o roteamento criptográfico aceita o pacote. Não diz nada sobre se o pacote pode sair do servidor depois.

Então siga um pacote em vez de adivinhar. Há quatro lugares onde ele pode morrer, e cada um deixa um rastro diferente.

O que o handshake realmente prova

O WireGuard é um protocolo UDP que estabelece uma sessão com um handshake Noise e depois cifra os pacotes de um par. Quando o wg show mostra um handshake de alguns segundos e um contador de transferência crescente, o endpoint, as chaves e a chave pública do par estão todos corretos.

O que ele não prova é que o seu cliente envie tráfego voltado à internet para a interface, que o servidor esteja disposto a encaminhá-lo ou que uma resposta encontre o caminho de volta. Essas são decisões de roteamento do kernel e do firewall, e são tomadas fora do túnel.

É por isso que pingar o endereço do túnel do servidor é um teste tão enganoso. Esse pacote é endereçado ao próprio servidor, então termina localmente. Ele nunca precisa de encaminhamento, nunca de tradução e nunca de uma rota de volta da internet.

AllowedIPs é uma decisão de roteamento

No cliente, o AllowedIPs faz dois trabalhos. É a tabela de roteamento por chave criptográfica que decide quais endereços de destino entram no túnel deste par, e é a lista de endereços de origem que o par aceitará de você. Se a configuração do cliente listar só 10.8.0.0/24, destinos públicos nunca entram na interface e a sua rota padrão normal os leva para fora do túnel. Então o túnel funciona perfeitamente e não faz nada do que você queria.

Olhe o que o cliente realmente instalou em vez do que o arquivo de configuração diz:

wg show wg0 allowed-ips
ip route get 1.1.1.1

O segundo comando é o decisivo. Se a resposta nomear a sua interface física e o gateway habitual, o pacote não está sendo tunelado e nenhuma mudança do lado do servidor vai consertar isso. Adicione 0.0.0.0/0 para IPv4 e ::/0 para IPv6 separadamente; uma regra que pega tudo para uma família deixa a outra no caminho original, e essa é uma causa comum de um túnel IPv4 que funciona e de uma consulta IPv6 travada.

Onde o pacote morre no gateway

Se a rota está correta e o pacote continua sem ir a lugar nenhum, ele chega ao servidor e para ali. Quatro verificações cobrem a maioria dos gateways.

Encaminhamento. O sysctl net.ipv4.ip_forward retornando 0 é a resposta clássica, e muitas distribuições continuam em 0 por padrão. Tem que ser 1, e definido de forma persistente num arquivo sysctl em vez de um comando que desaparece no reinício. O encaminhamento de IPv6 é um interruptor separado.

A política de filtragem. Uma cadeia FORWARD com política de descarte padrão vai descartar o tráfego do túnel enquanto permite o tráfego para o próprio host, o que corresponde exatamente ao sintoma. Leia o conjunto de regras vivo, não um arquivo salvo: nft list ruleset ou iptables -S.

Tradução ou roteamento. Clientes com endereços de túnel privados precisam ou de NAT de origem na interface de saída do servidor, ou de um prefixo roteado que a rede superior saiba devolver. A escolha entre os dois segue o plano de endereços. Adicionar MASQUERADE a uma rede que já roteia o seu prefixo de volta é inofensivo mas inútil, e omiti-lo onde não existe rota deixa as respostas endereçadas a uma faixa privada não roteável.

O caminho de volta. Em desenhos roteados, o roteador superior precisa de uma rota que aponte para o seu servidor. A rede do provedor também pode bloquear: várias nuvens ativam uma verificação de origem e destino na instância, que descarta silenciosamente pacotes cuja origem não é o endereço da própria instância até essa verificação ser desativada.

O DNS falha de forma diferente do roteamento

Um pacote para um endereço conhecido e uma consulta de nome são duas falhas separadas, e as mensagens de erro enganam em direções opostas. Se o ping 1.1.1.1 funciona e um navegador não carrega nada, a rota está bem e a resolução de nomes não. Se o ping em si falha, o DNS é irrelevante e você volta à seção anterior.

O wg-quick pode definir um resolvedor a partir da linha DNS = na configuração, e o systemd-resolved tem o próprio comportamento por enlace. Uma VPN que sobrescreve o resolvedor com um endereço só alcançável dentro do túnel vai falhar toda consulta no momento em que o túnel cair, o que parece que o túnel está quebrando a internet.

Uma ordem que produz evidência

Execute primeiro a verificação do lado do cliente, porque é um comando só e elimina metade das possibilidades. Depois confirme se o servidor é mesmo pensado como saída para a internet; um gateway feito para acesso privado não está quebrado quando destinos públicos falham.

No servidor, observe a interface enquanto envia um ping do cliente: o tcpdump -ni wg0 icmp deve mostrar a requisição, e o tcpdump -ni eth0 icmp deve mostrar que ela sai, traduzida ou não. Se aparecer no primeiro e nunca no segundo, a parada é local no servidor. Se sair e nenhuma resposta voltar, o problema está acima, e essa é outra conversa.

Por fim, faça a correção sobreviver a um reinício. O encaminhamento pertence a um arquivo sysctl, as regras do firewall pertencem ao serviço que as carrega, e as rotas do cliente pertencem à configuração que levanta a interface em vez de um shell que você vai esquecer. Reconecte, repita os mesmos dois testes e confirme que os contadores se movem.