आपकी /etc/hosts प्रविष्टि VPN के DNS तक क्यों नहीं पहुँचती

आपने /etc/hosts में एक नाम जोड़ा, VPN से जुड़े और उम्मीद की कि रिकॉर्ड सबको दिखेगा। ऐसा नहीं होता, और आश्चर्य आम तौर पर दूसरे लक्षण के साथ आता है: नाम आपकी मशीन पर रिज़ॉल्व होता है और किसी सहकर्मी की मशीन पर विफल होता है, जो टूटी हुई VPN DNS सेवा जैसा दिखता है और वास्तव में hosts फ़ाइल ठीक वही कर रही है जिसके लिए उसे बनाया गया था। hosts फ़ाइल स्थानीय नाम-रिज़ॉल्यूशन कॉन्फ़िगरेशन है, ज़ोन अपडेट नहीं, और सामान्य VPN कनेक्शन में कुछ भी उसे अपलोड नहीं करता।

Hosts एक स्थानीय ओवरराइड है, ज़ोन अपडेट नहीं

फ़ाइल मैपिंग की सूची है जिन्हें नाम-सेवा लाइब्रेरी DNS सर्वर से पूछने से पहले या उसके बजाय देखती हैं। 10.40.0.20 build.corp.example जैसी पंक्ति केवल उसी एक मशीन पर एप्लिकेशन जो निष्कर्ष निकालते हैं उसे बदलती है। यह रिकॉर्ड नहीं बनाती, सुरंग से नहीं गुज़रती, और जिस DNS सर्वर की ओर सुरंग इशारा करती है उसे इसके अस्तित्व का कोई अंदाज़ा नहीं है।

इसीलिए विफलता असममित है। आपका क्लाइंट फ़ाइल से उत्तर पाता है। दूसरा क्लाइंट VPN DNS सर्वर से पूछता है, जो कुछ नहीं लौटाता, और एप्लिकेशन बताता है कि नाम मौजूद नहीं है। दोनों मशीनें सही व्यवहार कर रही हैं; केवल एक के पास ऐसा ओवरराइड है जो दूसरे ने कभी नहीं देखा।

दो कमांड, दो अलग घटक

इस बहस को रोकने का सबसे तेज़ तरीका यह है कि अंतर को दो कमांड में दिखाया जाए, दोनों उसी क्लाइंट पर चलाए जाएँ जिसमें hosts प्रविष्टि है:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

पहला सिस्टम के अपने लुकअप पथ से पूछता है, जो एक सामान्य glibc सिस्टम में DNS से पहले स्थानीय फ़ाइलें पढ़ता है। दूसरा सीधे उस पते के सर्वर को DNS क्वेरी भेजता है और स्थानीय फ़ाइलों को बिल्कुल नहीं देखता। जब पहला आपकी प्रविष्टि लौटाता है और दूसरा NXDOMAIN लौटाता है, तो आपने साबित कर दिया है कि रिकॉर्ड DNS में मौजूद नहीं है और आपकी मशीन स्थानीय ओवरराइड से उत्तर दे रही है।

क्रम विन्यास योग्य है, और किसी विशेष वितरण के बारे में कोई निष्कर्ष निकालने से पहले इसे जाँचना उचित है। /etc/nsswitch.conf में hosts: पंक्ति देखें; hosts: files dns पहले फ़ाइलें देखता है। केवल क्रम बदलने के लिए उस उदाहरण को काम कर रहे कॉन्फ़िगरेशन पर नकल न करें, क्योंकि वास्तविक सिस्टम अक्सर अतिरिक्त स्रोत और सशर्त सेवा प्रविष्टियाँ सूचीबद्ध करते हैं जो उदाहरण में नहीं हैं।

systemd-resolved परीक्षण को धुँधला करता है

systemd-resolved वाले सिस्टम में स्थानीय स्टब hosts डेटाबेस से भी नाम परोसता है। इसलिए 127.0.0.53 से क्वेरी करना दूरस्थ सर्वर का स्वतंत्र परीक्षण नहीं है, हालाँकि यह DNS क्वेरी जैसा दिखता है और वैसा ही व्यवहार करता है। रिज़ॉल्वर क्या जानता है और किन सर्वरों से पूछेगा, यह आप इससे पुष्टि कर सकते हैं:

resolvectl query build.corp.example
resolvectl status

status आउटपुट प्रत्येक लिंक के लिए DNS सर्वर बताता है, और इसी तरह आप जानते हैं कि VPN लिंक को रिज़ॉल्वर मिला भी या नहीं। वह प्रश्न hosts प्रविष्टि से अलग है और जब निजी नाम किसी एक के बजाय हर उपयोगकर्ता के लिए विफल हो तब पूछने योग्य प्रश्न वही है।

एप्लिकेशन एक और परत जोड़ सकते हैं। अपनी DNS-over-HTTPS सेटिंग वाला ब्राउज़र, अपना रिज़ॉल्वर कॉन्फ़िगरेशन वाला कंटेनर, या प्रोसेस के पूरे जीवनकाल तक लुकअप कैश करने वाला रनटाइम—हर एक सिस्टम से अलग उत्तर दे सकता है। यह मानने के बजाय कि एक कमांड मशीन के हर प्रोग्राम का वर्णन करता है, उस एप्लिकेशन का परीक्षण करें जो आपके लिए मायने रखता है।

VPN पर वास्तव में क्या एक नाम साझा करता है

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

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

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

हल किया गया नाम मार्ग नहीं है

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

इसलिए जब रिपोर्ट हो कि “नाम रिज़ॉल्व होता है लेकिन सेवा पहुँच में नहीं है”, तो सिस्टम लुकअप की तुलना VPN DNS सर्वर से स्पष्ट क्वेरी से करें, फिर जो पता आपको मिला उसे उस पते से मिलाएँ जो सेवा वास्तव में उपयोग करती है। systemd-resolved संदर्भ उन स्थानीय स्रोतों का दस्तावेज़ीकरण करता है जिन्हें वह देखता है, और उस तुलना के लिए यही नक्शा चाहिए।

फिर ओवरराइड को उसके मालिक के माध्यम से ठीक करें। अपनी hosts फ़ाइल से एक पंक्ति हटाने से उन बारह लैपटॉपों के लिए कुछ नहीं होता जिन्हें परिनियोजन स्क्रिप्ट से वही पंक्ति मिली थी, और लोगों के पास वास्तव में इस समस्या का यही संस्करण है।