O peer do WireGuard sai pela WAN errada: cinco verificações em ordem

Dois uplinks, um gateway e um peer do WireGuard cujo tráfego continua a surgir na linha de reserva. O handshake mantém-se saudável o tempo todo. Por isso o sintoma é fácil de ler mal como falha do WireGuard em vez de falha de encaminhamento.

Execute as verificações abaixo por ordem. Cada uma tem uma condição de paragem, e saltar à frente costuma produzir uma resposta errada e confiante.

Separe o handshake do fluxo encaminhado

A troca cifrada com o peer tem uma rota de ponto final para o endereço público do servidor. O tráfego encaminhado do cliente tem outro destino e pode ser selecionado por marcas ou regras de política. São duas decisões de encaminhamento que partilham uma interface. Tratar uma como prova sobre a outra é o primeiro erro.

Pare assim que se apanhar a raciocinar a partir do handshake. É prova apenas sobre o caminho do ponto final.

Leia a regra de política, não a tabela predefinida

Uma tabela predefinida mostra o que acontece quando nenhuma regra de política corresponde. Num gateway que encaminha por origem, marca ou destino, a regra decisiva vive noutro lugar. A tabela simples pode parecer perfeitamente razoável enquanto a escolha real é feita acima dela.

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

Leia as regras de política e as tabelas para onde apontam. Depois confirme qual regra corresponde ao seu fluxo de teste. Uma regra que referencia uma interface que já não transporta o uplink pretendido é um achado, não um detalhe. A consulta de rota no fim mostra a resposta muito mais depressa do que ler uma tabela e adivinhar.

Verifique a marca e a tradução em conjunto

O encaminhamento por política baseia-se numa marca de pacote definida antes na cadeia. Se a regra de marcação deixar passar o seu tráfego, o fluxo cai na tabela principal e sai pelo que lá estiver por omissão. Os pacotes encaminhados saltam frequentemente cadeias escritas para tráfego gerado localmente.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

A tradução tem de concordar com o uplink que transporta o fluxo. Uma regra que traduz para o endereço primário enquanto o pacote sai pela linha de reserva produz respostas dirigidas a uma interface que o fluxo nunca usou. Verifique a condição de interface da própria regra de tradução. Uma regra incondicional funciona até o segundo uplink ser usado, e falha depois de uma forma que parece intermitente.

Observe qual interface transporta a resposta

Capture nos dois uplinks enquanto um pedido está a correr. Registe qual interface transporta o pedido e qual transporta a resposta. Os caminhos assimétricos são muito mais fáceis de ver do que de prever.

Se a resposta chegar pelo uplink errado, o problema passou do WireGuard para o rastreio de ligações ou para a tradução. Nenhuma alteração à configuração do peer o resolverá.

Altere uma coisa com um caminho de volta

Mantenha acesso por consola ou fora de banda antes de editar regras de política num gateway. Faça uma só alteração, teste o mesmo destino autorizado, depois volte a ligar e confirme que o handshake ainda usa o caminho de ponto final pretendido. Acrescente um teste numérico na segunda família de endereços, porque uma política apenas para v4 deixa o mesmo erro disponível.

Registe qual uplink cada fluxo usou. Esse registo transforma o relatório seguinte numa verificação de dois minutos em vez de uma tarde inteira. as notas do WireGuard sobre espaços de nomes e encaminhamento descrevem como separar deliberadamente o caminho do ponto final do tráfego tunelizado, o que costuma ser mais limpo do que copiar uma volta com rota predefinida.