हटाया गया 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

स्वयं-होस्ट किए गए नियंत्रक के लिए उसकी पहचान और कॉन्फ़िगरेशन का सुसंगत बैकअप रखें। पुरानी स्थिति में लौटने वाला पुनर्स्थापन पुरानी अनुमति भी साथ ला सकता है, और सदस्य सूची सेवानिवृत्ति से पहले जैसी ही दिखेगी।

सेवानिवृत्ति तब पूरी होती है जब पुरानी पहचान कहीं नहीं पहुँच सकती और रिकॉर्ड जा चुका है। ये काम इसी क्रम में करें और सदस्य लौटना बंद कर देगा।