Nebula static_host_map: लाइटहाउसले दिन नसक्ने ठेगाना

हरेक लाइटहाउसले कुनै होस्टलाई अरू हरेक पियरबारे बताउन सक्छ, तर लाइटहाउस आफैँ कहाँ छ भन्नेबाहेक। ओभरले अस्तित्वमा आउनुअघि केही कुरा थाहा हुनुपर्छ, र Nebula त्यो केही कुरा एउटा सानो नक्सामा राख्छ। नक्साले ओभरले पहिचानलाई साधारण नेटवर्कमा काम गर्ने ठेगानासँग जोड्छ। पछि सिकिएका सबै कुरा त्यो जोडी सही हुनमा निर्भर छन्।

दुई काम भएका दुई ठेगाना

हरेक Nebula होस्टसँग ओभरले ठेगाना हुन्छ जो यन्त्र नेटवर्कबीच सर्दा पनि स्थिर रहन्छ। त्यो ठेगाना नै प्रमाणपत्र, फायरवाल नियम र पियर सम्बन्धले प्रयोग गर्ने पहिचान हो, र एक्लैले त्यो कतै रुट गर्दैन। पुग्न सकिने एन्डपोइन्ट अर्कै कुरा हो: अन्तर्निहित नेटवर्कको होस्टनाम वा ठेगाना र एउटा UDP पोर्ट, र मेसिनले स्थान बदल्दा त्यो बदलिन्छ। स्थिर नक्सा दुईको बीचको जोड हो।

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

पहिचान पहिचान अपेक्षा गरिएको ठाउँमा जान्छ। पुग्ने क्षमता नक्सामा जान्छ।

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

नक्सा प्रविष्टिको बनोट

कुञ्जी उद्धरण चिन्हभित्र लेखिएको ओभरले ठेगाना हो, र मान एन्डपोइन्टको सूची हो, त्यसैले एउटा पहिचानका धेरै प्रवेश बिन्दु हुन सक्छन्। हरेक एन्डपोइन्टमा एउटा होस्ट र एउटा पोर्ट हुन्छ, र पोर्ट अर्को पक्षले वास्तवमा सुनेको कुरासँग मिल्नुपर्छ। Nebula को पूर्वनिर्धारित UDP 4242 हो, जो सुरुवात बिन्दु हो, तपाईंको तैनाथीबारे वाचा होइन।

एउटा लाइटहाउसमा भित्र पस्ने एकभन्दा बढी बाटो हुँदा धेरै एन्डपोइन्ट उपयोगी हुन्छन्, जस्तै सार्वजनिक ठेगाना र त्यही खण्डका होस्टका लागि निजी ठेगाना। क्लाइन्टले तिनीहरूलाई क्रममा प्रयास गर्छ, त्यसैले सबैभन्दा भरपर्दो पहिले राख्नुहोस्। IPv6 का लागि पोर्ट थप्नुअघि ठेगाना वर्ग कोष्ठकमा राख्नुहोस्; गल्ती गरेमा गलत लाइन देखाउने पार्स त्रुटि आउँछ।

गलत पोर्टले त्रुटिको सट्टा मौनता दिन्छ, किनकि UDP सँग अस्वीकार गर्ने ह्यान्डशेक छैन। त्यसैले प्रविष्टिको ढाँचा Nebula static_host_map सन्दर्भसँग जाँच्नु उपयुक्त हुन्छ, सम्झनासँग होइन। सन्दर्भले एन्डपोइन्ट सूची र DNS रिफ्रेस व्यवहार पनि समेट्छ।

ओभरलेअघि बुटस्ट्र्याप चल्नुपर्छ

नक्साको DNS नाम कुनै पनि टनेलअघि होस्टसँग भएको रिजोल्भरमार्फत समाधान हुनुपर्छ, अर्थात् साधारण प्रणाली रिजोल्भर। त्यही मेसिनबाट, बुटको समयमा, ओभरले रोकेर परीक्षण गर्नुहोस्। ओभरलेको आफ्नै DNS बाट मात्र समाधान हुने नामले ओभरले बुटस्ट्र्याप गर्न सक्दैन। त्यही परीक्षण मार्गमा पनि लागू हुन्छ: ओभरलेलाई अनुमति दिने तर पहिलो UDP आदानप्रदानलाई नदिने फायरवाल नियमले सुरुको प्याकेट रोक्छ।

पोर्ट खुला छ भन्ने अनुमान गर्नुअघि UDP उपकरणले जाँच्नुहोस्। मार्गमा कुनै पनि पोर्ट फर्वार्डिङ सही आन्तरिक होस्टलाई लक्षित छ र फर्कने मार्ग छ भन्ने पुष्टि गर्नुहोस्। होस्टनाम धेरै ठेगानामा समाधान हुन्छ भने प्रत्येक जाँच्नुहोस्, किनकि क्लाइन्टले तपाईंले कहिल्यै नजाँचेको ठेगाना रोज्न सक्छ।

स्थिर प्रविष्टिहरू सिधै डायल गरिन्छन् र कहिल्यै लाइटहाउसलाई सोध्दैनन्। त्यसैले यहाँको विफलता कुनै पियरबिना साधारण टाइमआउटजस्तो देखिन्छ।

पहिलो ह्यान्डशेकपछि के हुन्छ

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

होस्टहरूले आफ्ना थप पुग्न सकिने ठेगाना पनि घोषणा गर्न सक्छन्, र यसरी चिनिएको सार्वजनिक ठेगानापछाडिको पियरले अरूलाई त्यो भेट्टाउन मद्दत गर्छ। ती घोषणाहरू सिकिन्छन्, स्थिर नक्सामा लेखिँदैनन्।

DNS नामका रूपमा लेखिएका एन्डपोइन्टका लागि रिफ्रेस व्यवहार महत्त्वपूर्ण छ, किनकि प्रक्रिया चलिरहँदा समाधान भएको ठेगाना बदलिन सक्छ। Nebula का सेटिङहरूले ती लुकअप कसरी हुन्छन्, कुन रिजोल्भर प्रयोग हुन्छ भन्नेसम्म नियन्त्रण गर्छन्, त्यसैले प्रणालीको पूर्वनिर्धारित मान्नुको सट्टा ती पढ्नुहोस्। टनेल उठ्दा रिजोल्भर बदलिने होस्टमा, गलत सेटिङले चलिरहेको बुटस्ट्र्यापलाई सत्रको बीचमा समाधान हुन छाड्ने नाममा बदल्न सक्छ। लुकअपलाई स्थिर रिजोल्भरमा पिन गर्नु धेरैपटक भरपर्दो ओभरले र बीचबीचमा रोकिने ओभरलेबीचको फरक हो।

खोज चल्छ तर एउटा पियर चल्दैन

लाइटहाउसहरू पुग्न सकिने छन् र अधिकांश पियर जोडिए भने बुटस्ट्र्याप समस्या होइन। बाँकी जोडीले एकअर्कासम्म उपयोगी मार्ग भेट्टाउँदैन वा पुग्ने क्षमताभन्दा माथि असफल हुन्छ। लाइटहाउसको ठेगानाको अर्को हिज्जे थप्दा दुवैमध्ये कुनै पनि अवस्था सुध्रिँदैन।

बाँकी सबै पहिल्यै अवलम्बित नक्सा सम्पादन गर्नुअघि जोडी जाँच्नुहोस्। नक्सा परिवर्तनले हरेक होस्टलाई असर गर्छ, त्यसैले त्यो सबैभन्दा पछि छुनुपर्ने कुरा हो, पहिलो होइन।

एउटै निकायका प्रमाणपत्रबाट सुरु गर्नुहोस्, किनकि अस्वीकृत ह्यान्डशेक टाढाबाट पुग्न नसकिने पियरजस्तो देखिन सक्छ। त्यसपछि जोडीले सिधा मार्ग स्थापना गर्न सक्छ कि र सिधा ट्राफिक अस्वीकार गर्ने नेटवर्कका लागि रिले कन्फिगर छ कि जाँच्नुहोस्। रिलेले एउटा हप र एउटा निर्भरता थप्छ, तर त्यो समर्थित उत्तर हो, र पियरको मार्ग सुधार्नु खोज सुधार्नुभन्दा फरक काम हो।