Izbrisan član ZeroTier se vrača: najprej prekličite avtorizacijo

Izbrišete člana, zaprete stran in dan kasneje je ista naprava spet tukaj. To ni napaka v konzoli. To se zgodi, ko se zapis izbriše, medtem ko je naprava še v omrežju in še vedno prosi za pridružitev.

Dve operaciji stojita druga ob drugi in opravljata različno delo. Ena odloča o dostopu, druga samo pospravlja seznam.

Začnite pri zapisu, ki se vrača

Odprite omrežje in poglejte vnos, ki se je vrnil. Zapišite njegov node ID, zadnji naslov in čas, ko se je znova pojavil. Primerjajte to z napravo, ki ste jo nameravali umakniti. Prikazano ime je tisto, kar je nekdo vpisal, naslov pa se lahko ob naslednji pridružitvi spremeni.

Node ID je stabilni identifikator. ID omrežja poimenuje omrežje, zato vam pove, kateri seznam berete, in nič o tem, katera naprava je v njem. Zapišite oboje in nato primerjajte node ID s strojem, ki ste ga nameravali umakniti.

Če to primerjavo zgrešite, odstranite delujoč stroj, medtem ko nezaželena naprava še naprej prosi. Seznam je potem videti pravilen en dan. To je dovolj dolgo, da tega nihče ne opazi, in prav v tem je težava.

Prekličite, preden izbrišete

Najprej spremenite stanje avtorizacije po delovnem toku, ki ga krmilnik podpira. Od tega trenutka se poskus pridružitve prikaže kot neavtoriziran, namesto da bi tiho obnovil dostop, in zahteva je vidna, ne nevidna.

Brisanje pride zatem, nikoli namesto tega. Če odstranite zapis avtoriziranega člana, ne ostane nič za preklic. Naprava znova vpraša in krmilnik jo obravnava kot novo.

Za stroj, ki ga še nadzorujete, je zapustitev omrežja koristen del umika. Ne nadomešča odločitve skrbnika o izgubljeni napravi. Odjemalec, ki ga ne nadzorujete več, lahko prezre vse, kar mu je bilo rečeno.

Kje sta obe operaciji

Na gostujočem krmilniku seznam članov ponuja obe dejanji in ju označuje dovolj jasno, da ju je mogoče ločiti. Na lastnem krmilniku se ista razlika pojavi v API in v lokalni konfiguraciji, in tam se zmeda običajno začne.

# 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 klica zadoščata, da pokažeta, ali je bil član kdaj res neavtoriziran. Zapis, ki se vedno znova vrača z authorized: true, ni bil nikoli preklican; bil je samo izbrisan.

Preverite pri viru, ne na seznamu

Urejen seznam članov ni preverjanje dostopa. Preizkusite vir, ki ga je naprava uporabljala prej, s te naprave ali s stroja s starim naslovom, in potrdite, da povezava ne uspe. Nato potrdite, da odobrena zamenjava še deluje.

V ta preizkus vključite poti in dovoljenja storitev. ZeroTier lahko člana avtorizira in mu kljub temu ne dovoli doseči upravljane poti. Dovoljenje aplikacije lahko spodleti na enak način. S seznama članov sta oba primera videti enako.

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

Pri lastnem krmilniku vzdržujte dosledno varnostno kopijo njegove identitete in konfiguracije. Obnovitev, ki se vrne v prejšnje stanje, lahko prinese nazaj staro avtorizacijo, in seznam članov bo videti točno tako kot pred umikom.

Umik je končan, ko stara identiteta ne more doseči ničesar in zapisa ni več. Naredite to v tem vrstnem redu in član se neha vračati.