El membre de ZeroTier esborrat torna: revoca primer l'autorització

Esborres el membre, tanques la pàgina i, un dia més tard, el mateix dispositiu torna. No és cap error de la consola. És el que passa quan s'esborra un registre mentre el dispositiu encara és en línia i encara demana d'unir-se.

Dues operacions conviuen l'una al costat de l'altra i fan feines diferents. Una decideix l'accés i l'altra només endreça la llista.

Comença pel registre que reapareix

Obre la xarxa i mira l'entrada que ha tornat. Anota'n el node ID, la darrera adreça i l'hora en què ha reaparegut. Compara-ho amb el dispositiu que volies retirar. El nom de visualització és el que algú va escriure, i l'adreça pot canviar en la propera unió.

El node ID és l'identificador estable. L'ID de xarxa dóna nom a la xarxa, així que et diu quina llista estàs llegint i res sobre quin dispositiu hi ha. Anota tots dos i després compara el node ID amb la màquina que volies retirar.

Si t'equivoques en aquesta comparació, treuràs una màquina que funciona mentre la no desitjada continua demanant. Llavors la llista sembla correcta durant un dia. És prou temps perquè ningú no ho noti, i aquest és exactament el problema.

Revoca abans d'esborrar

Primer canvia l'estat d'autorització pel flux de treball que admet el controlador. A partir d'aquell moment, un intent d'unió apareix com a no autoritzat en lloc de restablir l'accés en silenci, i la petició és visible en comptes d'invisible.

L'esborrat ve després, mai en lloc seu. Treure el registre d'un membre autoritzat no deixa res per revocar. El dispositiu torna a demanar i el controlador el tracta com a nou.

Per a una màquina que encara controles, sortir de la xarxa és una part útil de la retirada. No substitueix la decisió de l'administrador sobre un dispositiu perdut. Un client que ja no controles pot ignorar tot el que se li hagi dit.

On viuen les dues operacions

En un controlador allotjat, la llista de membres ofereix les dues accions i les etiqueta prou clarament per distingir-les. En un controlador autoallotjat, la mateixa distinció apareix a l'API i a la configuració local, i és aquí on sol començar la confusió.

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

Aquestes dues crides n'hi ha prou per veure si el membre algun cop va estar realment no autoritzat. Un registre que torna una vegada i una altra amb authorized: true no es va revocar mai; només es va esborrar.

Confirma-ho des del recurs, no des de la llista

Una llista de membres endreçada no és una comprovació d'accés. Prova el recurs que el dispositiu feia servir abans, des d'aquell dispositiu o des d'una màquina que tingui la seva adreça antiga, i confirma que la connexió falla. Després confirma que un reemplaçament aprovat encara funciona.

Inclou les rutes i els permisos de servei en aquesta prova. ZeroTier pot autoritzar un membre i deixar-lo igualment incapaç d'arribar a una ruta gestionada. Un permís d'aplicació pot fallar de la mateixa manera. Tots dos es veuen iguals des de la llista de membres.

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

En un controlador autoallotjat, mantén una còpia de seguretat coherent de la seva identitat i configuració. Una restauració que retrocedeixi a un estat anterior pot tornar a portar una autorització antiga, i la llista de membres quedarà exactament com abans de la retirada.

La retirada s'acaba quan la identitat antiga no pot arribar a res i el registre ha desaparegut. Fes-ho en aquest ordre i el membre deixa de tornar.