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 पर्यंत पोहोचण्यासाठी सदस्यत्वाच्या पलीकडे मार्गनिर्देशन आणि फॉरवर्डिंग आवश्यक आहे, आणि सामान्य इंटरनेट प्रवेशासाठी एक्झिट नोड आवश्यक आहे, म्हणून कार्यरत पत्ता त्या चाचणीची सुरुवात आहे, शेवट नाही.

संबंधित लेख