सार्वजनिक DNS चल्नुको अर्थ Active Directory भेटिन्छ भन्ने होइन

VPN जोडिन्छ, ब्राउजरले सार्वजनिक साइट खोल्छ, र ल्यापटप अझै डोमेनमा साइन-इन गर्न सक्दैन। सामान्य निष्कर्ष नामहरू समाधान हुने भएकाले DNS ठीक छ भन्ने हुन्छ। त्यो ठीक छैन, र कारण यो हो कि ब्राउजर परीक्षणले डोमेनसँग जोडिएको क्लाइन्टलाई चाहिने शृंखलाको एउटा मात्र खोज परीक्षण गर्छ। डोमेन खोजले पहिले सेवा रेकर्ड माग्छ, त्यसपछि ती रेकर्डले नाम दिने कन्ट्रोलरका ठेगाना, र त्यसपछि ती कन्ट्रोलरले सुन्ने पोर्टसम्मको मार्ग। सार्वजनिक उत्तरले यीमध्ये एउटै चरण पूरा गर्दैन।

भ्रम: नामहरू समाधान हुन्छन्, त्यसैले DNS सकियो

सार्वजनिक साइट समाधान हुनुले केवल यो भन्छ कि कुनै रिजोल्भरले सार्वजनिक जोनको नामका लागि एउटा A वा AAAA प्रश्नको उत्तर दियो। Active Directory त्यही प्रोटोकल अर्को प्रश्नका लागि प्रयोग गर्छ: डोमेनका सेवा कहाँ छन्, र यो क्लाइन्टले कुन कन्ट्रोलर प्रयोग गर्नुपर्छ। प्रश्न डोमेनको नाममा रहेको जोनमुनि SRV रेकर्डका रूपमा व्यक्त हुन्छ, र पुनरावर्ती सार्वजनिक रिजोल्भरसँग ती राख्ने कुनै कारण छैन।

रेकर्ड नभएमा रिजोल्भर नकारात्मक उत्तर फर्काउँछ, जो अवरोध होइन, मान्य DNS उत्तर हो। त्यसपछि क्लाइन्ट क्यासमा रहेको कन्ट्रोलर जानकारीतर्फ फर्कन्छ, यदि छ भने, र त्यसैले डेस्कटप घण्टौं ठीक देखिन सक्छ र रिबुट वा पासवर्ड परिवर्तनपछि असफल हुन्छ।

डोमेन क्लाइन्टले वास्तवमा के माग्छ, क्रममा

corp.example जस्तो डोमेनका लागि सामान्य लोकेटर प्रश्न _ldap._tcp.dc._msdcs.corp.example हो। SRV उत्तरहरू सम्भावित कन्ट्रोलर र तिनका पोर्टको नाम दिन्छन्, र त्यसपछि जडान खोल्नुअघि क्लाइन्टलाई ती होस्ट नामका लागि ठेगाना रेकर्ड चाहिन्छ। साइट-सचेत खोजले साइट उपडोमेनमुनि प्रश्न थप्छ, र उत्तरहरूले कुन कन्ट्रोलर प्राथमिक हुन् भन्ने निर्धारण गर्छ, कुन अनिवार्य हो भन्ने होइन।

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

समस्या हुने नेटवर्कबाट यही क्रममा शृंखला पछ्याउनुहोस्। अगम्य ठेगानामा समाधान हुने होस्ट नाम राउटिङ त्रुटि हो, DNS त्रुटि होइन। लोकेटर रेकर्ड नभएको पुग्न सकिने कन्ट्रोलर DNS त्रुटि हो, राउटिङ त्रुटि होइन। दुवैले समान प्रयोगकर्ता गुनासा र पूर्ण रूपमा फरक मर्मत उत्पन्न गर्छन्।

सार्वजनिक रिजोल्भरले उत्तर दिँदा पनि साइन-इन किन भाँचिन्छ

यदि एडाप्टरले क्लाइन्टलाई सार्वजनिक रिजोल्भर दिन्छ भने सार्वजनिक नाम चल्छन् र आन्तरिक नामस्थान चल्दैन। दोस्रो सार्वजनिक रिजोल्भर थप्दा फाइदा हुँदैन, किनकि दुवैले जोन राख्दैनन्। “पहिले आन्तरिक, त्यसपछि सार्वजनिक” भन्ने चलनचल्तीको सूची पनि प्रत्येक डोमेनको नियमजस्तो व्यवहार गर्दैन: पहिलो सर्भरको नकारात्मक उत्तर वैध उत्तर हो, र उत्तर खाली थियो भन्ने मात्र कारणले क्लाइन्टले दोस्रो सर्भर फेरि प्रयास गर्दैन।

दुवै आन्तरिक रिजोल्भर, यदि दुई चलाउनुहुन्छ भने, AD नामस्थान राख्नुपर्छ र क्लाइन्टको हालको नेटवर्कबाट पुग्न सकिने हुनुपर्छ। स्प्लिट-टनेल डिजाइनले ठ्याक्कै यही भाँच्छ: VPN ले टनेलको उपनेट बोक्न सक्छ, तर आन्तरिक रिजोल्भर टनेलले राउट नगर्ने प्रिफिक्समा बस्छ, त्यसैले प्रश्न उत्तर दिन नसक्ने रिजोल्भरकहाँ जान्छ।

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

टनेलको DNS र त्यसका मार्गहरू मिलाएर राख्नुहोस्

रिजोल्भर पठाउने तर त्यसलाई समेट्ने प्रिफिक्स नपठाउने VPN प्रोफाइलले क्लाइन्ट पुग्न नसक्ने रिजोल्भर बनाउँछ; प्रिफिक्स पठाएर रिजोल्भर नपठाउने प्रोफाइलले क्लाइन्टलाई स्थानीयलाई सोध्न छाड्छ। जोडीलाई एउटै कन्फिगरेसन वस्तु मान्नुहोस् र प्रत्येक प्रोफाइल परिवर्तनपछि दुवै जाँच्नुहोस्, किनकि पुनर्व्यवस्थित पुश वा नयाँ स्प्लिट-टनेल नीतिले तिनलाई अलग गर्न सक्छ।

क्लाइन्टले पठाइएको सेटिङसँग के गर्छ पनि जाँच्नुहोस्। केही क्लाइन्टले DNS सर्भर टनेल इन्टरफेसमा मात्र लागू गर्छन् र भौतिक एडाप्टरको रिजोल्भर यथावत् राख्छन्, त्यसैले कुन जित्छ भन्ने इन्टरफेस मेट्रिक र सोधिने नाममा निर्भर हुन्छ। भौतिक एडाप्टर बन्द हुँदा मात्र आन्तरिक उत्तर आउँछ भने सुधार्नुपर्ने संयन्त्र त्यही हो, डोमेन रेकर्ड होइन।

खोज कल र एउटा जीवित कार्यले स्वीकार गर्नुहोस्

उपयोगी स्वीकृति परीक्षणले लोकेटर प्रश्न चलाउँछ र त्यसपछि एउटा वास्तविक प्रमाणित कार्य गर्छ, जस्तै डाइरेक्टरी-समर्थित साझेदारी खोल्ने वा टिकट माग्ने। VPN परिवर्तनअघि र पछि फेरि, एउटै मेसिनमा, बीचमा रिबुट बिना गर्नुहोस्। क्यास गरिएका प्रमाणहरू र पहिल्यै खुला सत्रहरूले भाँचिएको मार्गलाई खुसीसाथ स्वस्थ देखाउनेछन्, त्यसैले सफल डेस्कटप लगइन परीक्षण होइन।

Microsoft का DNS क्लाइन्टका लागि सिफारिसहरू ले आन्तरिक नामस्थान समाधान गर्ने र सार्वजनिक प्रश्न माथि पठाउनेबीच त्यही रेखा तान्छन्, र VPN ल्याउँदा यही व्यवस्था जोगाउनुपर्छ।

यदि असफलता केवल ढिलो हो, असफल होइन भने, ढिलाइलाई निदानबाट अलग राख्नुहोस्। खोजका क्रममा समय सकिनु अगम्य कन्ट्रोलर, रोकिएको पोर्ट वा ढिलो उत्तर दिने रिजोल्भरबाट आउन सक्छ, र तीमध्ये केही पनि केवल प्रतीक्षाले प्रमाणित हुँदैन। रिजोल्भर सेटिङ बदल्नुअघि वास्तविक प्रश्न, त्यसको उत्तर र जडान प्रयास रेकर्ड गर्नुहोस्।