Nebula मधील लाइटहाउसची भूमिका लोक स्वयंचलित मानतात असे बरेच काम करते, आणि DNS ला उत्तर देणे त्यातील एक नाही। नावांची सेवा हा बंद स्थितीत सुरू होणारा ऐच्छिक श्रोता आहे, त्यामुळे ओव्हरलेच्या आत नावे चांगली सोडवणाऱ्या होस्टकडे सहकाऱ्याचा लॅपटॉप सोडवण्यासाठी काहीही नसू शकते। तो सुरू करण्यापूर्वी कोणी त्याच्यापर्यंत पोहोचले पाहिजे आणि कोणत्या प्रकारच्या रेकॉर्डना उत्तर देण्यास तुम्ही तयार आहात हे ठरवा, कारण ही दोन उत्तरे वेगळी आहेत।

श्रोता ऐच्छिक आहे आणि डीफॉल्टनुसार बंद आहे

शोध आणि DNS वेगवेगळ्या सेवा आहेत। लाइटहाउस साथीदारांना एकमेकांना शोधण्यास मदत करतो आणि याव्यतिरिक्त आपल्याला माहीत असलेल्या होस्टबद्दलच्या नाव-क्वेरींना उत्तर देऊ शकतो, परंतु तो दुसरा भाग कॉन्फिगरेशनमध्ये स्पष्टपणे सुरू करावा लागतो।

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

A रेकॉर्ड आणि TXT समान प्रेक्षक वाटून घेत नाहीत

या दोन प्रकारच्या रेकॉर्डना वेगवेगळ्या परिस्थितीत उत्तर दिले जाते, आणि त्यांना एकच सेवा मानणे ही तीच चूक आहे जी रोखण्यासाठी हा लेख आहे।

QueryWhat it returnsWho can reach it
A record for a host nameThat host Nebula IPAny host that can reach the listener, overlay or not
TXT for a host IPCertificate informationOnly over the Nebula network

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

ते केवळ लाइटहाउसच्या स्वतःच्या होस्टबद्दल उत्तर देते

हे तुमच्या कार्यालयासाठी, क्लाउड VPC साठी किंवा सार्वजनिक इंटरनेटसाठी सामान्य रिझोल्व्हर नाही। लाइटहाउस त्याला दिलेल्या होस्ट माहितीवरून उत्तर देते, म्हणूनच हे वैशिष्ट्य प्रत्येक साथीदारावर नाही तर लाइटहाउस नोड्सवर राहते।

जेव्हा ओव्हरलेशी काहीही संबंध नसलेले नाव अयशस्वी होते, तेव्हा ते खरोखर धारण करणारे झोन आणि रिझोल्व्हर शोधा। होस्टच्या सामान्य DNS कॉन्फिगरेशनमध्ये ओव्हरले रिझोल्व्हर मिसळल्यास यादृच्छिक वाटणारे अपयश निर्माण होतात, कारण काही नावे सोडवली जातात आणि उर्वरितांना काहीही उत्तर देत नाही।

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

बाइंड पत्ता तपासा, नंतर बाहेरून चाचणी करा

lighthouse.dns.host आणि lighthouse.dns.port ऐच्छिक सेवा कुठे ऐकते हे ठरवतात। ही मूल्ये होस्ट फायरवॉल आणि नेटवर्क धोरणासह तपासा, कारण बाइंड पत्ता हेतूची घोषणा आहे आणि स्वतःच सुरक्षा नियंत्रण नाही।

dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +short

तुम्ही परवानगी देऊ इच्छित असलेल्या नेटवर्कमधून क्वेरी करा, लाइटहाउसपासूनच नाही। लाइटहाउसवर यशस्वी शोध प्रक्रिया चालू असल्याचे सिद्ध करतो आणि बाहेरील होस्ट काय विचारू शकतो याबद्दल काहीही सांगत नाही, आणि खरोखर महत्त्वाचा प्रश्न तोच आहे।

ते जाणीवपूर्वक उघड करा

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

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

संबंधित लेख