Ջնջված ZeroTier անդամը վերադառնում է՝ նախ չեղարկեք թույլտվությունը

Դուք ջնջում եք անդամին, փակում էջը, և մեկ օր անց նույն սարքը նորից այստեղ է։ Սա կոնսոլի սխալ չէ։ Սա տեղի է ունենում, երբ գրառումը ջնջվում է, մինչ սարքը դեռ ցանցում է և դեռ միանալու հայտ է ներկայացնում։

Երկու գործողություն կողք կողքի են և տարբեր աշխատանք են կատարում։ Մեկը որոշում է հասանելիությունը, մյուսը միայն կարգի է բերում ցանկը։

Սկսեք վերադարձող գրառումից

Բացեք ցանցը և նայեք վերադարձած գրառմանը։ Գրանցեք նրա node ID-ն, վերջին հասցեն և այն ժամը, երբ նորից հայտնվեց։ Համեմատեք այն սարքի հետ, որը ցանկանում էիք դուրս բերել շահագործումից։ Ցուցադրվող անունը այն է, ինչ ինչ-որ մեկը մուտքագրել է, իսկ հասցեն կարող է փոխվել հաջորդ միացման ժամանակ։

Node ID-ն կայուն նույնացուցիչն է։ Ցանցի ID-ն անվանում է ցանցը, այնպես որ այն ասում է, թե որ ցանկն եք կարդում, և ոչինչ այն մասին, թե որ սարքն է դրա մեջ։ Գրանցեք երկուսն էլ, ապա համադրեք node ID-ն այն մեքենայի հետ, որը ցանկանում էիք դուրս բերել շահագործումից։

Եթե այս համեմատությունը սխալ անեք, կհեռացնեք աշխատող մեքենա, մինչ անցանկալին շարունակում է հայտ ներկայացնել։ Այդ ժամանակ ցանկը մեկ օր ճիշտ է թվում։ Դա բավական է, որ ոչ ոք չնկատի, և հենց դա է խնդիրը։

Չեղարկեք մինչ ջնջելը

Նախ փոխեք թույլտվության վիճակը կարգավորիչի աջակցած աշխատահոսքի միջոցով։ Այդ պահից միանալու փորձը ցուցադրվում է որպես չթույլատրված՝ հանգիստ հասանելիությունը վերականգնելու փոխարեն, և հայտը տեսանելի է, ոչ թե անտեսանելի։

Ջնջումը գալիս է դրանից հետո, երբեք դրա փոխարեն։ Թույլատրված անդամի գրառումը հեռացնելուց ոչինչ չի մնում չեղարկելու։ Սարքը նորից հարցնում է, և կարգավորիչը դրան վերաբերվում է որպես նորի։

Մեքենայի համար, որը դեռ վերահսկում եք, ցանցից դուրս գալը շահագործումից դուրս բերման օգտակար մասն է։ Դա չի փոխարինում կորցրած սարքի վերաբերյալ ադմինիստրատորի որոշմանը։ Այն հաճախորդը, որը այլևս ձեր վերահսկողության տակ չէ, կարող է անտեսել ամեն ինչ, ինչ ասվել է նրան։

Որտեղ են գտնվում երկու գործողությունները

Հոսթինգով կարգավորիչի վրա անդամների ցանկը առաջարկում է երկու գործողություններն էլ և դրանք պիտակավորում է բավական պարզ, որ տարբերվեն։ Ինքնուրույն հոսթինգով կարգավորիչի վրա նույն տարբերությունը երևում է API-ում և տեղական կոնֆիգուրացիայում, և սովորաբար շփոթությունը սկսվում է հենց այնտեղ։

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

Այս երկու կանչերը բավական են ցույց տալու, թե արդյոք անդամը երբևէ իսկապես առանց թույլտվության է եղել։ Գրառումը, որը նորից ու նորից վերադառնում է authorized: true արժեքով, երբեք չեղարկված չի եղել. այն պարզապես ջնջվել է։

Հաստատեք ռեսուրսից, ոչ թե ցանկից

Կոկիկ անդամների ցանկը հասանելիության ստուգում չէ։ Փորձեք այն ռեսուրսը, որն օգտագործում էր սարքը նախկինում, այդ սարքից կամ նրա հին հասցեն ունեցող մեքենայից, և հաստատեք, որ կապը ձախողվում է։ Ապա հաստատեք, որ հաստատված փոխարինողը դեռ աշխատում է։

Ներառեք երթուղիները և ծառայությունների թույլտվությունները այդ թեստում։ ZeroTier-ը կարող է թույլատրել անդամին և այդուհանդերձ թույլ չտալ նրան հասնել կառավարվող երթուղու։ Հավելվածի թույլտվությունը կարող է նույն կերպ ձախողվել։ Երկուսն էլ անդամների ցանկից նույն տեսքն ունեն։

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

Ինքնուրույն հոսթինգով կարգավորիչի համար պահեք նրա ինքնության և կոնֆիգուրացիայի հետևողական պահուստային պատճեն։ Վերականգնումը, որը վերադառնում է ավելի վաղ վիճակի, կարող է հետ բերել հին թույլտվությունը, և անդամների ցանկը կլինի ճիշտ այնպես, ինչպես մինչ շահագործումից դուրս բերելը։

Շահագործումից դուրս բերելը ավարտված է, երբ հին ինքնությունը ոչնչի չի կարող հասնել, և գրառումը գնացել է։ Արեք դա այս հերթականությամբ, և անդամը կդադարի վերադառնալ։