Izbrisani ZeroTier član vraća se: prvo opozovite autorizaciju

Izbrišete člana, zatvorite stranicu, a dan kasnije isti je uređaj ponovno tu. To nije pogreška u konzoli. To se događa kada se zapis izbriše dok je uređaj još na mreži i još traži pridruživanje.

Dvije operacije stoje jedna uz drugu i rade različite poslove. Jedna odlučuje o pristupu, a druga samo posprema popis.

Počnite od zapisa koji se vraća

Otvorite mrežu i pogledajte unos koji se vratio. Zabilježite njegov node ID, posljednju adresu i vrijeme kada se ponovno pojavio. Usporedite to s uređajem koji ste namjeravali povući iz upotrebe. Prikazano ime je ono što je netko upisao, a adresa se može promijeniti pri sljedećem pridruživanju.

Node ID je stabilni identifikator. ID mreže imenuje mrežu, pa vam kaže koji popis čitate i ništa o tome koji je uređaj u njemu. Zabilježite oboje, zatim uparite node ID sa strojem koji ste namjeravali povući iz upotrebe.

Pogriješite li u toj usporedbi, uklonit ćete stroj koji radi dok neželjeni nastavlja tražiti. Popis tada izgleda ispravno jedan dan. To je dovoljno dugo da nitko ne primijeti, i upravo je to problem.

Opozovite prije nego što izbrišete

Najprije promijenite stanje autorizacije kroz tijek rada koji kontroler podržava. Od tog trenutka pokušaj pridruživanja pojavljuje se kao neautoriziran umjesto da tiho obnovi pristup, a zahtjev je vidljiv, a ne nevidljiv.

Brisanje dolazi poslije, nikada umjesto toga. Uklanjanjem zapisa autoriziranog člana ne ostaje ništa za opoziv. Uređaj ponovno pita, a kontroler ga tretira kao novi.

Za stroj koji još kontrolirate, napuštanje mreže koristan je dio povlačenja iz upotrebe. Ono nije zamjena za odluku administratora o izgubljenom uređaju. Klijent koji više ne kontrolirate može ignorirati sve što mu je rečeno.

Gdje se nalaze dvije operacije

Na hostanom kontroleru popis članova nudi obje radnje i označava ih dovoljno jasno da se razlikuju. Na samostalno hostanom kontroleru ista razlika pojavljuje se u API-ju i u lokalnoj konfiguraciji, i tu obično počinje zabuna.

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

Ta dva poziva dovoljna su da pokažu je li član ikada doista bio neautoriziran. Zapis koji se stalno vraća s authorized: true, nikada nije opozvan; samo je izbrisan.

Potvrdite na resursu, ne na popisu

Uredan popis članova nije provjera pristupa. Isprobajte resurs koji je uređaj prije rabio, s tog uređaja ili sa stroja koji ima njegovu staru adresu, i potvrdite da veza ne uspijeva. Zatim potvrdite da odobrena zamjena još radi.

Uključite rute i dozvole servisa u taj test. ZeroTier može autorizirati člana i ipak mu ne dopustiti da dosegne upravljanu rutu. Dozvola aplikacije može pasti na isti način. Obje izgledaju jednako s popisa članova.

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

Za samostalno hostan kontroler držite dosljednu sigurnosnu kopiju njegova identiteta i konfiguracije. Vraćanje na ranije stanje može sa sobom vratiti staru autorizaciju, a popis članova izgledat će točno kao prije povlačenja.

Povlačenje je dovršeno kada stari identitet ne može dosegnuti ništa i zapis je nestao. Učinite to tim redom i član prestaje dolaziti.