VPN DNS काम करता है, लेकिन .local नाम अब भी विफल होते हैं: उन्हें कौन हल करता है?

एक ही VPN पर दो मशीनें, एक ही होस्टनाम, और उनमें से केवल एक ही उसे हल करती है: अंतर आमतौर पर टनल नहीं, बल्कि यह है कि किस रिज़ॉल्वर ने जवाब दिया। Linux डेस्कटॉप पर वह नाम नाम सेवा स्विच से, systemd-resolved के स्टब से, या किसी ऐसे रिज़ॉल्वर से गुज़र सकता है जो एप्लिकेशन अपने साथ लाया है, और इनमें से हर एक उसी सफ़िक्स पर अपना नियम लागू करता है। सफ़िक्स ही वह जगह है जहाँ नियम अलग होते हैं, क्योंकि .local कोई निष्पक्ष लेबल नहीं है। कुछ भी किस क्रम में चलता है, यह बदलने से पहले पता करें कि विफल प्रोग्राम वास्तव में कौन-सा पथ लेता है।

दो रिज़ॉल्वर, दो अलग जवाब

पारंपरिक glibc लुकअप nsswitch.conf की hosts: पंक्ति से गुज़रता है और एक के जवाब देने तक हर मॉड्यूल से बारी-बारी पूछता है। स्टब लिसनर के ज़रिए systemd-resolved से बात करने वाला क्लाइंट इसके बजाय एक ही प्रक्रिया से पूछता है, और वह प्रक्रिया प्रति-लिंक नीति के साथ-साथ अपने विशेष मामले भी लागू करती है। जो एप्लिकेशन अपना रिज़ॉल्वर साथ लाता है, या ऐसा करने वाली लाइब्रेरी लिंक करता है, वह दोनों को बायपास कर सकता है। इसलिए एक होस्टनाम के एक मशीन पर तीन मालिक हो सकते हैं, और उनमें से केवल एक जानता है कि VPN का क्या इरादा था।

कुछ भी बदलने से पहले मालिक की पहचान करें, क्योंकि तीनों में से हर एक के लिए उपाय अलग है। एक ही डेस्कटॉप पर ब्राउज़र और कमांड-लाइन टूल वैध रूप से असहमत हो सकते हैं, और वही असहमति सुराग है, बग नहीं। अगर ब्राउज़र नाम हल करता है और टूल नहीं, तो आप रिज़ॉल्वर पथ को डीबग कर रहे हैं, VPN रूट को नहीं। रूट को अलग से सत्यापित करें, ताकि रूटिंग गड़बड़ी को नाम सेवा गड़बड़ी न समझा जाए। जब दोनों सहमत हों, तो गड़बड़ी होस्ट के ऊपर है और यहाँ का रिज़ॉल्वर कॉन्फ़िगरेशन एक और संपादन के लायक नहीं है।

किस कमांड ने वास्तव में आपके रिज़ॉल्वर से पूछा

दो केवल-पढ़ने वाले कमांड संबंधित प्रश्नों का जवाब देते हैं, और उनकी तुलना कॉन्फ़िगरेशन पढ़ने से तेज़ी से समस्या का स्थान तय करती है। असली आंतरिक नाम इस्तेमाल करें और आउटपुट को निजी रखें, क्योंकि आंतरिक रिकॉर्ड आंतरिक ही रहते हैं। दोनों को उसी सत्र में चलाएँ जिसमें विफल प्रोग्राम चलता है:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

पहला कॉन्फ़िगर किए गए मॉड्यूल से पूछता है, जो एक सामान्य प्रोग्राम अनुभव करता है। दूसरा सीधे systemd-resolved से पूछता है और जो लिंक, प्रोटोकॉल और सर्वर ने जवाब दिया उसकी रिपोर्ट करता है। कॉर्पोरेट सर्वर से पते के आधार पर पूछना केवल यह साबित करता है कि सर्वर के पास रिकॉर्ड है, क्योंकि इससे यह नहीं पता चलता कि एप्लिकेशन ने उससे कभी पूछा भी था या नहीं। जो लिंक VPN ले जाता है और जो डोमेन वह दावा करता है उन्हें पढ़ें, फिर उस सूची की तुलना विफल नाम के सफ़िक्स से करें।

क्यों .local आपके unicast ज़ोन को छोड़ देता है

systemd-resolved का संदर्भ कहता है कि .local पर समाप्त होने वाले बहु-लेबल नाम, mDNS सक्षम होने पर सामान्य unicast DNS के बजाय आमतौर पर multicast DNS पर जाते हैं। RFC 6762 उस नामस्थान को link-local multicast के लिए अलग रखता है, इसलिए कोई कॉर्पोरेट ज़ोन सही रिकॉर्ड रख सकता है जो उस सफ़िक्स के लिए कभी नहीं पूछा जाता। टनल रिज़ॉल्वर को पूरी तरह रूट कर सकता है और फिर भी दौड़ हार सकता है। कैश से सफल ping अभी हुई लुकअप के बारे में कुछ नहीं कहता।

एक प्रलेखित अपवाद है, और यह इनमें से अधिकांश मामलों को सुलझाता है: जब कोई लिंक उस सफ़िक्स को खोज डोमेन या रूटिंग डोमेन घोषित करता है, तो डेमन उसे unicast पथ पर रखता है और multicast के विशेष मामले को छोड़ देता है। यह प्रति-लिंक नीति है, वैश्विक वरीयता नहीं। एक ही VPN सर्वर वाली दो मशीनें अलग व्यवहार कर सकती हैं जब एक नेटवर्क प्रोफ़ाइल डोमेन घोषित करती है और दूसरी नहीं, इसलिए वह प्रोफ़ाइल पढ़ें जो सक्रिय है, न कि वह जिसे आप संपादित किया हुआ याद रखते हैं।

संकीर्ण अपवाद वैश्विक पुनर्क्रमण को हराता है

ऐसे मौजूदा ज़ोन के लिए जिसका नाम आप बदल नहीं सकते, रिज़ॉल्वर और VPN मालिकों से उस डोमेन को उस कनेक्शन पर घोषित करवाएँ जो उसे ले जाता है। उस एक सफ़िक्स के लिए रूटिंग-डोमेन प्रविष्टि और इच्छित सर्वर पता एक नामित मालिक वाला छोटा बदलाव है, और यह हाथ से संपादित फ़ाइल में नहीं, लिंक के साथ रहता है।

यह डिस्कनेक्ट के बाद भी टिकता है, क्योंकि लिंक लौटने पर लिंक नीति फिर लागू होती है। साझा nsswitch.conf को संपादित करना लुभावना और अधिक महंगा विकल्प है, क्योंकि यह मशीन के हर नाम के लिए लुकअप व्यवहार बदल देता है, स्थानीय खोज सहित। multicast डेमन को बंद करना भी बराबर नहीं है: यह स्थानीय व्यवहार हटाता है पर किसी रिज़ॉल्वर को कॉर्पोरेट ज़ोन के बारे में नहीं सिखाता। अगर सेवा विरासत में नहीं मिली बल्कि नई है, तो उसे अपने संगठन के नियंत्रण वाले सबडोमेन के अंतर्गत रखें और प्रतिस्पर्धा पूरी तरह छोड़ दें। जब नाम फ़र्मवेयर में तय हो या लेबल पर छपा हो तो संकीर्ण अपवाद चुनें, और जब आपके पास अब भी क्लाइंट का नियंत्रण हो तो नया सबडोमेन चुनें।

बदलाव के बाद क्या साबित करना है

सुधार को एप्लिकेशन की अपनी लुकअप से साबित करें, परीक्षण के लिए स्थापित किसी टूल से नहीं, और उसकी ओर से जवाब दे सकने वाला कोई भी कैश साफ़ करें। फिर रिज़ॉल्वर पथ और वह लिंक सत्यापित करें जिसने जवाब दिया। अंत में जाँचें कि स्थानीय खोज बदलाव से पहले जैसी ही व्यवहार करती है, क्योंकि जो प्रिंटर दिखना बंद कर देता है वही वह हिस्सा है जिसे लोग सबसे बाद में नोटिस करते हैं। ये तीन कमांड नाम, पथ और TLS पहचान को इसी क्रम में जाँचते हैं:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

गलत प्रमाणपत्र के साथ सही पता कठोर क्लाइंट को अब भी विफल करता है, इसलिए समाधान काम करने के बाद वह नाम जाँचें जिसकी एप्लिकेशन अपेक्षा करता है। पुष्टि करें कि सेवा केवल कार्यालय की श्रेणी से नहीं, VPN पते से भी कनेक्शन स्वीकार करती है। डोमेन का विस्तार, सर्वर और मालिक कनेक्शन के दस्तावेज़ीकरण में लिखें। वरना इस विफलता से मिलने वाला अगला व्यक्ति उसी वैश्विक संपादन की ओर बढ़ेगा जिसे आपने अभी टाला है।