O membro ZeroTier eliminado volta: revogue primeiro a autorização

Você elimina o membro, fecha a página e, um dia depois, o mesmo dispositivo está de volta. Não é um bug do console. É o que acontece quando um registro é eliminado enquanto o dispositivo ainda está online e ainda pede para entrar.

Duas operações ficam lado a lado e fazem trabalhos diferentes. Uma decide o acesso, a outra apenas arruma a lista.

Comece pelo registro que reaparece

Abra a rede e olhe a entrada que voltou. Anote o node ID, o último endereço e a hora em que reapareceu. Compare com o dispositivo que você queria retirar. O nome exibido é o que alguém digitou, e o endereço pode mudar na próxima entrada.

O node ID é o identificador estável. Um ID de rede dá nome à rede, então ele diz qual lista você está lendo e nada sobre qual dispositivo está nela. Anote os dois e depois compare o node ID com a máquina que você queria retirar.

Se errar essa comparação, você remove uma máquina que funciona enquanto a indesejada continua pedindo. A lista então parece correta por um dia. É tempo suficiente para ninguém notar, e é exatamente esse o problema.

Revogue antes de eliminar

Primeiro mude o estado de autorização pelo fluxo de trabalho suportado pelo controlador. A partir daí, uma tentativa de entrada aparece como não autorizada em vez de restaurar o acesso em silêncio, e o pedido fica visível em vez de invisível.

A eliminação vem depois, nunca no lugar dela. Remover o registro de um membro autorizado não deixa nada para revogar. O dispositivo pergunta de novo, e o controlador o trata como novo.

Para uma máquina que você ainda controla, sair da rede é uma parte útil da retirada. Não substitui a decisão do administrador sobre um dispositivo perdido. Um cliente que você não controla mais pode ignorar o que quer que lhe tenha sido dito.

Onde ficam as duas operações

Num controlador hospedado, a lista de membros oferece as duas ações e as rotula com clareza suficiente para distingui-las. Num controlador auto-hospedado, a mesma distinção aparece na API e na configuração local, e é aí que a confusão costuma começar.

# list members with authorization state
curl -s -H "X-ZT1-Auth: $TOKEN" \
  "http://127.0.0.1:9993/controller/network/$NETWORK_ID/member" | jq 'to_entries[] | {id: .key, authorized: .value.authorized}'

# deauthorize one member by node id, then confirm
curl -s -X POST -H "X-ZT1-Auth: $TOKEN" -d '{"authorized": false}' \
  "http://127.0.0.1:9993/controller/network/$NETWORK_ID/member/$NODE_ID"

Essas duas chamadas bastam para mostrar se o membro alguma vez esteve realmente sem autorização. Um registro que volta sempre com authorized: true nunca foi revogado; foi apenas eliminado.

Confirme pelo recurso, não pela lista

Uma lista de membros arrumada não é uma verificação de acesso. Tente o recurso que o dispositivo usava antes, a partir desse dispositivo ou de uma máquina que tenha o endereço antigo, e confirme que a conexão falha. Depois confirme que um substituto aprovado ainda funciona.

Inclua rotas e permissões de serviço nesse teste. O ZeroTier pode autorizar um membro e mesmo assim deixá-lo incapaz de alcançar uma rota gerenciada. Uma permissão de aplicação pode falhar da mesma forma. Os dois parecem idênticos na lista de membros.

zerotier-cli listnetworks
ip route show | grep zt
ping -c 3 10.144.0.5

Num controlador auto-hospedado, mantenha um backup consistente da identidade e da configuração. Uma restauração que volte a um estado anterior pode trazer de volta uma autorização antiga, e a lista de membros ficará exatamente como antes da retirada.

A retirada termina quando a identidade antiga não alcança nada e o registro desapareceu. Faça isso nessa ordem e o membro deixa de voltar.