Il membro ZeroTier eliminato torna: revoca prima l'autorizzazione

Elimini il membro, chiudi la pagina e un giorno dopo lo stesso dispositivo è di nuovo lì. Non è un bug della console. È quello che succede quando un record viene eliminato mentre il dispositivo è ancora in linea e chiede ancora di unirsi.

Due operazioni vivono una accanto all'altra e fanno lavori diversi. Una decide l'accesso, l'altra si limita a riordinare l'elenco.

Parti dal record che riappare

Apri la rete e guarda la voce tornata. Annota il suo node ID, il suo ultimo indirizzo e l'ora in cui è riapparsa. Confrontala con il dispositivo che volevi dismettere. Il nome visualizzato è quello che qualcuno ha digitato, e l'indirizzo può cambiare alla prossima unione.

Il node ID è l'identificatore stabile. Un ID di rete dà un nome alla rete, quindi ti dice quale elenco stai leggendo e nulla su quale dispositivo ci sia dentro. Annota entrambi, poi confronta il node ID con la macchina che volevi dismettere.

Se sbagli quel confronto, rimuovi una macchina che funziona mentre quella indesiderata continua a chiedere. L'elenco allora sembra corretto per un giorno. È tempo sufficiente perché nessuno se ne accorga, ed è esattamente il problema.

Revoca prima di eliminare

Cambia prima lo stato di autorizzazione tramite il flusso di lavoro supportato dal controller. Da quel momento, un tentativo di unione appare come non autorizzato invece di ripristinare l'accesso in silenzio, e la richiesta è visibile anziché invisibile.

L'eliminazione viene dopo, mai al suo posto. Rimuovere il record di un membro autorizzato non lascia nulla da revocare. Il dispositivo chiede di nuovo e il controller lo tratta come nuovo.

Per una macchina che controlli ancora, uscire dalla rete è una parte utile della dismissione. Non sostituisce la decisione dell'amministratore su un dispositivo smarrito. Un client che non controlli più può ignorare qualunque cosa gli sia stata detta.

Dove vivono le due operazioni

Su un controller ospitato, l'elenco dei membri offre entrambe le azioni e le etichetta in modo abbastanza chiaro da distinguerle. Su un controller auto-ospitato, la stessa distinzione compare nell'API e nella configurazione locale, ed è lì che di solito inizia la confusione.

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

Queste due chiamate bastano a mostrare se il membro è mai stato davvero non autorizzato. Un record che torna ancora e ancora con authorized: true non è mai stato revocato; è stato solo eliminato.

Verifica dalla risorsa, non dall'elenco

Un elenco dei membri ordinato non è un controllo degli accessi. Prova la risorsa che il dispositivo usava prima, da quel dispositivo o da una macchina che ne conserva il vecchio indirizzo, e conferma che la connessione fallisce. Poi conferma che un sostituto approvato funziona ancora.

Includi route e permessi di servizio in quel test. ZeroTier può autorizzare un membro e lasciarlo comunque incapace di raggiungere una route gestita. Un permesso applicativo può fallire allo stesso modo. Entrambi appaiono identici dall'elenco dei membri.

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

Su un controller auto-ospitato, mantieni un backup coerente della sua identità e della sua configurazione. Un ripristino che torna a uno stato precedente può riportare con sé una vecchia autorizzazione, e l'elenco dei membri apparirà esattamente come prima della dismissione.

La dismissione è conclusa quando la vecchia identità non può raggiungere nulla e il record è sparito. Fallo in quest'ordine e il membro smette di tornare.