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 ची सेटिंग्ज ते लुकअप कसे होतात, कोणता रिझोल्व्हर वापरला जातो यासह नियंत्रित करतात, त्यामुळे सिस्टम डीफॉल्ट गृहीत धरण्याऐवजी त्या वाचा। टनेल उभे राहिल्यावर रिझोल्व्हर बदलणाऱ्या होस्टवर, चुकीची सेटिंग चालणारे बूटस्ट्रॅप सत्राच्या मध्यात सोडवणे थांबवणाऱ्या नावात बदलू शकते। लुकअप स्थिर रिझोल्व्हरला पिन करणे हे बऱ्याचदा विश्वासार्ह ओव्हरले आणि अधूनमधून थांबणाऱ्या ओव्हरलेमधील फरक असतो।

शोध चालतो पण एक पीअर चालत नाही तेव्हा

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

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

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