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

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

Dvije operacije stoje jedna pored druge i rade različite poslove. Jedna odlučuje o pristupu, a druga samo sređuje listu.

Pođite 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 ponovo pojavio. Uporedite to sa uređajem koji ste namjeravali povući iz upotrebe. Prikazano ime je ono što je neko otipkao, 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 koju listu čitate i ništa o tome koji je uređaj u njoj. Zabilježite oboje, zatim uparite node ID sa mašinom koju ste namjeravali povući iz upotrebe.

Pogriješite li u tom poređenju, uklonit ćete mašinu koja radi dok neželjena nastavlja tražiti. Lista tada izgleda ispravno jedan dan. To je dovoljno dugo da niko ne primijeti, i upravo je to problem.

Opozovite prije nego što izbrišete

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

Brisanje dolazi poslije, nikada umjesto toga. Uklanjanje zapisa autorizovanog člana ne ostavlja ništa za opoziv. Uređaj ponovo pita, a kontroler ga tretira kao novi.

Za mašinu koju još kontrolišete, 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 kontrolišete može ignorisati sve što mu je rečeno.

Gdje se nalaze dvije operacije

Na hostovanom kontroleru lista članova nudi obje akcije i označava ih dovoljno jasno da se razlikuju. Na samostalno hostovanom 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 zaista bio neautorizovan. Zapis koji se stalno vraća sa authorized: true, nikada nije opozvan; samo je izbrisan.

Potvrdite s resursa, ne s liste

Uredna lista članova nije provjera pristupa. Isprobajte resurs koji je uređaj koristio prije, s tog uređaja ili s mašine koja 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 autorizovati člana i ipak mu ne dopustiti da dosegne upravljanu rutu. Dozvola aplikacije može pasti na isti način. Obje izgledaju identično s liste članova.

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

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

Povlačenje je završeno kada stari identitet ne može dosegnuti ništa i zapis je nestao. Uradite to tim redom i član prestaje da se vraća.