Porque é que um peer WireGuard eliminado volta após um reinício
Dois estados guardam a lista de peers: a interface em execução e o que a escreve no arranque. Retire-o de ambos e verifique SaveConfig antes de alterar seja o que for.
A identidade desaparece da interface em execução e a alteração parece concluída. Depois de o serviço reiniciar, ela está de volta, o que se lê como se o WireGuard ignorasse o comando. O que aconteceu na realidade é mais simples: a configuração de arranque ainda contém o peer.
Dois estados mantêm essa lista. A revogação só é real quando ambos a perdem.
O que o wg set altera de facto
O comando wg set wg0 peer <public-key> remove edita a interface em execução no kernel. Não escreve nada no disco. O ficheiro de configuração, o perfil do NetworkManager ou o estado guardado do router ficam intactos. É o desenho, não um erro.
Essa separação é deliberada, porque a ferramenta não faz ideia de quem é o dono da interface. Um comando em tempo de execução tem de ser seguro contra uma interface gerida por outra coisa. Não pode adivinhar onde vive a cópia duradoura. A consequência é fácil de enunciar: uma remoção em tempo de execução é temporária por construção.
Por isso o peer volta no reinício seguinte, e volta com os seus prefixos permitidos originais. Tudo o que é encaminhado através dele também é recriado. Uma identidade supostamente revogada pode, portanto, alcançar os seus destinos anteriores após um recarregamento. Nada na saída em tempo de execução tinha avisado ninguém.
Encontre o escritor antes de editar um ficheiro
A interface tem um dono. Pode ser o wg-quick a ler um ficheiro, o NetworkManager a aplicar um perfil, a configuração de interface do próprio router ou um ponto de entrada de contentor que recria a interface ao arrancar. Editar um ficheiro que o dono nunca lê não produz qualquer alteração persistente.
Comece pela interface em execução e identifique as chaves públicas, pois nomes e endereços são identificadores mais fracos do que a própria chave. Depois compare essa lista com a configuração guardada que o dono lê de facto.
wg show wg0 peers
wg show wg0 allowed-ips
systemctl status wg-quick@wg0 --no-pager
ls -l /etc/wireguard
Uma interface viva cuja lista de peers e cujo conteúdo do ficheiro não coincidem é todo o diagnóstico. A configuração guardada ganha no arranque, e o estado em execução perde. Compare os dois antes de alterar qualquer um deles.
A armadilha do SaveConfig
O wg-quick acrescenta uma dobra que apanha quem edita ficheiros à mão. Com o SaveConfig ativado, o seu comportamento documentado ao desligar escreve o estado em execução atual por cima do ficheiro de configuração.
Isso inverte a direção habitual da persistência. Retira um peer do ficheiro e depois o serviço para. O estado em execução é escrito por cima da sua edição e restaura o peer que acabou de apagar.
Por isso a ordem importa: edite o ficheiro com a interface em baixo, ou desative o SaveConfig antes da edição, depois suba a interface de novo e confirme o que foi carregado. Uma edição à mão com a interface em cima é uma corrida com a escrita de desligamento.
Altere os dois estados e recarregue
Em tempo de execução, remova o peer pela chave. Na configuração guardada, remova o mesmo bloco através da operação suportada pelo dono, em vez de editar em volta dele.
Depois reveja o que o peer transportava. Uma rede encaminhada que pertencia à identidade revogada deve ser reatribuída deliberadamente ou removida, não herdada em silêncio pelo peer que for editado a seguir.
Mantenha um caminho de recuperação aberto se a gateway também transporta o seu acesso administrativo. Um reinício que remove o peer errado é uma falha autoinfligida. O mesmo se aplica a um reinício que remove a rota errada.
Como é um teste aprovado
Recarregue ou reinicie o serviço e depois leia a lista de peers outra vez. A chave antiga tem de faltar, e os peers que queria manter têm de continuar presentes e a funcionar.
wg show wg0 peers
wg show wg0 allowed-ips
sudo wg-quick down wg0 && sudo wg-quick up wg0
wg show wg0 peers
Onde a situação o permitir, confirme que a identidade antiga já não alcança os seus recursos anteriores. Uma listagem de interface arrumada antes de um reinício é metade do teste. A outra metade é o que a identidade ainda consegue fazer depois.
Se algum gestor continuar a restaurar o peer, pare de repetir a remoção de baixo nível. Corrija o inventário que esse escritor lê, porque até lá cada reinício é outro convite para a identidade reaparecer.