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 |
प्रत्येक पीअरच्या स्थिर फाइलमधील प्रत्येक बदलणारा पीअर हे देखभालीचे काम आहे जे ताफ्याच्या वर्गाने वाढते। होस्टलाच उत्तर माहीत असताना दुसऱ्या सेटिंगकडे वळण्याचे व्यावहारिक कारण हेच आहे।
मालकीचा प्रश्न पत्ता बदलल्यावर काय होते हेही सांगतो। स्थिर नकाशासह, जुन्या नोंदीचा धारक प्रत्येक पीअर कोणालातरी लक्षात ठेवावा लागतो। जाहिरातीसह, होस्ट नवीन एंडपॉइंट प्रकाशित करतो आणि त्याचे लाइटहाऊस तो पुढे देतात, त्यामुळे बदल हललेल्या मशीनवरच स्थानिक राहतो।
बूटस्ट्रॅपला अजूनही स्थिर नोंदी हव्यात
क्लायंटला इतर पीअरबद्दल कोणालाही विचारण्यापूर्वी किमान एका लाइटहाऊसपर्यंत पोहोचावे लागते। ती पहिली उडी शोधातून येऊ शकत नाही, म्हणून ती क्लायंटच्या कॉन्फिगरेशनमधील स्थिर नोंद वर अवलंबून असते। ती एक नोंद बरोबर करा आणि उर्वरित ओव्हरले शिकता येईल।
नकाशा नोंद Nebula पत्त्याला एक किंवा अधिक पोहोचण्यायोग्य IP किंवा DNS एंडपॉइंट आणि पोर्टसोबत जोडते। लाइटहाऊस तिथे ठेवणे सामान्य आहे; प्रत्येक पीअर तिथे ठेवणे हा असा नमुना आहे जो वाईटपणे वृद्ध होतो, कारण प्रत्येक नवीन पीअर म्हणजे तुम्ही नियंत्रित करत नसलेल्या मशीनवरील फाइल्स संपादित करणे। यादी एवढी लहान ठेवा की एखादी व्यक्ती वाचून ती पडताळू शकेल।
होस्टला एंडपॉइंट माहीत असल्यास जाहीर करा
पोर्ट फॉरवर्डिंगमागील होस्ट त्याच्या कोणत्याही इंटरफेसला न दिलेल्या सार्वजनिक पत्त्यावर पोहोचण्यायोग्य असतो। स्वतःकडे पाहून त्याला तो पत्ता शोधता येत नाही। advertise_addrs त्याला त्याच्या लाइटहाऊसमार्फत एंडपॉइंट प्रकाशित करू देतो जेणेकरून इतर पीअर प्रत्यक्षात काम करणारा मार्ग शिकतील। हे सेटिंग अस्तित्वात आहे कारण मॅपिंग झाले हे जाणणारा होस्ट हाच एकमेव पक्ष आहे।
इतर पीअर प्रत्यक्षात पोहोचू शकतील असा पत्ता आणि पोर्ट वापरा। तोच युक्तिवाद अनेक नेटवर्क मार्ग असलेल्या होस्टलाही लागू होतो, जिथे विशिष्ट नेटवर्कवरील पीअरसाठी एक मार्ग अधिक चांगला असतो। जाहिरात अंडरलेबद्दलचे विधान आहे, कशाचीही विनंती नाही। मॅपिंग बदलल्यावर होस्टवर जाहिरात अद्ययावत करा आणि शोधाला ती वाहू द्या, संपूर्ण ताफ्यात स्थिर फाइल्स संपादित करण्याऐवजी।
जाहिरात म्हणजे पोहोच नाही
एंडपॉइंट प्रकाशित केल्याने राउटरचा फॉरवर्डिंग नियम तयार होत नाही, वरचा फायरवॉल उघडत नाही किंवा DNS नाव सुटत नाही। हे कामाचे वेगळे भाग आहेत, आणि गहाळ पोर्ट फॉरवर्डिंगसह योग्य जाहिरात तुम्ही दुरुस्त करू पाहत असलेला तोच बिघाड निर्माण करते। जाहिरात हे पोहोचीबद्दलचे विधान आहे, ती प्रस्थापित करणारी यंत्रणा नाही।
शोधाला दोष देण्यापूर्वी बाहेरून मार्ग तपासा। एंडपॉइंट शिकणाऱ्या पण हॅंडशेक पूर्ण करू न शकणाऱ्या पीअरला अंडरलेवर राउटिंग किंवा फिल्टरिंगची समस्या आहे, आणि दोन्ही सेटिंगमध्ये तोच पत्ता पुनरावृत्त केल्याने ते बदलणार नाही।
ओव्हरले पत्ता एंडपॉइंटपासून वेगळा ठेवा
नोडचे प्रमाणपत्र त्याचा Nebula पत्ता ओळखते। जाहीर केलेले पत्ते अंतर्निहित नेटवर्कचे आहेत, आणि प्रमाणपत्राला स्पर्श न करता बदलू शकतात। वेगळ्या ओव्हरले IP सह नवीन प्रमाणपत्र जारी करणे हे वेगळे ऑपरेशन आहे, जुन्याला पिन केलेल्या प्रत्येक विश्वास संबंधासाठी स्वतःचे परिणाम घेऊन। रनबुकमध्ये दोन्ही बदल वेगळे ठेवा, अन्यथा एंडपॉइंट स्थलांतर पुनर्जारी म्हणून नोंदवले जाईल।
ट्रायाज अडकल्यावर दोन्ही स्तर स्पष्टपणे वेगळे करा: शोध अपेक्षित एंडपॉइंट परत देतो का, आणि हॅंडशेक तिथपर्यंत पोहोचतो का? शोध बरोबर असून पॅकेट अयशस्वी झाल्यास समस्या ओव्हरलेखाली आहे। शोध चुकीचा असल्यास समस्या नकाशात किंवा जाहिरातीत आहे, आणि दुरुस्ती तिथेच आहे।