Un membre ZeroTier supprimé revient : révoquez d'abord l'autorisation

Vous supprimez le membre, vous fermez la page, et un jour plus tard le même appareil est de retour. Ce n'est pas un bug de la console. C'est ce qui se passe lorsqu'un enregistrement est supprimé alors que l'appareil est encore en ligne et demande toujours à rejoindre.

Deux opérations vivent côte à côte et font des travaux différents. L'une décide de l'accès, l'autre ne fait que ranger la liste.

Partez de l'enregistrement qui réapparaît

Ouvrez le réseau et regardez l'entrée revenue. Notez son node ID, sa dernière adresse et l'heure de sa réapparition. Comparez-la avec l'appareil que vous vouliez retirer. Le nom affiché est ce que quelqu'un a saisi, et l'adresse peut changer à la prochaine jonction.

Le node ID est l'identifiant stable. Un ID de réseau nomme le réseau, il vous dit donc quelle liste vous lisez et rien sur l'appareil qui s'y trouve. Notez les deux, puis comparez le node ID avec la machine que vous vouliez retirer.

Si vous vous trompez dans cette comparaison, vous retirez une machine qui fonctionne pendant que l'indésirable continue de demander. La liste paraît alors correcte pendant un jour. C'est assez long pour que personne ne le remarque, et c'est exactement le problème.

Révoquez avant de supprimer

Changez d'abord l'état d'autorisation via le flux de travail pris en charge par le contrôleur. À partir de là, une tentative de jonction apparaît comme non autorisée au lieu de rétablir l'accès en silence, et la demande est visible plutôt qu'invisible.

La suppression vient après, jamais à la place. Retirer l'enregistrement d'un membre autorisé ne laisse rien à révoquer. L'appareil redemande, et le contrôleur le traite comme nouveau.

Pour une machine que vous contrôlez encore, quitter le réseau est une partie utile du retrait. Cela ne remplace pas la décision de l'administrateur sur un appareil perdu. Un client que vous ne contrôlez plus peut ignorer ce qu'on lui a dit.

Où vivent les deux opérations

Sur un contrôleur hébergé, la liste des membres propose les deux actions et les étiquette assez clairement pour les distinguer. Sur un contrôleur auto-hébergé, la même distinction apparaît dans l'API et dans la configuration locale, et c'est là que la confusion commence généralement.

# 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"

Ces deux appels suffisent à montrer si le membre a jamais été réellement non autorisé. Un enregistrement qui revient sans cesse avec authorized: true n'a jamais été révoqué ; il a seulement été supprimé.

Vérifiez depuis la ressource, pas depuis la liste

Une liste de membres bien rangée n'est pas un contrôle d'accès. Essayez la ressource que l'appareil utilisait avant, depuis cet appareil ou depuis une machine qui détient son ancienne adresse, et confirmez que la connexion échoue. Confirmez ensuite qu'un remplacement approuvé fonctionne toujours.

Incluez les routes et les permissions de service dans ce test. ZeroTier peut autoriser un membre et le laisser malgré tout incapable d'atteindre une route gérée. Une permission d'application peut échouer de la même manière. Les deux se ressemblent depuis la liste des membres.

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

Sur un contrôleur auto-hébergé, gardez une sauvegarde cohérente de son identité et de sa configuration. Une restauration qui revient à un état antérieur peut rapporter une ancienne autorisation, et la liste des membres sera exactement comme avant le retrait.

Le retrait est terminé quand l'ancienne identité ne peut plus rien atteindre et que l'enregistrement a disparu. Faites-le dans cet ordre et le membre cesse de revenir.