क्या VPN ने मेरा DNS बदला? पहले और बाद की तुलना करें
एक प्रोफ़ाइल आपकी क्वेरीज़ को जानबूझकर स्थानांतरित कर सकती है। VPN जुड़ने से पहले और बाद में रिज़ॉल्वर नीति और वास्तविक उत्तर की तुलना करें, एक चर स्थिर रखते हुए।
आप टनल जोड़ते हैं, एक निजी डैशबोर्ड खोलते हैं, और नाम उस पते पर हल हो जाता है जिसे आपने पहले कभी नहीं देखा। या उल्टा होता है: ब्राउज़र काम करता रहता है जबकि कमांड-लाइन टूल अचानक कुछ भी हल नहीं करता। दोनों नतीजे एक ही बदलाव से आते हैं, और लोग आमतौर पर इसे VPN के "अपना DNS इस्तेमाल करने" वाले एक वाक्य से समझाते हैं, जो डिबग या सत्यापन के लिए पर्याप्त सटीक नहीं है। उस वाक्य में दो प्रश्न छिपे हैं: यह प्रोफ़ाइल किन क्वेरीज़ को लेना चाहती है, और क्या आपकी मशीन ने उन्हें वास्तव में उसी रिज़ॉल्वर को भेजा जो उसे दिया गया था? इन्हें अलग रखना ही पूरी विधि है, क्योंकि जो परीक्षण इन्हें मिला देता है वह दोनों दिशाओं में आत्मविश्वासी गलत उत्तर देता है।
प्रोफ़ाइल आख़िर रिज़ॉल्वर क्यों देती है
टनल के अंदर, दूर के छोर के पीछे के नाम आमतौर पर ऐसे पतों पर हल होते हैं जो केवल उसी नेटवर्क में मौजूद हैं। corp.internal जैसे निजी ज़ोन का कोई सार्वजनिक प्रत्यायोजन नहीं होता, इसलिए उसका उत्तर देने वाला रिज़ॉल्वर टनल के भीतर से पहुँचने योग्य होना चाहिए। वही तंत्र दूसरा उद्देश्य भी पूरा करता है: जब क्वेरीज़ अन्यथा आपके ISP से बाहर जातीं, तब दूर के छोर का रिज़ॉल्वर क्वेरी को एन्क्रिप्टेड पथ के भीतर रखता है। इसीलिए DNS सर्वर का पता कनेक्शन की नीति के भाग के रूप में आता है, न कि ऐसी वैश्विक सेटिंग के रूप में जिसे आपने मशीन के लिए एक बार चुना था।
पता अपने आप में कुछ तय नहीं करता। रिज़ॉल्वर तभी उत्तर दे सकता है जब उस तक कोई मार्ग हो, और सबसे आम विफलता वह रिज़ॉल्वर है जो केवल तब तक पहुँचने योग्य है जब तक टनल चालू है। जब टनल गिर जाता है और नीति बनी रहती है, तब क्वेरीज़ ऐसे पते पर जाती हैं जिसका कोई मार्ग नहीं, और लक्षण साफ़ त्रुटि नहीं बल्कि समय-समाप्ति होता है। यह अंतर तब मायने रखता है जब आप अगला परीक्षण परिणाम पढ़ते हैं, क्योंकि समय-समाप्ति लोगों को ऐसी ट्रांसपोर्ट सेटिंग्स में भेज देती है जो कभी शामिल ही नहीं थीं।
उत्तरों की तुलना से पहले दो डिज़ाइनों की तुलना करें
पूर्ण टनल और विभाजित DNS विपरीत अपेक्षाएँ पैदा करते हैं, और इनमें से कोई भी खराबी नहीं है। पूर्ण टनल के अंतर्गत हर क्वेरी प्रदाता या कॉर्पोरेट रिज़ॉल्वर पर जा सकती है, इसलिए जुड़ने के बाद सार्वजनिक नामों का अलग उत्तर देना अपेक्षित है। विभाजित DNS के अंतर्गत केवल सूचीबद्ध डोमेन निजी रिज़ॉल्वर पर जाते हैं जबकि बाकी सब स्थानीय रहता है; Windows में डोमेन सूची Name Resolution Policy Table में रहती है, macOS में DNS सेटिंग्स के मेल खाते डोमेन में, और systemd-resolved वाले होस्ट पर प्रति-लिंक रूटिंग डोमेन में।
यही तुलना पहले करनी चाहिए, क्योंकि यह तय करती है कि किसे खराबी गिना जाए। विभाजित DNS के साथ, नए रिज़ॉल्वर से उत्तर देने वाला सार्वजनिक नाम ही जाँच के योग्य है, जबकि सही ढंग से उत्तर देने वाला आंतरिक नाम व्यवस्था के अपना काम करने का प्रमाण है। पूर्ण टनल के साथ, विसंगति वह सार्वजनिक नाम है जो अब भी आपके ISP रिज़ॉल्वर से उत्तर देता है। Microsoft का VPN नाम समाधान पर दस्तावेज़ इन नियमों का Windows क्रम बताता है, जिसमें यह भी शामिल है कि मेल खाती नीति प्रविष्टि एडाप्टर के अपने सर्वरों से पहले कैसे देखी जाती है।
कमरे में तीसरा रिज़ॉल्वर भी है जिसे भूलना आसान है। ब्राउज़र का सुरक्षित DNS स्वयं नाम हल करता है और टनल द्वारा ऑपरेटिंग सिस्टम की नीति बदलने के बाद भी उत्तर देता रह सकता है, इसलिए लोड होने वाला पृष्ठ यह सिद्ध करता है कि ब्राउज़र का रिज़ॉल्वर काम कर गया, यह नहीं कि प्रोफ़ाइल लागू हुई। यदि आप केवल वही तुलना करते हैं जो ब्राउज़र दिखाता है, तो आधे समय आप गलत परत का परीक्षण कर रहे हैं।
केवल एक चर के साथ आधार-रेखा दर्ज करें
टनल बदलें। उसी चरण में नाम, उपकरण या खोज प्रत्यय भी न बदलें। ऐसा नाम चुनें जिसके बारे में पूछने की अनुमति आपको है, नोट करें कि कौन-सा एप्लिकेशन इस्तेमाल किया, और या तो लौटा हुआ पता या सटीक त्रुटि लिख लें। Windows में Get-DnsClientServerAddress -AddressFamily IPv4 प्रति-एडाप्टर सर्वर छापता है और Get-DnsClientNrptPolicy नीति प्रविष्टियाँ छापता है; systemd-resolved वाले Linux में resolvectl status प्रति-लिंक DNS सर्वर और रूटिंग डोमेन दिखाता है; macOS में scutil --dns वह रिज़ॉल्वर क्रम छापता है जिसका सिस्टम वास्तव में पालन करेगा।
फिर क्लाइंट के सामान्य नियंत्रणों से जुड़ें और ठीक वही कमांड दोहराएँ। पहला आउटपुट याद रखने के बजाय सहेजें, क्योंकि तुलना ही पूरा मुद्दा है और कैश खाली करने के बाद लिया गया दूसरा पाठ पहले से ही दूसरा माप है। यदि आधार-रेखा ब्राउज़र आगे रखकर ली गई थी और जुड़ने के बाद का संचालन टर्मिनल में होता है, तो आप दो रिज़ॉल्वर की तुलना कर रहे हैं, एक रिज़ॉल्वर की दो अवस्थाओं की नहीं।
स्पष्ट क्वेरी और एप्लिकेशन लुकअप अलग परीक्षण हैं
किसी एक विशिष्ट सर्वर से पूछना, nslookup name 10.20.0.1 या dig @10.20.0.1 name के साथ, एक ही बात सिद्ध करता है: जिस सर्वर का आपने नाम लिया वह तब उत्तर देता है जब आप उस तक पहुँच सकते हैं। यह चयन-तर्क को पूरी तरह छोड़ देता है, इसलिए यह नहीं बता सकता कि सिस्टम इस नाम के लिए वही सर्वर चुनता या नहीं। इसका उपयोग यह जाँचने के लिए करें कि आवंटित रिज़ॉल्वर पहुँचने योग्य है या नहीं, और नीति जाँचने के लिए इसका उपयोग न करें।
स्थानीय रिज़ॉल्वर से होकर जाने वाला लुकअप चयन का वास्तव में उपयोग करता है। resolvectl query name वही रूटिंग-डोमेन नियम चलाता है और बताता है कि किस प्रोटोकॉल ने उत्तर दिया, Windows में Resolve-DnsName नीति तालिका और क्लाइंट कैश से होकर जाता है, और scutil --dns वह क्रम दिखाता है जिसका लुकअप पालन करेगा। दोनों प्रकार चलाएँ और उन्हें अपने नोट्स के अलग स्तंभों में रखें। सफल स्पष्ट क्वेरी के बगल में विफल एप्लिकेशन लुकअप रूटिंग या चयन की समस्या है, काम करने से इंकार करता रिज़ॉल्वर नहीं।
कैश आपके और उत्तर के बीच खड़ा है। ऑपरेटिंग सिस्टम, स्थानीय स्टब रिज़ॉल्वर, ब्राउज़र और नकारात्मक कैश सभी परिणाम रखते हैं, इसलिए एक भी पैकेट मशीन छोड़े बिना लुकअप सफल हो सकता है। कुछ भी साफ़ करने से पहले परिणाम दर्ज करें: ipconfig /flushdns, resolvectl flush-caches या macOS में sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder। इस चरण में व्यापक नेटवर्क रीसेट छोड़ दें, क्योंकि यह उन साक्ष्यों को नष्ट करता है जो आप अभी एकत्र कर रहे हैं।
इस अंतर का क्या अर्थ है
आपने जो दो पंक्तियाँ दर्ज कीं उनकी तुलना करें और एक भी सेटिंग छूने से पहले बदलाव को वर्गीकृत करें।
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
एक पंक्ति विशेष ज़ोर के योग्य है। जो नाम हल हो जाता है वह काम करती सेवा नहीं है, और DNS की सफलता केवल यह कहती है कि कोई पता मिल गया। यह फ़ॉरवर्डिंग, फ़ायरवॉल नियमों या यह कहने के बारे में कुछ नहीं कहती कि आपका खाता इस सेवा का उपयोग कर सकता है या नहीं, इसलिए यह मानने के बजाय कि खराबी अपने आप चली गई, वास्तविक एप्लिकेशन जाँचकर समाप्त करें।
आधार-रेखा बहाल करें और सत्यापित करें
प्रक्रिया मारने के बजाय क्लाइंट के अपने नियंत्रणों से डिस्कनेक्ट करें, फिर वही तीन कमांड दोबारा पढ़ें। प्रति-लिंक सर्वर, नीति प्रविष्टियाँ और आपके परीक्षण नाम का उत्तर उस आधार-रेखा पर लौटने चाहिए जो आपने पहले लिखी थी। साफ़ डिस्कनेक्ट के बाद बची नीति प्रविष्टि एक वास्तविक दोष है जिसे दर्ज करना चाहिए, और इसी कारण से जनरेट की गई रिज़ॉल्वर फ़ाइल में हाथ से संपादन बुरी आदत है: फ़ाइल फिर से लिखी जाती है और संपादन गायब हो जाता है, या संपादन बचा रहता है और ऐसे रिज़ॉल्वर को पिन कर देता है जिसका अब कोई मार्ग नहीं है।
इस सूची को एक बार, क्रम से पूरा करें। किसी भी परिणाम का निर्णय करने से पहले तय करें कि प्रोफ़ाइल कौन-सा डिज़ाइन लागू करती है। दोनों रन में नाम, उपकरण और प्रत्यय स्थिर रखें। स्पष्ट क्वेरी को एप्लिकेशन लुकअप से अलग रखें। केवल उत्तर नहीं, प्रभावी नीति पढ़ें। तुलना लिखे जाने के बाद कैश अंत में साफ़ करें। वास्तविक एप्लिकेशन से सत्यापित करें, फिर एक बार रीबूट करें और पुष्टि करें कि डिस्कनेक्ट अवस्था अब भी साफ़ है।