O WireGuard não mostra nenhum handshake recente: o que verificar primeiro

Um campo de último handshake vazio normalmente significa que a interface não concluiu nenhum handshake desde que subiu, o que diz menos sobre a configuração do que parece. O WireGuard fica em silêncio até que um pacote precise sair pela interface, então um peer ocioso sem nada a enviar relata exatamente isso. Estabeleça se algo foi realmente oferecido antes de inspecionar as chaves.

O teste é um pacote permitido para um destino que o peer deve transportar. Todo o resto nessa tela de status descreve intenção, não atividade.

Uma interface ociosa não tem nada a relatar

O WireGuard faz handshakes preguiçosamente: o primeiro pacote que precisa do túnel aciona a troca, e a interface fica silenciosa até então. Um peer configurado e nunca usado mostra um handshake vazio, zero bytes recebidos e um intervalo crescente desde o último. Esse estado é saudável para um cliente ocioso e alarmante apenas se você esperava que o tráfego já tivesse fluído. Verifique também os contadores de transferência, porque eles separam nada-enviado de tentado-e-falhou.

Se os contadores estiverem em zero dos dois lados, o problema está acima do túnel. Nada chegou à interface para acionar nada.

Acione o tráfego que o peer tem permissão de transportar

Escolha um endereço dentro dos prefixos permitidos do peer, na máquina local, e confirme que a tabela de rotas o enviaria pela interface. Um destino fora desses prefixos produz uma solicitação roteada comum sem qualquer envolvimento do WireGuard. Use um serviço que responda rápido, como um ping ou uma conexão TCP curta, para que a tentativa tenha um começo e um fim visíveis. Depois leia a linha do handshake novamente em vez de olhar para a tela e esperar.

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

A consulta de rota importa mais que o ping. Se ela indicar a interface física, o pacote nunca entrou no túnel e o handshake vazio é uma resposta de roteamento, não criptográfica. Conserte a rota antes de depurar o peer.

Compare o par de chaves e o endpoint

Quando o tráfego é realmente oferecido, a identidade é a próxima verificação. A chave privada local deve corresponder à chave pública autorizada pelo outro lado, a chave pública remota configurada deve identificar o peer pretendido e qualquer chave pré-compartilhada deve coincidir nas duas pontas. Uma única diferença de caractere numa chave base64 produz um peer que parece configurado e nunca conclui uma troca. Compare com o registro de provisionamento em vez de regenerar chaves, porque uma chave nova invalida todos os peers que confiavam na antiga.

O endpoint exige o mesmo exame: nome do host, endereço, porta UDP e a família usada para alcançá-lo. Um endereço obsoleto ou a porta errada produzem silêncio em vez de mensagem.

Acompanhe o caminho UDP externo

O handshake viaja como UDP até o endpoint, então o caminho externo precisa transportá-lo. Os comandos abaixo verificam se existe um ouvinte, se a pilha local emitiu o datagrama e qual endpoint está configurado. Execute a captura enquanto aciona o tráfego, não antes.

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

Uma captura que mostra o início sem resposta aponta para fora da máquina, porque o outro lado ou não escuta, ou está filtrado, ou está endereçado incorretamente. Uma captura que não mostra nada significa que o pacote nunca saiu, o que o leva de volta à rota e a qualquer marca de socket em jogo. Quando administra as duas pontas, correlacione a tentativa por carimbo de tempo com uma captura estreita no servidor em vez de uma geral. Um teste de porta TCP não prova nada aqui, porque o protocolo é apenas UDP.

Assim que um handshake aparecer, teste uma aplicação através do túnel, porque uma troca concluída prova identidade e alcance, não vazão utilizável ou DNS correto. Guarde a saída de status antes e depois da mudança, e a diferença se torna sua evidência.