Anëtari i fshirë i ZeroTier kthehet: së pari revokoni autorizimin

E fshini anëtarin, e mbyllni faqen dhe një ditë më vonë e njëjta pajisje është përsëri aty. Ky nuk është defekt në konsolë. Kjo ndodh kur një regjistër fshihet ndërsa pajisja është ende në linjë dhe ende kërkon të bashkohet.

Dy operacione qëndrojnë pranë njëri-tjetrit dhe bëjnë punë të ndryshme. Njëri vendos aksesin, tjetri thjesht rregullon listën.

Filloni nga regjistri që kthehet

Hapni rrjetin dhe shikoni hyrjen që u kthye. Shënoni node ID-në, adresën e fundit dhe kohën kur u shfaq përsëri. Krahasoni me pajisjen që donit të tërhiqnit. Emri i shfaqur është ai që dikush ka shtypur, dhe adresa mund të ndryshojë në bashkimin e radhës.

Node ID është identifikuesi i qëndrueshëm. Një ID rrjeti i jep emrin rrjetit, prandaj ju tregon cilën listë po lexoni dhe asgjë për cilën pajisje ndodhet në të. Shënoni të dyja, pastaj përputhni node ID-në me makinën që donit të tërhiqnit.

Nëse e gaboni këtë krahasim, do të hiqni një makinë që punon, ndërsa pajisja e padëshiruar vazhdon të kërkojë. Atëherë lista duket e saktë për një ditë. Kjo është kohë e mjaftueshme që askush të mos e vërë re, dhe pikërisht ky është problemi.

Revokoni përpara se të fshini

Së pari ndryshoni gjendjen e autorizimit përmes rrjedhës së punës që kontrolluesi mbështet. Nga ai moment, një përpjekje për bashkim shfaqet si e paautorizuar në vend që të rivendosë aksesin në heshtje, dhe kërkesa është e dukshme dhe jo e padukshme.

Fshirja vjen më pas, kurrë në vend të saj. Heqja e regjistrit të një anëtari të autorizuar nuk lë asgjë për të revokuar. Pajisja pyet përsëri, dhe kontrolluesi e trajton si të re.

Për një makinë që ende e kontrolloni, dalja nga rrjeti është një pjesë e dobishme e tërheqjes. Nuk zëvendëson vendimin e administratorit për një pajisje të humbur. Një klient që nuk e kontrolloni më mund të injorojë çdo gjë që i është thënë.

Ku ndodhen dy operacionet

Në një kontrollues të strehuar, lista e anëtarëve ofron të dyja veprimet dhe i etiketon mjaftueshëm qartë për t'i dalluar. Në një kontrollues të vetë-strehuar, i njëjti dallim shfaqet në API dhe në konfigurimin lokal, dhe zakonisht aty fillon konfuzioni.

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

Këto dy thirrje mjaftojnë për të treguar nëse anëtari ka qenë ndonjëherë vërtet i paautorizuar. Një regjistër që kthehet vazhdimisht me authorized: true nuk u revokua kurrë; thjesht u fshi.

Verifikoni nga burimi, jo nga lista

Një listë e rregullt anëtarësh nuk është kontroll aksesi. Provoni burimin që pajisja përdorte më parë, nga ajo pajisje ose nga një makinë që mban adresën e saj të vjetër, dhe konfirmoni që lidhja dështon. Pastaj konfirmoni që një zëvendësues i miratuar ende funksionon.

Përfshini rrugët dhe lejet e shërbimit në atë test. ZeroTier mund të autorizojë një anëtar dhe gjithsesi ta lërë të paaftë të arrijë një rrugë të menaxhuar. Një leje aplikacioni mund të dështojë në të njëjtën mënyrë. Të dyja duken njësoj nga lista e anëtarëve.

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

Për një kontrollues të vetë-strehuar, mbani një kopje rezervë të qëndrueshme të identitetit dhe konfigurimit të tij. Një rivendosje që kthehet në një gjendje të mëparshme mund të sjellë me vete një autorizim të vjetër, dhe lista e anëtarëve do të duket saktësisht si përpara tërheqjes.

Tërheqja përfundon kur identiteti i vjetër nuk arrin asgjë dhe regjistri ka humbur. Bëjeni në këtë rend dhe anëtari ndalon së kthyeri.