O WireGuard só funciona depois que o servidor envia: conhecimento do endpoint

O túnel parece funcionar só depois que o servidor envia algo primeiro. Inicie pelo cliente e nada acontece, espere alguns segundos, tente de novo e funciona. O diagnóstico habitual é um NAT quebrado, e o diagnóstico habitual está errado. O que mudou é que um par aprendeu onde o outro mora.

Conhecimento do endpoint, não acessibilidade

Um par do WireGuard não iniciará um handshake até saber para onde enviá-lo. A configuração fornece isso como um endpoint de endereço e porta, e o estado em execução acompanha o endpoint em que acredita no momento.

wg show mostra os dois lados dessa imagem, e um par sem endpoint na saída não pode iniciar nada, por mais corretos que sejam sua chave pública e seus prefixos permitidos. Compare a visão do cliente com a do servidor antes de mudar qualquer regra, porque os dois frequentemente discordam sobre quem sabe o quê.

Como um par aprende um endpoint

O WireGuard é deliberadamente silencioso. Quando um pacote autenticado corretamente chega de um endereço que o par não esperava, a implementação atualiza o endpoint desse par para a nova origem, e é assim que o roaming funciona em um notebook que troca de rede. Esse comportamento explica a dependência da direção: se o servidor envia primeiro e seu pacote chega ao cliente, o cliente aprende o endereço atual do servidor e pode responder. Até então não tem para onde enviar. O mecanismo é roaming autenticado e não um atalho de confiança no primeiro uso, porque o pacote precisava ser válido antes de o endpoint mudar.

A documentação das ferramentas para wg descreve essa atualização, e vale uma leitura se você pretende projetar em torno disso.

A tradução com estado acrescenta sua própria direção

Onde o UDP passa por um gateway que traduz, o gateway cria estado para o primeiro pacote que vê. RFC 4787 descreve esse comportamento e os tempos limite que acabam removendo o mapeamento. Um mapeamento inativo expira, e um pacote de entrada do lado distante então é descartado pelo gateway antes de chegar ao host. Um túnel que funcionava a manhã toda para de responder à tarde exatamente por esse motivo.

Este é um segundo mecanismo independente que produz o mesmo sintoma direcional. Tanto o conhecimento do endpoint quanto o estado de tradução precisam estar corretos, e consertar um não conserta o outro.

Configure a direção que você realmente quer

Para um cliente que precisa iniciar a conexão, coloque o endpoint do servidor na seção de pares do cliente e deixe-o ali. Contar com o envio do servidor primeiro é contar com um acidente na ordem do tráfego que mudará em uma rede silenciosa. A configuração deveria declarar a direção pretendida, não descobri-la.

Para um par atrás de tradução que precisa continuar acessível, ative um keepalive persistente desse lado. Um keepalive a cada 25 segundos é o valor inicial habitual, e seu propósito é manter o mapeamento aberto em vez de testar o túnel. Escolha um só lado para carregá-lo, porque ativá-lo dos dois lados dobra o tráfego e o ruído dos registros sem melhorar o resultado.

Compare o estado antes e depois do gatilho

Capture as duas visões no momento em que falha e depois novamente após o servidor enviar. O primeiro comando mostra endpoints e a idade do handshake. O segundo mostra se existe uma entrada de tradução para a porta. A captura mostra qual direção realmente atravessou o cabo, e a verificação de rota confirma que o cliente não envia esse tráfego para outro lugar completamente diferente.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Anote a coluna do endpoint e a entrada de tradução juntas. Um par sem endpoint e um gateway sem mapeamento são duas falhas diferentes. Apenas uma delas é corrigida por um keepalive.