El miembro de ZeroTier eliminado vuelve: revoca primero la autorización

Eliminas el miembro, cierras la página y, un día después, el mismo dispositivo está de vuelta. No es un fallo de la consola. Es lo que ocurre cuando se elimina un registro mientras el dispositivo sigue en línea y sigue pidiendo unirse.

Dos operaciones conviven una al lado de la otra y hacen trabajos distintos. Una decide el acceso y la otra solo ordena la lista.

Empieza por el registro que reaparece

Abre la red y mira la entrada que ha vuelto. Anota su node ID, su última dirección y la hora en que reapareció. Compáralo con el dispositivo que querías retirar. El nombre visible es lo que alguien escribió, y la dirección puede cambiar en la próxima unión.

El node ID es el identificador estable. Un ID de red nombra la red, así que te dice qué lista estás leyendo y nada sobre qué dispositivo hay en ella. Anota ambos y luego compara el node ID con la máquina que querías retirar.

Si te equivocas en esa comparación, quitarás una máquina que funciona mientras la no deseada sigue pidiendo. Entonces la lista parece correcta durante un día. Es tiempo suficiente para que nadie lo note, y ese es justo el problema.

Revoca antes de borrar

Primero cambia el estado de autorización mediante el flujo de trabajo que admite el controlador. A partir de ese momento, un intento de unión aparece como no autorizado en lugar de restaurar el acceso en silencio, y la petición es visible en vez de invisible.

El borrado llega después, nunca en su lugar. Quitar el registro de un miembro autorizado no deja nada que revocar. El dispositivo vuelve a preguntar y el controlador lo trata como nuevo.

En una máquina que aún controlas, salir de la red es una parte útil de la retirada. No sustituye la decisión del administrador sobre un dispositivo perdido. Un cliente que ya no controlas puede ignorar lo que se le haya dicho.

Dónde viven las dos operaciones

En un controlador alojado, la lista de miembros ofrece ambas acciones y las etiqueta con claridad suficiente para distinguirlas. En un controlador autoalojado, la misma distinción aparece en la API y en la configuración local, y ahí suele empezar la 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 dos llamadas bastan para mostrar si el miembro estuvo alguna vez realmente sin autorización. Un registro que vuelve una y otra vez con authorized: true nunca se revocó; solo se borró.

Confirma desde el recurso, no desde la lista

Una lista de miembros ordenada no es una comprobación de acceso. Prueba el recurso que el dispositivo usaba antes, desde ese dispositivo o desde una máquina que tenga su dirección antigua, y confirma que la conexión falla. Luego confirma que un reemplazo aprobado sigue funcionando.

Incluye rutas y permisos de servicio en esa prueba. ZeroTier puede autorizar a un miembro y dejarlo igualmente incapaz de alcanzar una ruta gestionada. Un permiso de aplicación puede fallar del mismo modo. Ambos se ven idénticos desde la lista de miembros.

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

En un controlador autoalojado, mantén una copia de seguridad coherente de su identidad y su configuración. Una restauración que retroceda a un estado anterior puede traer de vuelta una autorización antigua, y la lista de miembros se verá exactamente como antes de la retirada.

La retirada termina cuando la identidad antigua no puede alcanzar nada y el registro ha desaparecido. Hazlo en ese orden y el miembro deja de volver.