ZeroTier मध्ये ONLINE पण ACCESS_DENIED: कुठे दुरुस्त करायचे?

ZeroTier सेवा पातळीवर ONLINE आणि नेटवर्क पातळीवर ACCESS_DENIED असे नोंदवते, आणि ही जोडी विरोधाभास नाही। पहिले तुमचा क्लायंट आणि समन्वय पायाभूत सुविधा यांच्यातील मार्गाबद्दलचे विधान आहे। दुसरे एका नेटवर्कच्या सदस्य यादीबद्दलचे विधान आहे। ती वेगवेगळी वाचा, आणि हे संयोजन कुठे शोधायचे ते नेमके सांगेल।

ONLINE काय मोजते

स्थिती आदेश नोंदवतो की स्थानिक सेवेला पीअर शोध समन्वयित करणाऱ्या मूळ सर्व्हरपर्यंत कार्यरत मार्ग आहे का। तो कोणत्याही एका नेटवर्कबद्दल काहीच सांगत नाही, आणि कंट्रोलरने हे उपकरण मंजूर केले का याबद्दलही काहीच सांगत नाही। त्यामुळे कार्यरत कनेक्शनवरील नवीन स्थापना, कोणीही कुठेही मंजूरी देण्यापूर्वीच लगेच ONLINE नोंदवते।

ONLINE कडे पाइपलाइनबद्दलचे विधान म्हणून आणि प्रत्येक नेटवर्कची स्थिती सदस्यत्वाबद्दलचे विधान म्हणून पाहा। एकाचे दुसऱ्याने स्पष्टीकरण देणे हेच या गोंधळाचा बहुतांश भाग सुरू होण्याचे ठिकाण आहे।

ACCESS_DENIED तुमच्याकडून काय मागते

खाजगी नेटवर्कमध्ये कंट्रोलर सदस्य यादी ठेवतो। त्या यादीत नसलेला नोड, किंवा यादीत असूनही अधिकृत नसलेला नोड, मूलभूत हँडशेकशिवाय कोणत्याही संरचनेशिवाय ACCESS_DENIED घेतो। दुरुस्ती कंट्रोलरच्या बाजूला आहे आणि तिला मशीनचे नाव नव्हे तर नोडचा पत्ता लागतो, म्हणून क्लायंटच्या आउटपुटमधील पत्ता सदस्य नोंदीशी जुळवा आणि त्या नोंदीला अधिकृतता द्या।

क्लायंट पुन्हा स्थापित करणे ही चुकीची पहिली पायरी आहे, कारण नवीन स्थापना नवीन ओळख आणते आणि जुनी अधिकृतता तिला यापुढे लागू होत नाही। नेटवर्क सार्वजनिक असेल तर तीच स्थिती वेगळ्या परिस्थितीकडे निर्देश करते, म्हणून मंजुरी मागण्यापूर्वी नेटवर्क खाजगी आहे का हे कंट्रोलरच्या मालकाला विचारा। तो एकच प्रश्न उर्वरित संवाद ठरवतो।

स्थिती मजकूर शाखा आहे, निवाडा नाही

प्रत्येक स्थिती पुढील तपासणी अरुंद करते, आणि त्यांना एकच अपयश संदेश म्हणून वाचणे हेच दोन मिनिटांची दुरुस्ती पुनर्स्थापनेने भरलेल्या संध्याकाळच्या पार करते। NOT_FOUND म्हणजे तुम्ही टाइप केलेला ओळखकर्ता त्या कंट्रोलरकडे नाही, त्यामुळे सदस्यत्वाच्या प्रश्नापर्यंत अजून पोहोचले नाही। REQUESTING_CONFIGURATION म्हणजे नोड कंट्रोलरपर्यंत पोहोचला आणि येत नसलेल्या संरचनेची वाट पाहत आहे, जे अधिकृततेकडे नव्हे तर मार्गाकडे निर्देश करते। OK म्हणजे सदस्यत्व आणि संरचना तयार आहेत, त्यामुळे पुढील प्रश्न नेमून दिलेला पत्ता आहे आणि मग सेवा स्वतः।

हे सर्व दोन आदेश वेगळे करतात, आणि दोन्ही एकच क्लायंट वाचतात। ZeroTier CLI संदर्भ ते परत करतात त्या प्रत्येक नेटवर्कच्या स्थिती अक्षरमाला सूचीबद्ध करतो। पहिला आदेश सेवा दृश्य आहे, दुसरा प्रत्येक नेटवर्कसाठी:

zerotier-cli status
zerotier-cli listnetworks

प्रशासकाकडे मदत मागताना स्थिती मजकूर जपून ठेवा। पुष्टी छापणाऱ्या स्थानिक join आदेशाने केवळ विनंती स्थानिक पातळीवर स्वीकारली गेली हेच सिद्ध होते, जे नेटवर्कमध्ये प्रवेश मिळण्यापेक्षा वेगळी गोष्ट आहे।

सदस्यत्व एका ओळखीचे असते

कंट्रोलर क्लायंटच्या ओळख फाइलींनाच ओळखतो, त्यामुळे संरचना दुसऱ्या मशीनवर कॉपी करणे किंवा पुनर्स्थापनेदरम्यान ओळख पुसणे हे कंट्रोलरने कधीही न पाहिलेला सदस्य निर्माण करते। म्हणूनच सदस्य नोंद हटवणे तिची अधिकृतता रद्द करण्यापेक्षा वेगळे आहे। अजूनही चालू असलेला अधिकृत नोड प्रयत्न सोडत नाही, आणि रद्द करण्याऐवजी हटवलेली नोंद त्याच पत्त्यावरून नवीन विनंती म्हणून परत येऊ शकते।

उपकरण निवृत्त करताना आधी त्याची अधिकृतता रद्द करा आणि काहीही काढण्यापूर्वी नोंद ती स्थिती दर्शवते याची खात्री करा। क्रम हाच स्वच्छ काढणे आणि गूढ पुनर्जोडणी यातील फरक आहे।

बदलानंतर पडताळा

बदल केलेला आदेश नव्हे तर नेटवर्क नोंद पुन्हा वाचा। निकाल चार प्रश्नांनी व्यापला आहे, आणि त्यापैकी कोणताही चुकीचा असू शकतो तर इतर बरोबर दिसतात:

zerotier-cli listnetworks
ip -br addr show
ping -c 2 10.147.20.5
ip route get 10.147.20.5

पहिला प्रत्येक नेटवर्कचे सदस्यत्व आणि नेमून दिलेला पत्ता छापतो, आणि दुसरा इंटरफेसला तो पत्ता प्रत्यक्षात मिळाला का हे दाखवतो। शेवटचे दोन नेटवर्कवरील पीअर प्रतिसाद देतो आणि कोणता इंटरफेस रहदारी वाहतो हे सिद्ध करतात। कोणत्या आदेशाने कोणत्या प्रश्नाचे उत्तर दिले ते नोंदवा, म्हणजे पुढचा माणूस स्मरणातून नव्हे तर पुराव्यातून सुरुवात करेल।

जर सदस्यत्व OK असेल आणि पत्ता असेल पण पीअर प्रतिसाद देत नसतील, तर समस्या राउटिंगकडे किंवा पीअरच्याच धोरणाकडे सरकली आहे। त्या संवादातून स्थिती मजकूर काढून टाका, कारण त्याने आपले काम आधीच केले आहे। सदस्यत्व नोंद आणि मार्ग या वेगळ्या विषय असून ते जितक्या लवकर वेगळे होतील तितकी तपासणी लहान होईल।