Membrul ZeroTier șters revine: revocați mai întâi autorizarea

Un dispozitiv conectat poate cere din nou să se alăture imediat ce înregistrarea îi este eliminată. Revocați autorizarea, apoi tratați ștergerea ca o curățare a listei.

Ștergeți membrul, închideți pagina și, o zi mai târziu, același dispozitiv este din nou acolo. Nu este o eroare a consolei. Este ceea ce se întâmplă când o înregistrare este ștearsă în timp ce dispozitivul este încă online și încă cere să se alăture.

Două operații stau una lângă alta și fac treburi diferite. Una decide accesul, cealaltă doar aranjează lista.

Începeți cu înregistrarea care revine

Deschideți rețeaua și priviți intrarea care a revenit. Notați node ID-ul, ultima adresă și momentul în care a reapărut. Comparați cu dispozitivul pe care voiați să îl retrageți. Numele afișat este ceea ce a tastat cineva, iar adresa se poate schimba la următoarea alăturare.

Node ID-ul este identificatorul stabil. Un ID de rețea dă nume rețelei, așa că vă spune ce listă citiți și nimic despre ce dispozitiv se află în ea. Notați ambele, apoi potriviți node ID-ul cu mașina pe care voiați să o retrageți.

Dacă greșiți această comparație, veți elimina o mașină care funcționează în timp ce dispozitivul nedorit continuă să ceară. Atunci lista pare corectă timp de o zi. Este suficient ca nimeni să nu observe, și exact aceasta este problema.

Revocați înainte de a șterge

Mai întâi schimbați starea autorizării prin fluxul de lucru acceptat de controler. Din acel moment, o încercare de alăturare apare ca neautorizată în loc să restabilească accesul în tăcere, iar cererea este vizibilă și nu invizibilă.

Ștergerea vine după, niciodată în locul ei. Eliminarea înregistrării unui membru autorizat nu lasă nimic de revocat. Dispozitivul întreabă din nou, iar controlerul îl tratează ca nou.

Pentru o mașină pe care o mai controlați, părăsirea rețelei este o parte utilă a retragerii. Nu înlocuiește decizia administratorului privind un dispozitiv pierdut. Un client pe care nu îl mai controlați poate ignora orice i s-a spus.

Unde se află cele două operații

Pe un controler găzduit, lista de membri oferă ambele acțiuni și le etichetează suficient de clar pentru a le distinge. Pe un controler auto-găzduit, aceeași distincție apare în API și în configurația locală, și de acolo începe de obicei confuzia.

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

Aceste două apeluri sunt suficiente pentru a arăta dacă membrul a fost vreodată cu adevărat neautorizat. O înregistrare care revine mereu cu authorized: true nu a fost niciodată revocată; a fost doar ștearsă.

Verificați din resursă, nu din listă

O listă de membri ordonată nu este o verificare a accesului. Încercați resursa pe care dispozitivul o folosea înainte, de pe acel dispozitiv sau de pe o mașină care are adresa lui veche, și confirmați că conexiunea eșuează. Apoi confirmați că un înlocuitor aprobat încă funcționează.

Includeți rutele și permisiunile de serviciu în acel test. ZeroTier poate autoriza un membru și totuși să îl lase incapabil să ajungă la o rută gestionată. O permisiune de aplicație poate eșua în același fel. Ambele arată identic din lista de membri.

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

Pentru un controler auto-găzduit, păstrați o copie de siguranță consecventă a identității și configurației sale. O restaurare care revine la o stare anterioară poate aduce înapoi o autorizare veche, iar lista de membri va arăta exact ca înainte de retragere.

Retragerea este încheiată când identitatea veche nu mai poate ajunge la nimic și înregistrarea a dispărut. Faceți asta în această ordine și membrul nu va mai reveni.

Articole similare