Removeste o peer. O wg show confirma que desapareceu. Uma semana depois, o portátil que revogaste
volta a ligar-se e nada nos teus logs o explica.
Nada correu mal. O WireGuard tem simplesmente dois estados, e o comando que usaste só alterou um deles.
Os dois estados
| o que é | o que o altera | |
|---|---|---|
| estado em execução | o que o kernel aceita neste momento | wg set, wg syncconf |
| ficheiro de configuração | o que é carregado no próximo arranque | o teu editor, wg-quick save |
wg set wg0 peer PUBLIC_KEY remove atua sobre o primeiro. É imediato, deixa todos os outros peers
ligados e nunca toca em /etc/wireguard/wg0.conf. A chave pública que passas é a chave Curve25519
de 32 bytes apresentada como 44 caracteres base64, e é por isso que um peer é identificado por essa
cadeia e não por um nome: o WireGuard não guarda nenhum nome para ele.
Assim, o próximo wg-quick down wg0 && wg-quick up wg0 (um reboot, uma atualização de pacotes, um
restart do systemd em que não pensaste) lê um ficheiro que ainda contém o peer e volta a pô-lo.
Ninguém é avisado. O acesso simplesmente retoma.
Removê-lo de vez
Duas ordens de operação, e a segunda é a preferível.
A rápida, quando o ficheiro não tem nada que te interesse:
sudo wg set wg0 peer PUBLIC_KEY remove
sudo wg-quick save wg0
O wg-quick save escreve o estado em execução de volta no ficheiro. Funciona, e reescreve o ficheiro
do ponto de vista do kernel. Os teus comentários desaparecem. Num servidor com uma dúzia de peers,
esses comentários são normalmente o único registo de que peer corresponde a que portátil. Perdê-los
transforma uma configuração legível numa lista de chaves públicas anónimas.
A preferível, que mantém o ficheiro como referência:
sudo nano /etc/wireguard/wg0.conf # delete the whole [Peer] block
sudo wg syncconf wg0 <(wg-quick strip wg0)
O wg syncconf aplica o ficheiro à interface em execução sem a deitar abaixo: só o que mudou é
afetado e os outros túneis mantêm as suas sessões. O wg-quick strip remove as diretivas que o
kernel não entende (Address, DNS, PostUp) e imprime o resto.
A distinção importa num servidor com vários clientes: wg-quick down && up desliga toda a gente
durante uns segundos para revogar um único peer. A implementação no kernel aceita até 1 048 576 peers
por dispositivo, por isso o limite que atinges primeiro é a tua própria capacidade de os distinguir,
não o do protocolo.
Duas chaves planas numa única argola, penduradas numa placa de metal clara aparafusada a uma porta de madeira clara. A chave de cima tem gravadas as iniciais « R.M.I. ». Tons quentes, veio da madeira visível.
Verificar nos dois sítios, não num só
sudo wg show wg0 peers # what the kernel accepts now
grep PublicKey /etc/wireguard/wg0.conf # what loads next time
Uma chave ausente do primeiro e presente no segundo é uma revogação com prazo de validade. É exatamente a situação para a qual este artigo existe, e é invisível até ao dia em que a interface reinicia.
Os comandos em direto usados aqui (wg set wg0 peer <pubkey> remove, wg show wg0 latest-handshakes, wg show wg0 endpoints) cabem numa página A4 imprimível na nossa WireGuard Cheat Sheet gratuita, ao lado das chaves [Peer] e do comando que volta a adicionar um peer em direto. Download direto, sem registo. Descarregar a cheat sheet.
O que a revogação não faz
Remover o peer significa que o servidor recusa o handshake. O material de chaves no dispositivo perdido torna-se inútil contra este servidor. Isso é real, e é aí que o efeito acaba.
A revogação não é bem instantânea, e o atraso é limitado pelos próprios temporizadores do protocolo.
Uma chave de sessão é rejeitada ao fim de 180 segundos (REJECT_AFTER_TIME) e um novo handshake é
normalmente iniciado ao fim de 120 segundos (REKEY_AFTER_TIME). Portanto, uma sessão já estabelecida
quando removeste o peer pode continuar a transportar tráfego durante até três minutos antes de o kernel
a descartar. Se essa janela importa, deita a interface abaixo em vez de esperar.
O ficheiro de configuração continua nesse dispositivo. A sua chave privada também, e tudo o mais que o dispositivo tinha: uma sessão ainda aberta, um gestor de palavras-passe deixado desbloqueado, a caixa de correio que permite repor as tuas outras contas. Revogar o túnel é o primeiro passo certo. Não é a resposta completa, e tratá-lo como tal é a forma como as pessoas acabam perfeitamente confiantes e ainda expostas.
Situa a tua própria superfície de ataque, 10 perguntas, cerca de três minutos, sem conta, sem email, nada guardado. O resultado indica a alteração que mais reduz a tua exposição, e para quem faz self-hosting raramente é mais uma regra de firewall.
Em resumo
| O que fizeste | O que mudou realmente |
|---|---|
wg set … peer … remove | só o estado em execução, reverte no reinício |
wg-quick save | o ficheiro também, à custa dos teus comentários |
editar o ficheiro, depois wg syncconf | ambos, sem desligar os outros peers |
| revogado depois de perder um dispositivo | o túnel, não o que o dispositivo ainda guarda |
Uma frase a reter: um peer removido da memória e deixado no ficheiro não está removido, está adiado.
Quando o dispositivo revogado precisar de substituto, gera um novo par de chaves em vez de reutilizar o antigo: o nosso gerador de configuração WireGuard escreve o novo ficheiro de cliente e o respetivo código QR, e um ficheiro de servidor cujo bloco [Peer] copias para o teu antes do wg syncconf. O gerador é gratuito até 10 dispositivos; acima disso, o WireGuard Pro (produto nosso, 9 EUR uma única vez, sem subscrição) sobe o limite para 250 e acrescenta um ZIP com todos os .conf de cliente e o respetivo código QR em PNG, prático para configurar um escritório inteiro ou uma família de uma só vez.
★ Datacenter GDPR em Nuremberg · ✓ IPv4 dedicado incluído · porta de 200 Mbit/s
Aloje a sua VPN no seu próprio VPS → ContaboAcesso root completo · IPv4 público · escolha a sua região→
