ZeroTier सदस्य को OK दिखाता है, नेटवर्क जुड़ा है, और फिर भी पिंग करने के लिए कोई पता नहीं है। यह संयोजन बग जैसा लगता है और आमतौर पर यह बँटा हुआ कॉन्फ़िगरेशन होता है: सदस्य को स्वीकृत करना एक स्विच है, और उसे पता देना दूसरा। कोई नेटवर्क किसी डिवाइस को स्वीकार कर सकता है और उसे कभी कुछ आवंटित नहीं कर सकता, क्योंकि पता पूल या असाइनमेंट मोड कभी सेट ही नहीं हुआ।

किसी एक को बदलने से पहले दोनों पक्ष पढ़ें। उत्तर दो जगहों पर दिखता है, और उनमें से केवल एक कंट्रोलर पर है।

अधिकृति और असाइनमेंट अलग स्विच हैं

अधिकृति उत्तर देती है कि यह नोड नेटवर्क में भाग ले सकता है या नहीं। पता असाइनमेंट उत्तर देता है कि भाग लेने के बाद नेटवर्क उसे क्या देता है, और यह उत्तर पता पूल के साथ असाइनमेंट मोड से आता है। कोई भी सेटिंग दूसरी को अनिवार्य नहीं करती। एक अनुमति है और दूसरा आवंटन।

कंट्रोलर कॉन्फ़िगरेशन में आमतौर पर एक प्रबंधित रूट, पता श्रेणी और वह मोड होता है जो तय करता है कि स्वतः असाइनमेंट उपयोग होगा या नहीं। किसी दूसरे वातावरण से नेटवर्क ID कॉपी करने पर सदस्यता आती है और उस कॉन्फ़िगरेशन में से कुछ नहीं आता।

इसीलिए कोई डिवाइस सदस्य सूची में स्वस्थ दिख सकता है जबकि उसका असाइन किया गया पता कॉलम खाली रहता है। कंट्रोलर ने उसे स्वीकार किया है और उसके पास देने को कुछ नहीं है। दोनों कथन एक ही समय सत्य हैं।

LayerWhat it decidesWhere it is configured
MembershipWhether the node may joinMember authorization on the network
PoolWhich addresses exist to hand outNetwork address range
Assignment modeWhether they are handed out automaticallyNetwork v4/v6 assignment settings

सदस्य की प्रभावी स्थिति पढ़ना

क्लाइंट से पूछें कि उसे वास्तव में क्या मिला, न कि कंट्रोलर का क्या इरादा था। सादी सूची स्थिति और पता कॉलम दिखाती है, और JSON रूप वह नेटवर्क कॉन्फ़िगरेशन दिखाता है जो क्लाइंट ने लागू किया, जिसमें प्रबंधित पते और रूट शामिल हैं।

zerotier-cli listnetworks
zerotier-cli -j listnetworks | jq '.networks[] | {nwid, status, assignedAddresses}'

दोनों आउटपुट की तुलना एक ही नेटवर्क ID के लिए करें, ऑपरेटिंग सिस्टम की अपनी सूची में दिखने वाले भौतिक एडाप्टरों के लिए नहीं। खाली पता समुच्चय के साथ OK बताने वाली पंक्ति असाइनमेंट के अंतराल की पुष्टि करती है, कनेक्टिविटी खराबी की नहीं। गलत पंक्ति पढ़ना इस भूल का दूसरा आधा हिस्सा है।

ACCESS_DENIED स्थिति अधिकृति की ओर इशारा करती है, और वह अलग मरम्मत है। यदि कमांड स्थानीय प्रमाणीकरण टोकन बिल्कुल नहीं पढ़ सकता, तो समस्या स्थानीय अनुमतियाँ हैं, कंट्रोलर का अस्वीकार नहीं, और सुधार उसी मशीन पर है जिस पर आप बैठे हैं।

जब क्लाइंट कंट्रोलर के भेजे को अनदेखा करता है

क्लाइंट की अपनी सेटिंग होती हैं जो तय करती हैं कि प्रबंधित कॉन्फ़िगरेशन लागू होगा या नहीं। जो प्रोफ़ाइल प्रबंधित पते, प्रबंधित रूट या डिफ़ॉल्ट रूट का प्रबंधन बंद करती है, वह नेटवर्क के भेजे को फेंक देगी, और सदस्य सूची कंट्रोलर की ओर से अब भी सही दिखेगी।

ये फ़्लैग केवल स्थानीय नोड को प्रभावित करते हैं। इन्हें बदलने से अन्य सदस्यों को क्या मिलता है वह नहीं बदलता, और यह कभी परिभाषित न किए गए पूल को ठीक नहीं करता।

इसलिए निदान की दो शाखाएँ हैं: या कंट्रोलर के पास देने के लिए कोई पता नहीं है, या क्लाइंट ने दिया गया पता अस्वीकार कर दिया। ये अलग-अलग मशीनों पर अलग-अलग मरम्मत की ओर ले जाते हैं। JSON आउटपुट इन्हें अलग करता है, क्योंकि पता या तो नेटवर्क के कॉन्फ़िगरेशन में नहीं है, या है और क्लाइंट की लागू स्थिति में नहीं है।

पता गढ़ने के बजाय क्या ठीक करें

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

व्यवस्थापक से पूछें कि नेटवर्क को क्या देना चाहिए, फिर जाँचें कि पूल इच्छित श्रेणी को कवर करता है और असाइनमेंट मोड सक्षम है। बदलाव के बाद फिर से जुड़ें, बजाय इसके कि क्लाइंट स्वयं तुरंत नए कॉन्फ़िगरेशन तक पहुँच जाएगा।

पता दिखने पर वह जाँचें जो वास्तव में चाहिए था: कोई पीयर, कोई सेवा, या गेटवे के पीछे का सबनेट। सदस्य के पीछे के LAN तक पहुँचने के लिए सदस्यता से आगे रूटिंग और फ़ॉरवर्डिंग चाहिए, और सामान्य इंटरनेट पहुँच के लिए एग्ज़िट नोड चाहिए, इसलिए काम करता पता उस परीक्षण की शुरुआत है, अंत नहीं।

संबंधित लेख