VPN जुड़ा है पर नाम विफल होते हैं: DNS वास्तव में कहाँ टूटता है

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

लुकअप को वास्तव में क्या चाहिए

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

क्लाइंट अपना रिज़ॉल्वर VPN प्रोफ़ाइल से, टनल पर DHCP से या अपने कॉन्फ़िगरेशन से सीखता है, और कौन-सा स्रोत जीतेगा यह प्लेटफ़ॉर्म पर निर्भर करता है। Windows पर, ipconfig /all हर एडाप्टर के लिए DNS सर्वर दिखाता है, इसलिए आप देख सकते हैं कि भेजा गया मान वास्तव में पहुँचा या नहीं। ऐसा भेजा गया मान जो कभी ऑपरेटिंग सिस्टम तक नहीं पहुँचा, एक शांत और आम विफलता है। प्रोफ़ाइल छूने से पहले कॉन्फ़िगर किया गया मान पढ़ें।

Linux और macOS उसी सवाल का जवाब अलग कमांड से देते हैं, और जवाब उसी पढ़ाई के लायक है: resolvectl status और scutil --dns दोनों हर इंटरफ़ेस के लिए सर्वर सूचीबद्ध करते हैं। उस सूची की तुलना उस पते से करें जो प्रोफ़ाइल भेजने का दावा करता है। यहाँ की असंगति नीचे की सब कुछ समझाती है, इसलिए नाम जाँचने से पहले इसे तय करें।

एक सार्वजनिक और एक निजी नाम जाँचें

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

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

nslookup वह सर्वर भी दिखाता है जिससे पूछा गया और वह जवाब भी जो मिला, और यही वह जोड़ी है जो आपको चाहिए। इसे उसी शेल में दो बार चलाएँ और हर जवाब के आगे जवाब देने वाला पता लिखें।

nslookup example.com
nslookup host.corp.example 10.20.30.53

पुष्टि करें कि क्लाइंट वास्तव में उस सर्वर तक पहुँच सकता है

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

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

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

स्प्लिट-टनल प्रोफ़ाइल में रिज़ॉल्वर भेजे गए रूट से बाहर हो सकता है, जो सर्वर की नहीं प्रोफ़ाइल की समस्या है। रिज़ॉल्वर का पता भेजे गए प्रीफ़िक्स से तुलना करें और पुष्टि करें कि उनमें से एक उसे ढकता है। वही असंगति समझाती है कि DNS एक नेटवर्क पर क्यों काम करता है और समान प्रोफ़ाइल वाले दूसरे पर क्यों विफल होता है।

याद रखें कि ब्राउज़र सिस्टम रिज़ॉल्वर को बायपास कर सकते हैं

सुरक्षित DNS चालू वाला ब्राउज़र HTTPS पर क्वेरी अपनी पसंद के प्रदाता को भेज सकता है और ऑपरेटिंग सिस्टम के रिज़ॉल्वर को पूरी तरह अनदेखा कर सकता है। तब सिस्टम सही दिखता है जबकि ब्राउज़र विफल होता है, या उल्टा। यह टनल के लिए नहीं, ब्राउज़र के लिए नीति का सवाल है।

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

कैश साफ़ करें और असली काम फिर जाँचें

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

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

फिर कृत्रिम लुकअप के बजाय मूल काम दोहराएँ, क्योंकि काम ही वह चीज़ है जो उपयोगकर्ता के लिए मायने रखती है। एक बार फिर कनेक्ट भी करें, ताकि पुनःजाँच उस स्थिति को ढके जिसमें उपयोगकर्ता वास्तव में होगा। Microsoft का nslookup संदर्भ क्वेरी आर्ग्युमेंट के लिए रखने लायक पेज है।

अगर नाम केवल डिस्कनेक्ट करने के बाद विफल हों, तो क्लाइंट ने पिछला कॉन्फ़िगरेशन बहाल नहीं किया, जो DNS सर्वर बदलने के बजाय रिपोर्ट करने लायक जीवनचक्र की गलती है। काम करने वाला लुकअप भी लीक परीक्षण नहीं है, क्योंकि निकास देश आपको नहीं बताता कि किस रिज़ॉल्वर ने जवाब दिया।