nslookup VPN पर हल क्यों करता है पर ब्राउज़र नहीं

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

नीचे दी गई जाँचें उन रास्तों को सिस्टम से बाहर की ओर अनुसरण करती हैं। जब तक आपको पता न चले कि कौन-सा रास्ता उत्तर दे और कौन-सा विफल हुआ, VPN प्रोफ़ाइल न बदलें।

तीन नीतियाँ उत्तर तय करती हैं

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

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

ब्राउज़र अलग सवाल क्यों पूछता है

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

पता-परिवार वरीयता देरी समझाती है, विफलता नहीं। जो ब्राउज़र केवल IPv4 ले जाने वाली टनल पर पहले IPv6 रिकॉर्ड माँगता है वह पीछे हटने से पहले समय-सीमा बीतने की प्रतीक्षा करता है। Firefox ने इसी के लिए वरीयता रखी है, और उसे बंद करना मरम्मत नहीं बल्कि निदान का कदम है।

रिज़ॉल्वर सूची और नियम पढ़ें

Windows पर सिद्धांत गढ़ने से पहले वह छापें जो सिस्टम के पास है। Get-DnsClientServerAddress प्रत्येक इंटरफ़ेस के सर्वर दिखाता है, Get-DnsClientNrptRule नामस्थान नियमों की सूची देता है, और Resolve-DnsName सिस्टम मार्ग से ठीक नाम का उत्तर देता है। उस उत्तर की तुलना VPN के सर्वर पर पते से सीधी क्वेरी से करें। जब Resolve-DnsName विफल हो और सीधी क्वेरी सफल हो, तो संदिग्ध रिज़ॉल्वर सूची या नामस्थान नियम है।

नाम को भी जाँचें। आंतरिक छोटे नाम को वह निजी प्रत्यय चाहिए हो सकता है जो केवल VPN एडाप्टर देता है, जबकि पूर्णतः योग्य नाम ठीक से हल होता है। सफल खोज के बाद प्रमाणपत्र चेतावनी किसी और समस्या की है।

अपहुँच्य धकेला गया रिज़ॉल्वर

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

अगर रिज़ॉल्वर अपहुँच्य है, तो मरम्मत मार्ग या शामिल सबनेट है, दूसरा DNS सर्वर नहीं।

एन्क्रिप्टेड DNS पूरा रास्ता बचाता है

DNS-over-HTTPS वाले ब्राउज़र चुने हुए प्रदाता से HTTPS कनेक्शन पर स्वयं नाम हल करते हैं। यह चालू होने पर उन खोजों के लिए सिस्टम रिज़ॉल्वर और split DNS नियम पूरी तरह बचाए जाते हैं, इसलिए ब्राउज़र में आंतरिक नाम विफल होते हैं जबकि ऑपरेटिंग सिस्टम उन्हें सही ढंग से हल करता है। उल्टा भी होता है: आंतरिक नाम ऐसे प्रदाता के ज़रिए ब्राउज़र में सफल होते हैं जिसे उन्हें कभी नहीं देखना चाहिए था, और यह कनेक्टिविटी नहीं नीति की समस्या है।

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

विफलता से मेल खाने वाली मरम्मत

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

फिर खोज को कनेक्शन से अलग करें। जो नाम सही पते पर हल होता है पर कनेक्शन से इंकार करता है वह सेवा, फ़ायरवॉल या प्रमाणपत्र की समस्या है, और DNS बदलाव उसे ठीक नहीं करेंगे।

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