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 संपादित करणे थांबवा। पुढील उपयुक्त पायरी म्हणजे पत्ता आणि तिथपर्यंतचा मार्ग, कारण नाव निराकरणाने आपले काम आधीच केले आहे।