हटाइएको 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

आफैं होस्ट गरिएको नियन्त्रकका लागि यसको पहिचान र कन्फिगरेसनको सुसंगत ब्याकअप राख्नुहोस्। अघिल्लो अवस्थामा फर्कने पुनःस्थापनाले पुरानो अनुमति पनि सँगै ल्याउन सक्छ, र सदस्य सूची रिटायर अघिको जस्तै देखिनेछ।

पुरानो पहिचान कतै पुग्न नसकेको र रेकर्ड हटिसकेको अवस्थामा रिटायर पूरा हुन्छ। यी काम यही क्रममा गर्नुहोस्, सदस्य फेरि आउन छाड्नेछ।