Eytt ZeroTier-meðlimur kemur aftur: afturkallið heimildina fyrst

Tæki á netinu getur beðið um að ganga inn aftur um leið og færsla þess er fjarlægð. Afturkallið heimildina og lítið síðan á eyðinguna sem hreinsun á listanum.

Þú eyðir meðlimnum, lokar síðunni og degi síðar er sama tækið komið aftur. Það er ekki villa í stjórnborðinu. Þetta gerist þegar færslu er eytt á meðan tækið er enn á netinu og biður enn um að ganga inn.

Tvær aðgerðir standa hlið við hlið og gera ólík störf. Önnur ræður aðgangi, hin lagar bara listann til.

Byrjið á færslunni sem kemur aftur

Opnið netið og skoðið færsluna sem kom aftur. Skráið node ID hennar, síðustu vistfang og tímann þegar hún birtist aftur. Berið það saman við tækið sem þið ætluðuð að taka úr notkun. Sýnilegt heiti er það sem einhver sló inn, og vistfangið getur breyst við næstu innkomu.

Node ID er stöðugi auðkennið. Net-ID gefur netinu nafn, þannig að það segir þér hvaða lista þú ert að lesa og ekkert um hvaða tæki er í honum. Skráið bæði og berið síðan node ID saman við vélina sem þið ætluðuð að taka úr notkun.

Ef þið ruglið þessari samanburði, fjarlægið þið vél sem virkar á meðan hin óæskilega heldur áfram að biðja. Þá lítur listinn rétt út í einn dag. Það er nógu langur tími til að enginn taki eftir því, og einmitt það er vandamálið.

Afturkallið áður en þið eyðið

Breyið fyrst heimildastöðuna í gegnum það vinnuflæði sem stjórnandinn styður. Frá þeim tíma birtist innkomutilraun sem óheimiluð í stað þess að endurheimta aðgang hljóðlega, og beiðnin er sýnileg í staðinn fyrir ósýnilega.

Eyðingin kemur á eftir, aldrei í staðinn. Að fjarlægja færslu heimilaðs meðlims skilur ekkert eftir til að afturkalla. Tækið spyr aftur og stjórnandinn meðhöndlar það sem nýtt.

Fyrir vél sem þið stjórnið enn er að yfirgefa netið gagnlegur hluti af því að taka hana úr notkun. Það kemur ekki í stað ákvörðunar stjórnandans um týnt tæki. Biðlari sem þið stjórnið ekki lengur getur hunsað hvað sem sagt var við hann.

Hvar aðgerðirnar tvær eru

Á hýstum stjórnanda býður meðlimlistinn báðar aðgerðirnar og merkir þær nógu skýrt til að greina þær. Á stjórnanda sem þið hýsið sjálf birtist sami munurinn í API og í staðbundinni uppsetningu, og þaðan byrjar ruglingurinn venjulega.

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

Þessi tvö köll nægja til að sýna hvort meðlimurinn hafi nokkurn tíma verið raunverulega óheimilaður. Færsla sem kemur aftur og aftur með authorized: true var aldrei afturkölluð; henni var bara eytt.

Staðfestið út frá auðlindinni, ekki listanum

Snyrtilegur meðlimlisti er ekki aðgangsprófun. Prófið auðlindina sem tækið notaði áður, frá því tæki eða frá vél sem geymir gamla vistfangið hans, og staðfestið að tengingin mistakist. Staðfestið síðan að samþykkt staðgengill virki enn.

Takið leiðir og þjónustuheimildir með í þá prófun. ZeroTier getur heimilað meðlim og samt látið hann ekki komast að stýrðri leið. Heimild forrits getur mistekist á sama hátt. Báðar líta eins út frá meðlimlistanum.

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

Fyrir stjórnanda sem þið hýsið sjálf skuluð þið halda samkvæmri öryggisafritun af auðkenni hans og uppsetningu. Endurheimt sem rúllar aftur í fyrra ástand getur fært gamla heimild til baka og meðlimlistinn mun líta nákvæmlega út eins og fyrir töku úr notkun.

Takan úr notkun er lokið þegar gamla auðkennið kemst hvergi og færslan er farin. Gerið það í þessari röð og meðlimurinn hættir að koma aftur.

Tengdir greinar