ZeroTier ONLINE ma ACCESS_DENIED: dove si interviene?

ZeroTier segnala ONLINE a livello di servizio e ACCESS_DENIED a livello di rete, e la coppia non è una contraddizione. Il primo è un’affermazione sul percorso tra il tuo client e l’infrastruttura di coordinamento. Il secondo è un’affermazione sulla lista dei membri di una rete. Leggili separatamente e la combinazione ti dice esattamente dove guardare.

Che cosa misura ONLINE

Il comando di stato segnala se il servizio locale ha un percorso funzionante verso i server root che coordinano la scoperta dei peer. Non dice nulla su una singola rete e nulla sul fatto che un controller abbia approvato questo dispositivo. Un’installazione nuova su una connessione funzionante riporta quindi ONLINE subito, prima che qualcuno l’abbia autorizzata da qualche parte.

Considera ONLINE un’affermazione sull’impianto e lo stato per rete un’affermazione sull’appartenenza. Usare l’uno per spiegare l’altro è il punto in cui nasce gran parte di questa confusione.

Che cosa chiede ACCESS_DENIED

Su una rete privata il controller tiene una lista dei membri. Un nodo assente da quella lista, o elencato ma non autorizzato, riceve ACCESS_DENIED insieme a nessuna configurazione oltre all’handshake di base. La correzione è lato controller e richiede l’indirizzo del nodo invece del nome della macchina, quindi confronta l’indirizzo nell’output del client con la voce del membro e autorizza quella voce.

Reinstallare il client è la prima mossa sbagliata, perché una nuova installazione porta una nuova identità e la vecchia autorizzazione non vale più per essa. Se la rete è pubblica, lo stesso stato indica una condizione diversa, quindi chiedi al proprietario del controller se la rete è privata prima di richiedere l’approvazione. Quella sola domanda decide il resto della conversazione.

Il testo di stato è un ramo, non un verdetto

Ogni stato restringe il controllo successivo, e leggerli come un unico messaggio di errore è ciò che trasforma una correzione di due minuti in un pomeriggio di reinstallazioni. NOT_FOUND significa che l’identificatore digitato non esiste su quel controller, quindi la domanda sull’appartenenza non è ancora stata raggiunta. REQUESTING_CONFIGURATION significa che il nodo ha raggiunto il controller e attende una configurazione che non arriva, il che punta al percorso e non all’autorizzazione. OK significa che appartenenza e configurazione sono a posto, quindi la domanda successiva è l’indirizzo assegnato e poi il servizio stesso.

Due comandi separano tutto questo, ed entrambi leggono lo stesso client. Il riferimento della CLI di ZeroTier elenca le stringhe di stato per rete che restituiscono. Il primo comando è la vista del servizio e il secondo è per rete:

zerotier-cli status
zerotier-cli listnetworks

Conserva il testo di stato quando chiedi aiuto all’amministratore. Un comando di join locale che ha stampato una conferma prova solo che la richiesta è stata accettata localmente, che è un fatto diverso dall’essere ammessi.

L’appartenenza appartiene a un’identità

Sono i file di identità del client ciò che il controller riconosce, quindi copiare una configurazione su un’altra macchina o cancellare l’identità durante una reinstallazione produce un membro che il controller non ha mai visto. È anche il motivo per cui eliminare un record di membro è diverso dal revocarne l’autorizzazione. Un nodo autorizzato ancora in esecuzione continua a provare, e un record cancellato invece che revocato può tornare come nuova richiesta dallo stesso indirizzo.

Quando dismetti un dispositivo, revoca prima e conferma che la voce rifletta quello stato prima di rimuovere qualsiasi cosa. L’ordine è la differenza tra una rimozione pulita e un rientro misterioso.

Verifica dopo la modifica

Rileggi la voce di rete invece del comando che ha fatto la modifica. Quattro domande coprono l’esito, e una qualsiasi di esse può essere sbagliata mentre le altre sembrano giuste:

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

Il primo stampa l’appartenenza e l’indirizzo assegnato per ogni rete, e il secondo mostra se un’interfaccia ha effettivamente ricevuto quell’indirizzo. Gli ultimi due dimostrano che un peer sulla rete risponde e quale interfaccia porta il traffico. Annota quale comando ha risposto a quale domanda, così la persona successiva parte da prove e non dalla memoria.

Se l’appartenenza è OK e l’indirizzo è presente ma i peer non rispondono, il problema si è spostato sull’instradamento o sulla policy del peer stesso. Togli il testo di stato da quella conversazione, perché ha già fatto il suo lavoro. Il record di appartenenza e il percorso sono soggetti separati, e prima si separano, più breve diventa l’indagine.