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 मा पुग्न सदस्यताभन्दा बाहिर राउटिङ र फर्वार्डिङ चाहिन्छ, र सामान्य इन्टरनेट पहुँचका लागि एक्जिट नोड चाहिन्छ, त्यसैले काम गर्ने ठेगाना त्यो परीक्षणको सुरुवात हो, अन्त्य होइन।

सम्बन्धित लेखहरू