Sletta ZeroTier-medlem kjem attende: kalla attende godkjenninga først

Du slettar medlemmen, lukkar sida, og ein dag seinare er same eininga attende. Det er ikkje ein feil i konsollen. Det er det som skjer når ein post blir sletta medan eininga framleis er på nett og framleis ber om å bli med.

To operasjonar ligg side om side og gjer ulike arbeidsoppgåver. Den eine avgjer tilgang, den andre ryddar berre i lista.

Start med posten som kjem attende

Opne nettet og sjå på oppføringa som kom attende. Noter node ID-en, siste adresse og tidspunktet ho dukka opp igjen. Samanlikn det med eininga du ville fasa ut. Eit visingsnamn er det nokon har skrive, og adressa kan endre seg ved neste innmelding.

Node ID-en er den stabile identifikatoren. Ein nettverks-ID namngir nettet, så han fortel kva liste du les og ingenting om kva eining som er i henne. Noter båe, og samanlikn deretter node ID-en med maskina du ville fasa ut.

Tek du feil i den samanlikninga, fjernar du ei maskin som verkar medan den uønska held fram med å spørje. Lista ser då rett ut i ein dag. Det er lenge nok til at ingen legg merke til det, og det er nettopp problemet.

Kalla attende før du slettar

Endre først godkjenningstilstanden gjennom arbeidsflyten kontrolløren støttar. Frå det punktet blir eit innmeldingsforsøk vist som uautorisert i staden for å gjenopprette tilgang i det stille, og førespurnaden er synleg i staden for usynleg.

Slettinga kjem etterpå, aldri i staden. Fjernar du posten til ein godkjend medlem, er det ingenting att å kalla attende. Eininga spør igjen, og kontrolløren handsamar henne som ny.

For ei maskin du framleis kontrollerer, er det ei nyttig side av utfasinga å forlate nettet. Det er ikkje ei erstatning for avgjerda til administratoren om ei tapt eining. Ein klient du ikkje lenger kontrollerer, kan ignorere kva han enn har fått beskjed om.

Kvar dei to operasjonane ligg

På ein drifta kontrollør tilbyr medlemslista båe handlingane og merkjer dei tydeleg nok til å skiljast. På ein sjølvdrifta kontrollør viser same skilnaden i API-et og i den lokale konfigurasjonen, og det er der forvirringa vanlegvis byrjar.

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

Desse to kalla er nok til å vise om medlemmen nokon gong faktisk var uautorisert. Ein post som stadig kjem attende med authorized: true blei aldri kalla attende; han blei berre sletta.

Stadfest frå ressursen, ikkje lista

Ei ryddig medlemsliste er ikkje ein tilgangskontroll. Prøv ressursen eininga brukte før, frå den eininga eller frå ei maskin som har den gamle adressa hennar, og stadfest at sambandet feilar. Stadfest deretter at ein godkjend erstatning framleis verkar.

Ta med ruter og tenesteløyve i den testen. ZeroTier kan godkjenne ein medlem og likevel la han vere ute av stand til å nå ei styrt rute. Eit applikasjonsløyve kan feile på same måten. Båe ser like ut frå medlemslista.

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

For ein sjølvdrifta kontrollør, hald ein konsistent tryggingskopi av identiteten og konfigurasjonen. Ei gjenoppretting som rullar attende til ein tidlegare tilstand, kan bringe ei gammal godkjenning med seg, og medlemslista vil sjå nøyaktig ut som før utfasinga.

Utfasinga er ferdig når den gamle identiteten ikkje kan nå noko og posten er borte. Gjer det i den rekkjefølgja, og medlemmen sluttar å kome attende.