Kustutatud ZeroTier-liige tuleb tagasi: tühista esmalt volitus

Kustutad liikme, sulged lehe ja päev hiljem on sama seade jälle kohal. See ei ole konsooli viga. Nii juhtub siis, kui kirje kustutatakse, kui seade on veel võrgus ja palub ikka veel liituda.

Kaks toimingut seisavad kõrvuti ja teevad erinevat tööd. Üks otsustab juurdepääsu, teine ainult korrastab loendit.

Alusta kirjest, mis naaseb

Ava võrk ja vaata kirjet, mis tagasi tuli. Pane kirja selle node ID, viimane aadress ja aeg, millal see uuesti ilmus. Võrdle seda seadmega, mille kavatsesid kasutusest välja viia. Kuvatav nimi on see, mille keegi trükkis, ja aadress võib järgmisel liitumisel muutuda.

Node ID on püsiv identifikaator. Võrgu ID nimetab võrku, seega ütleb see, millist loendit sa loed, ja mitte midagi selle kohta, milline seade selles on. Pane kirja mõlemad ja sobitage seejärel node ID masinaga, mille kavatsesid kasutusest välja viia.

Kui teed selle võrdluse valesti, eemaldad töötava masina, samal ajal kui soovimatu masin jätkab küsimist. Siis näib loend ühe päeva jooksul õige. Sellest piisab, et keegi ei märkaks, ja täpselt selles on probleem.

Tühista enne kustutamist

Muuda esmalt volituse olekut kontrolleri toetatud töövoo kaudu. Sellest hetkest ilmub liitumiskatse volitamata katsena, selle asemel et juurdepääs vaikselt taastada, ja taotlus on nähtav, mitte nähtamatu.

Kustutamine tuleb pärast, mitte kunagi selle asemel. Volitatud liikme kirje eemaldamine ei jäta midagi tühistada. Seade küsib uuesti ja kontroller kohtleb seda uuena.

Masina puhul, mida sa veel kontrollid, on võrgust lahkumine kasutusest väljaviimise kasulik osa. See ei asenda administraatori otsust kadunud seadme kohta. Klient, mida sa enam ei kontrolli, võib eirata kõike, mida talle öeldi.

Kus need kaks toimingut asuvad

Majutatud kontrolleril pakub liikmete loend mõlemat tegevust ja märgistab need piisavalt selgelt, et neid eristada. Isemajutatud kontrolleril ilmneb sama erinevus API-s ja kohalikus konfiguratsioonis, ja just sealt hakkab segadus tavaliselt pihta.

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

Need kaks päringut on piisavad, et näidata, kas liige oli kunagi tõesti volitamata. Kirje, mis tuleb ikka ja jälle tagasi väärtusega authorized: true, ei olnud kunagi tühistatud; see lihtsalt kustutati.

Kinnita ressursi, mitte loendi järgi

Korrastatud liikmete loend ei ole juurdepääsukontroll. Proovi ressurssi, mida seade varem kasutas, sellelt seadmelt või masinalt, millel on selle vana aadress, ja kinnita, et ühendus ebaõnnestub. Seejärel kinnita, et kinnitatud asendus ikka töötab.

Lisa sellesse testi marsruudid ja teenuseõigused. ZeroTier võib liikme volitada ja siiski jätta ta hallatavale marsruudile jõudmata. Rakenduse õigus võib samamoodi ebaõnnestuda. Mõlemad näevad liikmete loendist ühesugused välja.

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

Isemajutatud kontrolleri puhul hoia selle identiteedist ja konfiguratsioonist järjepidevat varukoopiat. Varunduse taastamine varasemasse olekusse võib tuua tagasi vana volituse ja liikmete loend näeb välja täpselt nagu enne kasutusest väljaviimist.

Kasutusest väljaviimine on lõpetatud, kui vana identiteet ei saa midagi kätte ja kirje on kadunud. Tee seda selles järjekorras ja liige lakkab tagasi tulemast.