Nebula advertise_addrs या static_host_map: मालिक के अनुसार चुनें
स्थिर मानचित्र को वह हर पीयर बनाए रखता है जो उसे डायल करता है; विज्ञापित पता होस्ट प्रकाशित करता है। चुनें कि कौन एंडपॉइंट जानता है।
static_host_map और advertise_addrs दोनों सेटिंग एक पीयर के सामने पता रखती हैं, और वे अलग-अलग सवालों का जवाब देती हैं। एक स्थानीय फ़ाइल है जो ओवरले पता और डायल करने वाला अंडरले एंडपॉइंट सूचीबद्ध करती है। दूसरी एक होस्ट है जो अपने लाइटहाउस को बताती है कि कौन से अतिरिक्त एंडपॉइंट उस तक पहुँच सकते हैं। असली अंतर मालिकी है: मानचित्र को वे सब बनाए रखते हैं जिन्हें इसकी ज़रूरत है, और विज्ञापन को होस्ट स्वयं।
तय करें कि जानकारी किसके पास है
| Setting | Where it lives | Best for |
|---|---|---|
static_host_map | Every peer that needs the entry | Bootstrap endpoints, deliberately fixed paths |
advertise_addrs | The host's own config | Endpoints the host cannot otherwise discover |
हर पीयर की स्थिर फ़ाइल में हर बदलता पीयर रखरखाव का काम है जो बेड़े के वर्ग के साथ बढ़ता है। यही व्यावहारिक कारण है कि जब होस्ट स्वयं उत्तर जानता है तो दूसरी सेटिंग पर जाएँ।
मालिकी का सवाल यह भी बताता है कि पता बदलने पर क्या होता है। स्थिर मानचित्र के साथ, किसी को हर उस पीयर को याद रखना होता है जिसके पास पुरानी प्रविष्टि है। विज्ञापन के साथ, होस्ट नया एंडपॉइंट प्रकाशित करता है और उसके लाइटहाउस उसे आगे भेजते हैं, इसलिए बदलाव उसी मशीन पर स्थानीय रहता है जो हिली है।
Bootstrap को अभी भी स्थिर प्रविष्टियाँ चाहिए
क्लाइंट को दूसरे पीयर के बारे में किसी से पूछने से पहले कम से कम एक लाइटहाउस तक पहुँचना चाहिए। वह पहली छलांग खोज से नहीं आ सकती, इसलिए वह क्लाइंट के कॉन्फ़िगरेशन में एक स्थिर प्रविष्टि पर निर्भर करती है। उस एक प्रविष्टि को सही करें और बाकी ओवरले सीखा जा सकता है।
मानचित्र प्रविष्टि एक Nebula पते को एक या अधिक पहुँचने योग्य IP या DNS एंडपॉइंट और पोर्ट के साथ जोड़ती है। लाइटहाउस को वहाँ रखना सामान्य है; हर पीयर को वहाँ रखना वह पैटर्न है जो बुरी तरह पुराना होता है, क्योंकि हर नया पीयर उन मशीनों पर फ़ाइलें संपादित करने का मतलब है जिन्हें आप शायद नियंत्रित नहीं करते। सूची इतनी छोटी रखें कि कोई व्यक्ति पढ़कर उसे सत्यापित कर सके।
विज्ञापित करें जब होस्ट एंडपॉइंट जानता है
पोर्ट फ़ॉरवर्डिंग के पीछे का होस्ट एक सार्वजनिक पते पर पहुँचने योग्य होता है जो उसके किसी भी इंटरफ़ेस को आवंटित नहीं है। वह स्वयं को देखकर उस पते को खोज नहीं सकता। advertise_addrs उसे अपने लाइटहाउस के माध्यम से एंडपॉइंट प्रकाशित करने देता है ताकि अन्य पीयर ऐसा मार्ग सीखें जो वास्तव में काम करता है। सेटिंग ठीक इसलिए मौजूद है कि मैपिंग हुई है यह होस्ट ही एकमात्र पक्ष जानता है।
वह पता और पोर्ट इस्तेमाल करें जहाँ अन्य पीयर वास्तव में पहुँच सकें। यही तर्क कई नेटवर्क मार्गों वाले होस्ट पर लागू होता है, जहाँ किसी विशेष नेटवर्क के पीयर के लिए एक मार्ग बेहतर है। विज्ञापन अंडरले के बारे में एक कथन है, किसी चीज़ का अनुरोध नहीं। मैपिंग बदलने पर होस्ट पर विज्ञापन अपडेट करें और खोज को उसे ले जाने दें, पूरे बेड़े में स्थिर फ़ाइलें संपादित करने के बजाय।
विज्ञापन पहुँच नहीं है
किसी एंडपॉइंट को प्रकाशित करने से राउटर का फ़ॉरवर्डिंग नियम नहीं बनता, ऊपर की ओर फ़ायरवॉल नहीं खुलता और DNS नाम हल नहीं होता। ये अलग काम के हिस्से हैं, और अनुपस्थित पोर्ट फ़ॉरवर्डिंग वाला सही विज्ञापन ठीक वही विफलता पैदा करता है जिसे आप ठीक करना चाहते थे। विज्ञापन पहुँच के बारे में एक दावा है, उसे स्थापित करने वाला कोई तंत्र नहीं।
खोज को दोष देने से पहले बाहर से मार्ग जाँचें। जो पीयर एंडपॉइंट सीखता है पर हैंडशेक पूरा नहीं कर सकता, उसके अंडरले पर राउटिंग या फ़िल्टरिंग की समस्या है, और दोनों सेटिंग में वही पता दोहराने से वह नहीं बदलेगा।
ओवरले पते को एंडपॉइंट से अलग रखें
नोड का प्रमाणपत्र उसका Nebula पता पहचानता है। विज्ञापित पते अंतर्निहित नेटवर्क के हैं, और उन्हें प्रमाणपत्र छुए बिना बदला जा सकता है। अलग ओवरले IP के साथ नया प्रमाणपत्र जारी करना एक अलग कार्रवाई है, जिसके अपने परिणाम हर उस ट्रस्ट संबंध के लिए हैं जिसने पुराने को पिन किया था। दोनों बदलावों को रनबुक में अलग रखें, वरना एंडपॉइंट स्थानांतरण पुनः जारी के रूप में दर्ज होगा।
जब ट्रायाज अटक जाए, दोनों परतों को स्पष्ट रूप से अलग करें: क्या खोज अपेक्षित एंडपॉइंट लौटाती है, और क्या हैंडशेक उस तक पहुँचता है? यदि खोज सही है और पैकेट विफल होते हैं, समस्या ओवरले के नीचे है। यदि खोज गलत है, समस्या मानचित्र या विज्ञापन में है, और सुधार वहीं है।