सार्वजनिक 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 आणताना हीच मांडणी टिकवायची आहे।

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