O peer do WireGuard desaparece após reiniciar: encontre a configuração real

O peer que você adicionou com wg set responde aos ping a tarde toda e desaparece após o reinício. Nada foi corrompido: o kernel nunca armazenou esse peer em outro lugar além da interface ativa, e o que recria a interface na inicialização a reconstruiu a partir de um arquivo que você não tocou. A correção não é outro wg set. É descobrir qual componente possui a interface, editar o estado desse componente e então provar que o peer sobrevive exatamente ao evento do ciclo de vida que o removeu.

Reproduza uma vez, de propósito

Não corrija um problema de reinício antes de conseguir vê-lo acontecer. Com acesso por console ou fora de banda disponível, anote a lista de peers, reinicie pelo serviço que possui a interface e compare. Se o peer ainda estiver lá, sua alteração já chegou ao estado persistente e você está depurando o evento errado.

Anote três fatos enquanto faz isso: o nome da interface, a unidade ou o perfil que a iniciou e se o contador de handshake do peer sobrevivente foi zerado. Um contador zerado significa que a interface foi destruída e recriada; um contador inalterado com um peer ausente significa que algo editou a configuração sob seus pés.

Quem possui a interface?

O próprio WireGuard não tem daemon nem arquivo de configuração. Algo acima dele chama wg na inicialização, e esse algo é a fonte da verdade. Os candidatos habituais são [email protected], um perfil de conexão do NetworkManager, uma unidade de rede específica da distribuição ou um painel de gestão que escreve seu próprio banco de dados.

Pergunte ao sistema, não à documentação da sua distribuição. systemctl status wg-quick@wg0 e nmcli connection show costumam resolver a questão com um comando cada. Se ambos reivindicarem a interface, você encontrou o bug antes de editar qualquer coisa: dois proprietários reescrevem o mesmo dispositivo a cada início, e o último a rodar vence.

systemctl status wg-quick@wg0 --no-pager
grep -R "Address\|SaveConfig\|PostUp" /etc/wireguard/wg0.conf
nmcli -g NAME,TYPE connection show
wg show wg0 peers

O estado de execução e o estado de inicialização não são o mesmo arquivo

wg set manipula o dispositivo ativo através do netlink. Ele não escreve /etc/wireguard/wg0.conf, um perfil do NetworkManager nem o banco de dados de um painel. Um wg show bem-sucedido depois prova que o kernel aceitou o peer, não que algo vai restaurá-lo.

Há uma segunda armadilha na direção oposta. A opção SaveConfig do wg-quick grava o estado atual da interface de volta no arquivo de configuração quando a interface é derrubada. Com ela ativa, uma edição feita no arquivo enquanto a interface está no ar pode ser sobrescrita pelo desligamento seguinte, e você jurará que a linha estava lá. Se o peer volta sempre, leia o arquivo depois de uma parada, não antes.

O NetworkManager se comporta de forma diferente de novo: ele possui o perfil e o aplica na ativação, então um .conf editado à mão ao lado de uma conexão ativa do NetworkManager é apenas decoração. Escolha um único proprietário para a interface e deixe o outro gerenciador não mexer nela.

Faça a edição chegar aos dois lugares

Edite primeiro o estado persistente, deixe o proprietário aplicá-lo e depois verifique o estado ativo. Essa ordem faz com que uma falha em qualquer etapa aponte para uma coisa em vez de três.

# 1. persistent state (wg-quick owner)
sudo vi /etc/wireguard/wg0.conf

# 2. apply through the owner, not by hand
sudo systemctl restart wg-quick@wg0

# 3. verify runtime matches the file
sudo wg show wg0
sudo wg showconf wg0

wg showconf imprime a configuração ativa na mesma sintaxe usada pelo arquivo, o que torna as duas diretamente comparáveis. Trate essa saída como segredo: ela contém chaves privadas, então não a cole em um ticket ou canal de chat. Compare as chaves públicas dos peers e os IPs permitidos, e verifique se o peer que você removeu de propósito não voltou.

Prove que ele sobrevive ao evento do ciclo de vida

Reinicie pelo proprietário uma segunda vez e confirme três coisas separadas: o peer aparece em wg show, o contador de handshake aumenta após o tráfego e o aplicativo que depende do túnel responde de verdade. Um peer listado com um handshake antigo é um problema de roteamento ou de chave, não de persistência, e essa distinção economiza uma edição de configuração inútil.

Por fim, verifique o que o reinício restaurou. Um reinício que ressuscita um peer que você removeu deliberadamente é o mesmo bug com o sinal oposto, e geralmente significa que uma cópia antiga da configuração ainda está sendo carregada de algum lugar. Anote o proprietário, o caminho do arquivo, a chave pública do peer e os comandos de verificação junto à configuração, para que a próxima pessoa não descubra isso de novo reiniciando um host de produção.