टनल चालू है, तो निजी नाम अब भी क्यों विफल होता है?
काम करती टनल का मतलब यह नहीं कि क्लाइंट ने सही रिज़ॉल्वर से पूछा। जाँचें कि किसने जवाब दिया, फिर केवल वही ज़ोन आगे भेजें जिसे वास्तव में इसकी ज़रूरत है।
कनेक्शन की हर बात सही दिखती है: टनल चालू है और कंसोल निजी एंडपॉइंट दिखाता है, फिर भी हर अनुरोध नाम विभेदन में विफल होता है। स्वाभाविक कदम टनल को दोष देना है, जो आमतौर पर निर्दोष निकलता है। क्वेरी ऐसे सर्वर को भेजी जा रही है जो निजी ज़ोन के बारे में कुछ नहीं जानता। कोई भी रूटिंग बदलाव उस जवाब को नहीं बदलेगा, क्योंकि समस्या यह है कि किससे पूछा गया।
क्वेरी किस रिज़ॉल्वर तक पहुँची?
टनल की ओर देखने से पहले हर लिंक से जुड़ा रिज़ॉल्वर खोजें। Linux रिज़ॉल्वर स्थिति कमांड से प्रति-लिंक सर्वर दिखाता है, और macOS अपने DNS कॉन्फ़िगरेशन डंप में स्कोप्ड रिज़ॉल्वर दिखाता है। अगर जवाब अब भी घर के राउटर से आ रहा है, तो टनल लिंक से कभी परामर्श नहीं लिया गया।
resolvectl status
scutil --dns | head -40
dig +short internal.example.com
यहाँ दो चरण मिल जाते हैं: एक सर्वर जो रिज़ॉल्वर पता धकेलता है, और एक क्लाइंट जो उसे सक्रिय लिंक पर स्थापित करता है। प्रोफ़ाइल में विकल्प हो सकता है, और लॉग दिखा सकता है कि वह आ रहा है, जबकि ऑपरेटिंग सिस्टम पुराने सर्वर का उपयोग जारी रखता है। लॉग की तुलना लिंक जो बताता है उससे करें, और लिंक पर भरोसा करें।
ऐसा पता इस्तेमाल करें जिस पर क्लाउड नेटवर्क वास्तव में जवाब दे
क्लाउड नेटवर्क आमतौर पर निजी नामों का जवाब रेंज के आधार से दो आगे स्थित आरक्षित पते के ज़रिए देते हैं, इसलिए 10.0.0.0 से शुरू होने वाला नेटवर्क 10.0.0.2 पर जवाब देता है। कुछ प्रदाता लिंक-लोकल रिज़ॉल्वर भी प्रकाशित करते हैं जो रेंज जाने बिना काम करता है, जो तब मदद करता है जब नेटवर्क किसी और ने बनाया हो। उम्मीदवार पते से किसी को भी भेजने से पहले सीधे पूछें। जो पता रिज़ॉल्वर नहीं है वह फ़ायरवॉल ड्रॉप जैसा ही लगता है, क्योंकि क्वेरी को कभी जवाब ही नहीं मिलता।
अगर सीधी क्वेरी नेटवर्क के अंदर से जवाब देती है पर टनल के पार नहीं, तो रिज़ॉल्वर ठीक है और दो बिंदुओं के बीच का रास्ता नहीं। यह परिणाम जाँच को क्लाइंट प्रोफ़ाइल के बजाय रूट, फ़ॉरवर्डिंग और एक्सेस नियमों की ओर ले जाता है।
टनल नाम-स्थान नहीं ले जाती
पैकेट पार होते हैं; नाम नहीं। हर पक्ष को बताना होता है कि कौन-सा नाम-स्थान दूसरे का है, और वह अलग वस्तु है जिसका मालिक ज़ोन रखने वाला होता है। सामान्य रूप एक नाम-स्थान के लिए फ़ॉरवर्ड है, जो टनल से पहुँचने योग्य रिज़ॉल्वर की ओर इंगित होता है।
व्यवहार में हर दिशा को अपना नियम चाहिए, क्योंकि ज़ोन रखने वाला पक्ष ही क्वेरी आगे भेजता है। दोनों दिशाओं में क्वेरी के स्रोत को रूट और अनुमत किया जाना चाहिए, और जवाब देने वाले पक्ष को जवाब इंटरनेट की ओर नहीं बल्कि टनल से वापस भेजने चाहिए। फ़ॉरवर्ड को संकीर्ण रखें, ताकि केवल निजी नाम-स्थान ही लिंक पर निर्भर हो। हर क्वेरी उससे भेजने पर छोटी-सी निर्भरता उस पल पूर्ण रुकावट बन जाती है जब टनल गिरती है।
सीमाओं को क्रम से पार करें
सक्रिय लिंक पर स्थापित रिज़ॉल्वर की जाँच करें, फिर उस रिज़ॉल्वर से सीधी क्वेरी, फिर दूर के पक्ष से वही क्वेरी, और अंत में वही नाम इस्तेमाल करने वाला अनुप्रयोग। हर कदम एक सीमा अलग करता है, इसलिए विफलता बताती है कि कहाँ देखें, जाँच फिर से शुरू करने के बजाय। ऐसा जवाब जो काम करता है जबकि अनुप्रयोग विफल हो, DNS के बजाय प्रमाणपत्र भरोसे या API नीति की ओर इशारा करता है। वे खराबियाँ वास्तविक हैं, और कोई रिज़ॉल्वर बदलाव उन्हें ठीक नहीं करेगा।
लिखें कि कौन-सा कदम विफल हुआ। वही एक पंक्ति अगले व्यक्ति को चाहिए, और उसे दर्ज करने में दस सेकंड लगते हैं।
श्रृंखला को वहाँ रखें जहाँ अगला व्यक्ति उसे ढूँढ सके
धकेला गया रिज़ॉल्वर, फ़ॉरवर्डिंग नियम, अनुमत क्वेरी स्रोत और जवाब देने वाला एंडपॉइंट एक ही जगह दर्ज करें। जब निजी नाम फिर विफल हो, रिकॉर्ड दिखाता है कि टनल हिली, रिज़ॉल्वर का पता बदला, या कोई नियम संकीर्ण हुआ। इसके बिना हर घटना शून्य से शुरू होती है और उन्हीं तीन अनुमानों पर खत्म होती है।
रिकॉर्ड को सटीक रहने के लिए पर्याप्त छोटा रखें: चार पंक्तियाँ, एक तारीख, और हर हिस्से का मालिक कौन है उसका नाम। पुराना रिकॉर्ड न होने से बुरा है, क्योंकि वह गलत होते हुए भी आधिकारिक लगता है।