NetworkManager ou wg-quick: quem é dono das suas rotas WireGuard?

Você altera AllowedIPs no arquivo do WireGuard, reinicia o túnel, e a tabela de rotas fica exatamente como antes. A reação usual é apagar a rota incômoda e seguir em frente, o que funciona até a próxima reconexão colocá-la de volta. O arquivo que você editou não é necessariamente o objeto que produziu o estado que você está vendo. Dois gerenciadores podem rodar o mesmo protocolo numa máquina, e só um deles possui a interface por vez.

Mito: existe uma única configuração do WireGuard na máquina

O wg-quick lê um arquivo em /etc/wireguard/ e constrói a interface quando você a levanta. O NetworkManager guarda um perfil de conexão em seu próprio formato keyfile e o renderiza na ativação, e importar um arquivo do wg-quick copia os valores para esse perfil em vez de apontar para ele. Editar o original depois não muda nada, porque o perfil não o lê mais. A mesma lista de pares e chaves pode, portanto, existir duas vezes, com a segunda cópia em vigor.

Um sinal que vale lembrar: alterações que sobrevivem a um reinício mas não a uma reimportação vêm de um armazenamento, e alterações que somem no reinício vêm do outro.

Um exemplo prático deixa a divisão óbvia. Compare nmcli connection show com systemctl status wg-quick@wg0, e depois verifique de qual interface as rotas realmente dependem. Se o serviço está morto e a interface está no ar, o perfil é quem faz o trabalho, diga o que disser o arquivo.

Mito: as regras de roteamento fazem parte do WireGuard

O dispositivo WireGuard do kernel conhece pares e chaves, e não sabe nada de roteamento por políticas. As entradas ip rule e as tabelas extras que você vê foram instaladas pela ferramenta que levantou a interface. O wg-quick pode adicionar um fwmark e uma tabela dedicada mais regras que apontam para ela, enquanto o NetworkManager instala rotas pelas próprias configurações de ipv4 e deixa o DNS para o backend de resolução que o sistema usa. Mesmo túnel, efeitos colaterais diferentes.

Leia ip rule e ip route show table all antes de mudar qualquer coisa, e anote em qual tabela cada rota vive. Um número de tabela que você não configurou é uma pista forte sobre a ferramenta que a criou.

Mito: apagar a rota é uma correção

Uma rota apagada em tempo de execução é uma rota que o proprietário vai reinstalar na próxima ativação, e a ativação pode acontecer sem você: retomada de um notebook, um flap do link, reinício de um serviço ou uma autoconnexão do NetworkManager. É por isso que a mesma rota volta e por isso a gambiarra parece não confiável em vez de errada. Identifique primeiro o gerenciador e depois altere a entrada que esse gerenciador realmente lê.

Reconectar e reiniciar o serviço relevante é o teste que separa uma correção real de uma que só parece arrumada.

Escolha um único dono e remova o outro

Escolha o gerenciador que sua implantação suporta e desative a ativação concorrente pelo controle documentado dele, em vez de esperar que fique ocioso. Um serviço wg-quick mascarado ou um perfil do NetworkManager apagado é explícito; deixar os dois habilitados e fazê-los competir não é. Preserve o acesso funcional antes de desativar qualquer coisa, porque a interface que carrega sua sessão remota pode ser justamente a que você está prestes a remover.

Depois da mudança, verifique o tráfego incluído e excluído, depois o DNS e depois reinicie uma vez. Se o estado sobrevive a um reinício com um único gerenciador, você tem um dono em vez de uma coincidência.

A regra geral vale para além do WireGuard: quando uma configuração continua voltando, pare de apagar o resultado e encontre o processo que continua produzindo-o.