WireGuard AllowedIPs: a rota que o NetworkManager nunca adicionou

O contador de handshake é atualizado, a interface mantém o seu endereço e um ping para o outro lado não chega a lugar nenhum. Essa combinação confunde as pessoas, porque um handshake a funcionar parece a prova de que o túnel está pronto. Não é: um túnel pode estar completamente negociado e mesmo assim não ter nenhuma rota que encaminhe tráfego para dentro dele, e são duas tarefas separadas executadas por duas peças de estado separadas. A correção depende inteiramente de qual das duas falta, portanto o primeiro passo é descobri-lo.

O wg-quick faz as duas coisas sem que ninguém lhe peça. O suporte WireGuard integrado do NetworkManager também instala rotas de peers por predefinição, o que reduz os suspeitos a uma opção desativada, a outra tabela de encaminhamento ou a uma configuração importada por outra via.

Confirme o túnel antes de perseguir a rota

wg show mostra a interface, o peer, o endpoint e a idade do último handshake, e ip addr show confirma que o endereço está presente. Um handshake recente significa que as chaves, o endpoint e o caminho UDP estão a funcionar. Tudo o que está avariado fica a jusante: encaminhamento, filtragem ou resolução de nomes.

Depois pergunte ao núcleo o que faria com um destino real em vez de um hipotético: ip route get 10.42.7.9. A resposta indica a interface de saída e o endereço de origem que o pacote levaria. Quando indica o adaptador físico, o pacote nunca entra no túnel, por mais saudável que pareça o handshake.

AllowedIPs é um filtro e uma lista de rotas

Os prefixos em AllowedIPs fazem dois trabalhos. Escolhem qual peer transporta um destino de saída e validam o endereço de origem dos pacotes recebidos, que é o limite do encaminhamento por chave criptográfica. No wg-quick também comandam a instalação automática de rotas, e é exatamente esse comportamento extra que explica porque a mesma configuração funciona a partir de um terminal e não de um cliente de ambiente de trabalho.

No caso por detrás deste artigo, o perfil foi importado através de um plugin de terceiros e não do suporte integrado, e a interface subiu sem a rota do prefixo. Listar a tabela mostra-o de imediato: ip route show contém apenas a rota ligada do endereço da interface, e nada para o intervalo remoto.

Pergunte se as rotas de peers estão sequer ativadas

Leia a definição antes de alterar seja o que for: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. Quando peer-routes mostra no, a reparação suportada é nmcli connection modify work-wg wireguard.peer-routes yes, seguida de uma reconexão. Acrescentar antes uma rota estática funciona até à ativação seguinte e depois desaparece em silêncio. Esse desaparecimento é a pista: uma rota que regressa como um mistério todas as manhãs não é instalada pelo perfil.

Se a opção já estiver ativada, verifique se o prefixo vive noutra tabela com ip route show table all | grep 10. Uma rota numa tabela que não é a principal não falta, é simplesmente invisível para uma pesquisa que só consulta a tabela principal. Corrija o encaminhamento por políticas em vez de empilhar uma entrada duplicada por cima.

Acrescente o prefixo à ligação, não ao sistema em execução

No editor de ligações, a página WireGuard contém o peer e as respetivas AllowedIPs, e a página IPv4 contém rotas adicionais. Uma rota aí acrescentada sobrevive às reconexões porque pertence ao perfil. Na linha de comandos o equivalente é acrescentar uma rota à ligação na forma de gateway vazio e depois descer e subir a ligação para que a alteração seja aplicada.

Escolha o prefixo mais estreito que cobre os anfitriões de que precisa. Copiar o exemplo /8 do fornecedor pode engolir intervalos locais que estejam lá dentro por acaso, e as falhas resultantes parecem um túnel avariado e não uma rota demasiado larga.

O túnel dividido é decidido pela lista de prefixos

Não existe nenhum interruptor de túnel dividido; a lista de prefixos é a decisão. Um peer com um intervalo para a LAN do escritório e outro para uma rede de laboratório envia exatamente esses destinos pelo túnel e deixa tudo o resto em paz. Um único anfitrião precisa de um /32, e os intervalos sobrepostos em dois locais precisam de prefixos de anfitrião até alguém renumerar uma sub-rede.

Escolher não enviar nada pelo túnel leva a mesma decisão ao seu limite: uma lista mínima mantém a ligação ativa enquanto o tráfego comum segue o seu caminho habitual. Escreva a intenção, porque caso contrário o leitor seguinte tomará a lista curta por um descuido e irá ampliá-la com boa vontade.

Um único dono para a tabela de rotas

O wg-quick e o NetworkManager acreditam ambos que são donos das rotas da interface. Importe uma configuração escrita para o wg-quick e depois arranque também o serviço wg-quick, e obtém entradas duplicadas ou em conflito cujo comportamento depende de qual foi executada por último. Escolha um único dono e remova o outro: se o NetworkManager gere a ligação, desative a unidade wg-quick para essa interface, e nunca acrescente um segundo perfil para o mesmo dispositivo.

Quando a divisão tem de seguir um adaptador físico em vez de um destino, passou para o encaminhamento por políticas, e o encaminhamento por políticas também precisa de um único autor. Verifique repetindo ip route get e depois alcançando um anfitrião dentro do prefixo remoto com algo que imprima o endereço de origem que escolheu. Verifique IPv6 e DNS separadamente se o perfil transportar algum dos dois.