ZeroTier muestra ONLINE pero ACCESS_DENIED: dónde se corrige?

ZeroTier informa ONLINE a nivel de servicio y ACCESS_DENIED a nivel de red, y la pareja no es una contradicción. Lo primero es una afirmación sobre la ruta entre su cliente y la infraestructura de coordinación. Lo segundo es una afirmación sobre la lista de miembros de una red. Léalos por separado y la combinación le dirá exactamente dónde mirar.

Qué mide ONLINE

El comando de estado informa si el servicio local tiene una ruta funcional hacia los servidores raíz que coordinan el descubrimiento de pares. No dice nada sobre ninguna red concreta, ni sobre si un controlador ha aprobado este dispositivo. Por eso una instalación nueva en una conexión funcional informa ONLINE de inmediato, antes de que nadie la haya autorizado en ningún sitio.

Trate ONLINE como una afirmación sobre la fontanería y el estado de cada red como una afirmación sobre la pertenencia. Usar uno para explicar el otro es donde empieza la mayor parte de esta confusión.

Qué le pide ACCESS_DENIED

En una red privada el controlador mantiene una lista de miembros. Un nodo que falta de esa lista, o que figura en ella sin estar autorizado, recibe ACCESS_DENIED sin configuración más allá del apretón de manos básico. La corrección está del lado del controlador y necesita la dirección del nodo en lugar del nombre de la máquina, así que compare la dirección de la salida de su cliente con la entrada de miembro y autorice esa entrada.

Reinstalar el cliente es el primer paso equivocado, porque una instalación nueva trae una identidad nueva y la autorización antigua ya no se le aplica. Si la red es pública, el mismo estado apunta a otra condición, así que pregunte al propietario del controlador si la red es privada antes de pedir aprobación. Esa sola pregunta decide el resto de la conversación.

El texto de estado es una rama, no un veredicto

Cada estado estrecha la siguiente comprobación, y leerlos como un único mensaje de fallo es lo que convierte una corrección de dos minutos en una tarde entera de reinstalaciones. NOT_FOUND significa que el identificador que escribió no existe en ese controlador, así que la cuestión de la pertenencia aún no se ha planteado. REQUESTING_CONFIGURATION significa que el nodo llegó al controlador y espera una configuración que no llega, lo que apunta a la ruta y no a la autorización. OK significa que la pertenencia y la configuración están en su sitio, así que la siguiente pregunta es la dirección asignada y después el servicio mismo.

Dos comandos separan todo esto, y ambos leen el mismo cliente. La referencia de la CLI de ZeroTier enumera las cadenas de estado por red que devuelven. El primer comando es la vista del servicio y el segundo es por red:

zerotier-cli status
zerotier-cli listnetworks

Guarde el texto de estado cuando pida ayuda al administrador. Un comando de unión local que imprimió una confirmación solo demuestra que la solicitud se aceptó localmente, lo cual es un hecho distinto de ser admitido.

La pertenencia pertenece a una identidad

El controlador reconoce los archivos de identidad del cliente, por eso copiar una configuración a otra máquina o borrar la identidad durante una reinstalación produce un miembro que el controlador nunca ha visto. Es también por eso por lo que borrar un registro de miembro es distinto de desautorizarlo. Un nodo autorizado que sigue funcionando sigue intentándolo, y un registro borrado en lugar de revocado puede volver como una solicitud nueva desde la misma dirección.

Cuando retire un dispositivo, revóquelo primero y confirme que la entrada refleja ese estado antes de quitar nada. El orden es la diferencia entre una retirada limpia y una reincorporación misteriosa.

Verifique después del cambio

Vuelva a leer la entrada de la red en lugar del comando que hizo el cambio. Cuatro preguntas cubren el resultado, y cualquiera de ellas puede estar mal mientras las demás parecen correctas:

zerotier-cli listnetworks
ip -br addr show
ping -c 2 10.147.20.5
ip route get 10.147.20.5

La primera imprime la pertenencia y la dirección asignada para cada red, y la segunda muestra si una interfaz recibió realmente esa dirección. Las dos últimas prueban que un par de la red responde y qué interfaz lleva el tráfico. Anote qué comando respondió a qué pregunta, para que la siguiente persona empiece por la evidencia y no por la memoria.

Si la pertenencia es OK y la dirección está presente pero los pares no responden, el problema se ha trasladado al enrutamiento o a la política del propio par. Saque el texto de estado de esa conversación, porque ya ha hecho su trabajo. El registro de pertenencia y la ruta son temas separados, y cuanto antes se separen, más corta será la investigación.