हटवलेला 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

स्वतः होस्ट केलेल्या नियंत्रकासाठी त्याच्या ओळखीची आणि संरचनेची सुसंगत बॅकअप प्रत ठेवा. जुन्या स्थितीत परत जाणारे पुनर्संचयन जुनी अनुमतीही सोबत आणू शकते, आणि सदस्य यादी निवृत्तीपूर्वीच्या सारखीच दिसेल.

जुनी ओळख कुठेही पोहोचू शकत नाही आणि नोंद गेली आहे तेव्हा निवृत्ती पूर्ण होते. हे याच क्रमाने करा आणि सदस्य परत येणे थांबवेल.