एका अ‍ॅडॉप्टरवरील दोन DNS सर्व्हर नेमस्पेस विभागत नाहीत

एका अ‍ॅडॉप्टरवर दोन रिझॉल्व्हर सूचीबद्ध करणे म्हणजे एक डोमेन एका सर्व्हरकडे आणि दुसरे डोमेन दुसऱ्याकडे पाठवण्याचा मार्ग वाटतो, पण रिझॉल्व्हर यादीतील काहीही असे चालत नाही। Windows नावाने सोडवते, आणि कोणत्या सर्व्हरला विचारायचे हा निर्णय क्रमबद्ध पत्ता यादीतून नाही तर धोरण वस्तूंमधून येतो। बदलायचा मानसिक नमुना रांग हा आहे: डोमेन A साठी पहिला सर्व्हर आणि डोमेन B साठी दुसरा सर्व्हर असे काही नसते। प्रत्येक नेमस्पेससाठी सर्व्हरची स्पष्ट नावे देणारा नियमसंच असतो, आणि ते नियम असतील तर अ‍ॅडॉप्टरची यादी रंजक राहत नाही।

समजूत: दोन पत्ते दोन डोमेन विभागतात

हा विश्वास टिकतो कारण एक सर्व्हर सगळ्यांना उत्तर देत असेल आणि दुसरा केवळ फॉलबॅक असेल तेव्हा तो अपघाताने चालतो। क्लायंट पहिल्या सर्व्हरला विचारतो, तो सर्व्हर पुढे पाठवतो किंवा पुनरावृत्ती करतो, आणि उत्तर येते; झोन प्रत्यक्षात कोणत्या रिझॉल्व्हरकडे होता हे कोणालाही जाणवत नाही। दोन नेमस्पेस त्यांच्यातील पुढे पाठवणीशिवाय वेगळ्या खाजगी झोनमध्ये राहू लागताच भ्रम फुटतो, कारण तेव्हा पहिला सर्व्हर नाव अस्तित्वात नाही असे अधिकाराने उत्तर देतो। पहिल्या सर्व्हरचे नकारात्मक उत्तर फॉलबॅक सुरू करत नाही, कारण क्लायंटला अपयश नाही तर निर्णायक उत्तर मिळाले आहे।

क्रमबद्ध यादीत डोमेनची संकल्पनाच नाही, म्हणून ती हेतू व्यक्त करू शकत नाही। यादी प्रत्यक्षात कशावर नियंत्रण ठेवते ते म्हणजे कोणत्या सर्व्हरला आधी विचारायचे आणि कोणाला दुसऱ्यांदा प्रयत्न करायचे, आणि ती दोन्ही उत्तरे प्रत्येक नावाला समानपणे लागू होतात।

Windows निवडीसाठी प्रत्यक्षात काय वापरते

नाव निराकरण धोरण तक्ता नावाची जुळणी कॉन्फिगर केलेल्या नेमस्पेसशी करतो आणि त्या जुळणीसाठी सर्व्हर व पर्याय निवडतो। नियम स्थानिक पातळीवर कॉन्फिगर करता येतात, गट धोरणाने पोहोचवता येतात किंवा VPN प्रोफाइलमधून देता येतात, आणि प्रभावी धोरण एकच यादी नसून संयोजन असते। म्हणूनच पहिले निदान नेहमी प्रभावी स्थिती असते: स्थानिक पातळीवर तयार केलेला नियम व्यवस्थापित धोरणाकडून हरला तर त्याच्या कॉन्फिगरेशनने सुचवलेल्यापेक्षा पूर्णपणे वेगळे वागणारी प्रयोगशाळा तयार होते। नियम विशिष्टतेनुसारही जुळवले जातात, त्यामुळे रुंद नेमस्पेस नोंद अरुंद नोंदीला कॉन्फिगर केलेल्या घटकांच्या यादीत न दिसणाऱ्या पद्धतीने झाकू शकते। प्रभावी क्रम वाचणे हाच कोणता नियम जिंकतो हे पाहण्याचा एकमेव मार्ग।

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

पहिली आज्ञा यंत्रावर काय कॉन्फिगर आहे ते सूचीबद्ध करते; दुसरी क्लायंट प्रत्यक्षात काय लागू करेल ते दाखवते, इतरत्रून आलेल्या नोंदींसह। प्रभावी आउटपुटमध्ये व्यवस्थापित नेमस्पेस असल्यास, बदलाची विनंती करण्याचे योग्य स्थान त्या धोरणाचा मालक आहे, स्थानिक नियम यादी नाही। दोन्ही आज्ञा केवळ स्थिती वाचतात, त्यामुळे बदलास कोणी संमती देण्यापूर्वी त्या चालवण्यात काहीच खर्च नाही।

प्रत्येक नेमस्पेससाठी एक नियम, वस्तू ठेवून घ्या

प्रभावी स्थिती समजल्यानंतर प्रत्येक नेमस्पेससाठी एक नियम तयार करा आणि प्रत्येक आज्ञा परत देते ती वस्तू जतन करा। दर्शनी नावे माणसांसाठी लेबल असतात, आणि परत दिलेल्या वस्तूतील अद्वितीय ओळखकर्ता हाच नंतर विश्वासार्ह हटवण्याचा लक्ष्य असतो। दोन्ही ओळखकर्ते नेमस्पेस व रिझॉल्व्हर नोंदवणाऱ्या त्याच बदल टिपेत लिहा, कारण ते तयार करणारे सत्र स्वच्छ करणारे सत्र असेलच असे नाही।

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

सुरुवातीचा ठिपका प्रत्यय जुळणी दर्शवतो, त्यामुळे नियम app.svc.internal.example आणि त्याखालील सर्व काही व्यापतो। येथील दोन्ही पत्ते या प्रयोगशाळेच्या स्वतःच्या मार्गनिर्देशन योजनेचे आहेत; नियम झोन तयार करत नाही, मार्ग स्थापित करत नाही किंवा शेवटी जोडणाऱ्या अनुप्रयोगाला अधिकृत करत नाही, आणि Add-DnsClientNrptRule संदर्भ कोणते मापदंड काय करते ते नेमके नोंदवते।

लक्ष द्या या आज्ञा काय करत नाहीत: त्या संपूर्ण यंत्रासाठी आहेत, VPN सत्रापुरत्या मर्यादित नाहीत, आणि खिडकी बंद केल्यावरही टिकतात। हे विसरणारी प्रयोगशाळा बोगदा गेल्यानंतर धोरण मागे सोडते।

क्लायंटने सर्व्हर निवडला हे सिद्ध करा

विशिष्ट सर्व्हरला नाव माहीत आहे का असे विचारणे तो सर्व्हर उत्तर देऊ शकतो हे सिद्ध करते, जे क्लायंटने तो सर्व्हर निवडला या दाव्यासारखे नाही। महत्त्वाची चाचणी नेहमीच्या क्लायंट मार्गाने खरे नाव सोडवते आणि नंतर कोणत्या रिझॉल्व्हरने ते हाताळले हे निश्चित करते, आदर्शपणे मार्ग देणारा बोगदा सुरू असताना। बोगदा बंद असल्यास, योग्यरीत्या मर्यादित नियमही पोहोचू न शकणाऱ्या सर्व्हरकडे निर्देश करतो, आणि ही धोरणाची नाही तर मार्गनिर्देशनाची समस्या आहे। नंतर दोघांत फरक करता यावा म्हणून दोन्ही स्थिती तपासा।

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

नियम अस्तित्वात येण्यापूर्वीच्या कालावधीतील कॅशे केलेली उत्तरे आणि स्वतःच्या एन्क्रिप्टेड DNS ने प्रणाली रिझॉल्व्हर पूर्णपणे टाळणाऱ्या अनुप्रयोगांकडे लक्ष द्या। शोध प्रत्यय हे आणखी एक स्वतंत्र वैशिष्ट्य आहे: नियम पूर्ण नावासाठी रिझॉल्व्हर निवडू शकतो, पण रिकाम्या होस्टनावाचा त्या नेमस्पेसपर्यंत विस्तार करण्याचे Windows ला शिकवत नाही।

तुम्ही तयार केलेले नेमके हटवा

स्वच्छता ही अशी जागा आहे जिथे प्रयोगशाळा इशारा देणारी गोष्ट बनते। यंत्रावरील प्रत्येक नियम हटवणे जलद असते आणि दुसऱ्या कोणाच्या अवलंबून असलेल्या धोरणाचे उच्चाटन करते, म्हणून नियम तयार करताना नोंदवलेले ओळखकर्ते वापरा, आणि नंतर प्रभावी स्थिती पुन्हा वाचून यंत्र जिथून सुरू झाले तिथे परत आले याची खात्री करा। ते तयार करणारे सत्र नसेल तर ओळखकर्ते अस्तित्वात असलेली एकमेव जागा बदल टीप आहे। म्हणूनच ते पहिली आज्ञा चालण्यापूर्वी लिहितात, नंतर नाही।

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

प्रयोगशाळा नाही तर तैनातीसाठी, आयुष्याचा प्रश्न नियमाइतकाच महत्त्वाचा आहे। VPN प्रोफाइल नेमस्पेसचे नियम वाहून नेऊ शकते आणि जोडणीनंतर ते टिकतील का हे निवडू शकते; रिझॉल्व्हर पोहोचू न शकणाऱ्या स्थितीत टिकणारा नियम क्लायंटला मृत सर्व्हरला प्राधान्य देऊन ठेवतो, आणि जोडणीपुरता मर्यादित नियम बोगदा गेल्यावर अदृश्य होतो। यापैकी कोणते वर्तन सेवेला हवे आहे ते ठरवा, नियम कोणाचा आहे ते चिन्हांकित करा, आणि अधिकाराची विभागणी कोणाच्या प्रयोगशाळेच्या स्मरणात नाही तर प्रोफाइलजवळ नोंदवलेली ठेवा।