WireGuard envia dados mas não recebe nada de volta: qual lado?

Contadores de transmissão que sobem enquanto o contador de receção fica em zero descrevem uma direção, não um diagnóstico. A mesma leitura aparece quando o par nunca concluiu um handshake, quando o destino escolheu o par errado, quando o lado remoto não tem rota de volta e quando um filtro descarta a resposta a caminho de casa. Cada um destes casos repara-se num local diferente.

A comparação que encurta o trabalho é entre um pedido que nunca saiu do túnel e uma resposta que nunca voltou. Uma captura na interface correta decide entre as duas.

Os contadores descrevem volume, não a direção da avaria

Os contadores do WireGuard registam o que a interface entregou ao par e o que recebeu dele. Não dizem qual destino, qual par ou qual metade de uma troca falhou. O tráfego de fundo torna os totais ainda menos informativos, já que alguns bytes podem ser mensagens de manutenção ou fluxos não relacionados. Leia-os como um indício de que a interface está ativa e depois deixe de os tratar como prova.

O primeiro dado útil é saber se o handshake está atual. Sem ele nada foi cifrado para este par e o contador de receção não tem motivo para se mover.

Seleção do par ou caminho da resposta: duas explicações

A primeira explicação é que o pacote nunca chegou ao par pretendido, porque a rota apontava para outro sítio ou porque os prefixos permitidos do par não cobriam o destino. A segunda é que o pacote chegou e a resposta não conseguiu voltar, o que é um problema de encaminhamento no extremo remoto. A tabela separa as duas pelo que observaria em cada ponto.

Leia a tabela de cima para baixo. Um handshake ausente envia-o para as chaves, os extremos e o caminho exterior, porque ainda não há mais nada para examinar. Um handshake atual com o pedido visível no servidor desloca o problema para a direção de retorno, onde decide a própria tabela de rotas do destino. Um pedido que nunca aparece no servidor é um problema de seleção, e os prefixos permitidos nos dois pares são a primeira coisa a comparar.

Duas destas quatro linhas reparam-se no cliente e duas no servidor. Saber em que par está é a maior parte do trabalho.

Onde desaparecem as respostas

Uma resposta sai do destino, chega à interface de túnel do servidor e é cifrada para o par cujos endereços permitidos coincidem com o endereço interno do cliente. Se essa correspondência falhar, a resposta é descartada em silêncio, o que do lado do cliente parece exatamente uma avaria de rede. Se a resposta estiver cifrada e o próprio filtro do cliente a rejeitar, o sintoma volta a ser idêntico. Os dois casos precisam da captura e não do contador.

A forma mais forte deste erro é um servidor que reencaminha pacotes pelo cliente mas não tem rota de volta para o intervalo interno do cliente. Aceita o pedido, envia a resposta para o seu gateway predefinido e o túnel nunca a vê. Uma regra de tradução ampla acrescentada ao servidor esconde essa avaria em vez de reparar a rota.

Teste um único destino de ponta a ponta

Escolha um único destino dentro do intervalo do par e teste-o enquanto o handshake for comprovadamente atual. Os comandos abaixo leem o estado do par, a rota escolhida e os dois lados da troca. Execute a captura na interface que os pacotes cifrados realmente usam.

wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5

Uma captura que mostra o pedido na interface de túnel sem nada a voltar é uma resposta do lado do servidor, e a tabela de rotas do destino é o próximo local a observar. Se não aparecer absolutamente nada, o pacote seguiu outro caminho, por isso a rota local é a suspeita. Uma troca visível nas duas capturas sem progresso na aplicação desloca a questão para o tamanho dos pacotes ou para um filtro que as estatísticas da interface nunca mostram. Mantenha um destino e um cliente no teste, porque uma segunda variável transforma a prova outra vez numa impressão.

Se os nomes falharem enquanto um endereço permitido funciona, a resposta está no DNS e não no túnel. Se apenas as transferências grandes bloquearem, examine o tamanho dos pacotes em separado.