Windows आपके VPN नाम ऐसे DNS सर्वर पर क्यों भेजता है जिसे आपने कभी सेट नहीं किया

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

आपने क्या बदला, और असल में क्या तय करता है

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

इसीलिए एक ही लैपटॉप पर दो नाम एक ही पल अलग रास्तों पर जा सकते हैं। कॉर्पोरेट सफ़िक्स के अंतर्गत होस्ट अपने नियम का पालन करता है; सार्वजनिक नाम डिफ़ॉल्ट रास्ते पर चलता है, जिसका मतलब आम तौर पर वह अडैप्टर है जो पहले जवाब देता है।

तालिका किसी नाम को कैसे मिलाती है

नियम नेमस्पेस के आधार पर कुंजीबद्ध हैं, और सबसे विशिष्ट मेल जीतता है। corp.example के लिए नियम vpn.corp.example पर लागू होता है और example.net पर लागू नहीं होता। . नेमस्पेस वाला नियम वह सब ढकता है जो बाकी नियम नहीं ढकते, जिससे वह सूची की सबसे ख़तरनाक प्रविष्टि बन जाता है और तब जाँचने लायक भी, जब कोई असंबंधित साइट सुरंग से हल हो।

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

इच्छा-सूची नहीं, प्रभावी तालिका पढ़ें

कॉन्फ़िगर किए गए नियम और प्रभावी नियम दो अलग सवाल हैं। Get-DnsClientNrptRule सूचीबद्ध करता है कि मशीन पर क्या मौजूद है। Get-DnsClientNrptPolicy -Effective दिखाता है कि क्लाइंट वास्तव में क्या लागू करेगा, नीति और स्थानीय सेटिंग्स से जुड़े मानों के साथ।

उस आउटपुट के सफ़िक्स की तुलना आप जिस नाम की जाँच कर रहे हैं उससे अक्षर-दर-अक्षर करें। corp.example के लिए नियम corp.example.com पर समाप्त होने वाला नाम नहीं पकड़ता, और एक जगह अंत में बिंदु होना और दूसरी जगह न होना मेल बदलने के लिए काफ़ी है।

नियम के बिना Windows एक से अधिक अडैप्टर से पूछता है

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

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

ऐसे रास्ते जो रिज़ॉल्वर को पूरी तरह छोड़ देते हैं

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

यह भी जाँचें कि ऐप किसी पुराने सत्र के कैश किए पते से कनेक्ट हो रहा है या नहीं। Clear-DnsClientCache और फिर वही लुकअप पुराने नतीजे से अनुमान लगाने की तुलना में साफ़ जवाब देता है।

उसी नाम से जाँचें जो विफल हुआ

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

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