Um par de WireGuard inacessível enquanto outro funciona: lista de verificação

Um par de WireGuard passa tráfego e um segundo completa o handshake mas nunca alcança nada atrás do túnel. O par que funciona diz-lhe que a interface, a porta UDP e a chave do servidor estão provavelmente bem. Não diz nada sobre as AllowedIPs do segundo par, o seu endereço de origem interno nem as regras de encaminhamento entre eles. Percorra a lista por ordem e pare no primeiro passo cuja condição falhe.

Passo 1: Anote o caminho que o pacote deve seguir

Dois clientes no mesmo concentrador não se alcançam automaticamente. Num desenho de concentrador e raios, o servidor recebe o pacote em wg0 e tem de o reencaminhar de novo para fora de wg0 até ao outro par, o que exige encaminhamento IP e uma regra de encaminhamento. Num desenho direto de par a par, cada lado precisa do extremo do outro e do endereço do seu túnel dentro das AllowedIPs. Decida que desenho está a depurar antes de ler qualquer configuração.

O caminho esperado também lhe diz onde olhar. Se o pacote deve atravessar o concentrador, o salto que falha é ou as AllowedIPs do emissor, ou o encaminhamento do concentrador, ou as AllowedIPs do recetor. Se deve ir diretamente, o concentrador é irrelevante e os campos de extremo dos dois pares são os que contam.

Passo 2: Compare as AllowedIPs nos dois lados, não apenas num

O WireGuard usa as AllowedIPs ao mesmo tempo como tabela de encaminhamento e como lista de acesso. Ao enviar, o endereço de destino é procurado nas AllowedIPs do par para escolher o túnel; ao receber, o endereço de origem interno tem de cair dentro das AllowedIPs do par emissor ou o pacote é descartado. Um intervalo em falta em qualquer dos lados produz o mesmo sintoma: o transporte funciona, a carga desaparece.

Leia o estado ativo em vez do ficheiro, porque um recarregamento pode ter falhado em silêncio: sudo wg show wg0 allowed-ips. No servidor, a entrada do par que falha tem de incluir o seu endereço de túnel, por exemplo 10.90.0.3/32. No cliente, a entrada do par servidor tem de incluir o destino que está a testar, quer seja o endereço de túnel do concentrador quer a sub-rede remota. Intervalos sobrepostos tornam a procura ambígua e podem selecionar um par que não pretendia, por isso mantenha-os separados.

Passo 3: Verifique o endereço de origem interno

Um cliente que encaminha 10.90.0.3 por wg0 mas envia pacotes do seu endereço Wi-Fi será rejeitado pelo recetor, porque a origem não corresponde às AllowedIPs do par. Confirme o que o núcleo escolhe realmente com ip route get 10.90.0.3 from 10.90.0.2, e confirme o endereço atribuído à interface do túnel com ip -brief addr show wg0.

No anfitrião Linux recetor, a filtragem de caminho inverso é uma segunda porta. Um rp_filter estrito na interface que possui a rota de retorno pode descartar tráfego do túnel cujo caminho de regresso não corresponde à interface por onde chegou. Verifique o valor efetivo antes de o desativar; em muitas topologias a correção certa é uma rota, não um filtro relaxado.

Passo 4: Reveja o encaminhamento do concentrador e o caminho de regresso

Se o concentrador tiver de encaminhar entre pares, o núcleo precisa de net.ipv4.ip_forward=1, e a firewall tem de aceitar o fluxo encaminhado: entrada em wg0, saída em wg0, do endereço de túnel do emissor para o do recetor. Uma falha comum é uma regra de entrada que aceita UDP 51820 mas nenhuma regra de encaminhamento], pelo que o handshake tem sucesso e a carga morre. Liste as regras efetivas com sudo nft list ruleset ou o equivalente para o seu gestor de firewall.

Depois verifique a resposta. O anfitrião de destino tem de ter uma rota de regresso ao emissor, seja pelo concentrador seja pela sua própria gateway. Se o concentrador também fizer NAT na sub-rede do túnel, confirme que a tradução se aplica ao fluxo encaminhado e que a resposta chega ao concentrador antes de o estado expirar. Uma falha unidirecional que parece um problema de chave é muitas vezes apenas esta rota de regresso.

Por fim, separe o handshake dos dados. Um par que completa o handshake mas encrava em transferências grandes tem normalmente um problema de MTU ou MSS nesse caminho, não um problema de AllowedIPs. Teste primeiro com um ping pequeno, depois com um de tamanho completo, e compare os dois pares.

Passo 5: Altere uma coisa e mantenha intacto o par que funciona

Faça uma única alteração no caminho que falha e volte a testar os dois pares. Substituir as AllowedIPs de cada par por 0.0.0.0/0 é a forma mais rápida de quebrar o par que já funcionava, porque altera a decisão de encaminhamento de todo o tráfego nessa interface. Edite essa única entrada, recarregue e volte a ler o estado ativo.

Anote qual caminho funcionou, qual falhou e a saída exata do comando para cada um. Essa comparação vale mais do que um relatório geral de que a VPN está quebrada, e é a primeira coisa que a próxima pessoa vai pedir.