एउटै एडाप्टरमा दुई 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 प्रोफाइलले नेमस्पेसका नियम बोक्न सक्छ र जडानपछि पनि ती रहने कि नरहने छान्न सक्छ; रिजोल्भर पुग्न नसकिने अवस्थामा पनि रहने नियमले क्लाइन्टहरूलाई मृत सर्भरलाई प्राथमिकता दिन छोड्छ, र जडानमा सीमित नियम सुरुङ जाँदा हराउँछ। यी व्यवहारमध्ये सेवालाई कुन चाहिन्छ निर्णय गर्नुहोस्, नियम कसको हो चिन्ह लगाउनुहोस्, र अधिकारको विभाजन कसैको प्रयोगशालाको सम्झनामा होइन, प्रोफाइलको छेउमा अभिलेख गरिएको राख्नुहोस्।