O membro de ZeroTier eliminado volve: revoca primeiro a autorización

Eliminas o membro, pechas a páxina e, un día despois, o mesmo dispositivo está de volta. Non é un fallo da consola. É o que ocorre cando se elimina un rexistro mentres o dispositivo segue en liña e segue pedindo unirse.

Dúas operacións conviven unha ao lado da outra e fan traballos distintos. Unha decide o acceso e a outra só ordena a lista.

Comeza polo rexistro que reaparece

Abre a rede e mira a entrada que volveu. Anota o seu node ID, a súa última dirección e a hora en que reapareceu. Compárao co dispositivo que querías retirar. O nome visible é o que alguén escribiu, e a dirección pode cambiar na próxima unión.

O node ID é o identificador estable. Un ID de rede nomea a rede, así que che di que lista estás a ler e nada sobre que dispositivo hai nela. Anota ambos e despois compara o node ID coa máquina que querías retirar.

Se te equivocas nesa comparación, quitarás unha máquina que funciona mentres a non desexada segue pedindo. Entón a lista parece correcta durante un día. É tempo abondo para que ninguén o note, e ese é xusto o problema.

Revoca antes de borrar

Primeiro cambia o estado de autorización mediante o fluxo de traballo que admite o controlador. A partir dese momento, un intento de unión aparece como non autorizado en lugar de restaurar o acceso en silencio, e a petición é visible en vez de invisible.

O borrado chega despois, nunca no seu lugar. Quitar o rexistro dun membro autorizado non deixa nada que revogar. O dispositivo volve preguntar e o controlador trátao como novo.

Nunha máquina que aínda controlas, saír da rede é unha parte útil da retirada. Non substitúe a decisión do administrador sobre un dispositivo perdido. Un cliente que xa non controlas pode ignorar o que se lle dixese.

Onde viven as dúas operacións

Nun controlador aloxado, a lista de membros ofrece ambas as accións e etiquétaas con claridade suficiente para distinguilas. Nun controlador autoaloxado, a mesma distinción aparece na API e na configuración local, e aí adoita comezar a confusión.

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

Esas dúas chamadas abondan para mostrar se o membro estivo algunha vez realmente sen autorización. Un rexistro que volve unha e outra vez con authorized: true nunca se revogou; só se borrou.

Confirma desde o recurso, non desde a lista

Unha lista de membros ordenada non é unha comprobación de acceso. Proba o recurso que o dispositivo usaba antes, desde ese dispositivo ou desde unha máquina que teña a súa dirección antiga, e confirma que a conexión falla. Logo confirma que un substituto aprobado segue funcionando.

Inclúe rutas e permisos de servizo nesa proba. ZeroTier pode autorizar un membro e deixalo igualmente incapaz de alcanzar unha ruta xestionada. Un permiso de aplicación pode fallar do mesmo xeito. Ambos se ven idénticos desde a lista de membros.

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

Nun controlador autoaloxado, mantén unha copia de seguridade coherente da súa identidade e da súa configuración. Unha restauración que retroceda a un estado anterior pode traer de volta unha autorización antiga, e a lista de membros verase exactamente como antes da retirada.

A retirada remata cando a identidade antiga non pode alcanzar nada e o rexistro desapareceu. Fai iso nesa orde e o membro deixa de volver.