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 की सेटिंग्स नियंत्रित करती हैं कि वे लुकअप कैसे होते हैं, किस रिज़ॉल्वर का उपयोग होता है सहित, इसलिए सिस्टम डिफ़ॉल्ट मानने के बजाय उन्हें पढ़ें। जिस होस्ट का रिज़ॉल्वर टनल उठने पर बदल जाता है, वहाँ गलत सेटिंग काम कर रहे बूटस्ट्रैप को ऐसे नाम में बदल सकती है जो सत्र के बीच में हल होना बंद कर दे। लुकअप को स्थिर रिज़ॉल्वर से बाँधना अक्सर भरोसेमंद ओवरले और रुक-रुक कर चलने वाले ओवरले के बीच का अंतर होता है।

जब खोज काम करती है और एक पीयर नहीं

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

जिस नक्शे पर बाकी सब पहले से टिका है उसे संपादित करने से पहले जोड़ी को जाँचें। नक्शा बदलना हर होस्ट को परेशान करता है, इसलिए यह सबसे आखिर में छूने वाली चीज़ है, पहली नहीं।

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