तीन प्रकाशक एक डोमेन कंट्रोलर का VPN पता DNS में डाल सकते हैं

एक से अधिक इंटरफ़ेस वाले डोमेन कंट्रोलर पर तीन अलग-अलग घटक एक ही VPN पता DNS में डाल सकते हैं, और वे एक-दूसरे से स्वतंत्र रूप से विफल होते हैं। अडैप्टर के चेकबॉक्स पर भरोसा करने के बजाय यह तुलना करें कि हर एक क्या प्रकाशित करता है, क्योंकि वह चेकबॉक्स केवल एक को नियंत्रित करता है। लक्षण हर मामले में एक जैसा है: क्लाइंट नाम हल करता है, टनल का पता प्राप्त करता है और डोमेन कंट्रोलर तक नहीं पहुँच पाता। इसे किसने प्रकाशित किया, यही तय करता है कि इसे कैसे रोकना है।

एक सेटिंग, एक सेवा और एक भूमिका; तीन प्रकाशक, तीन स्विच।

रिकॉर्ड से शुरू करें, चेकबॉक्स से नहीं

प्रभावित सर्वर का पूरा नाम उस DNS सर्वर से पूछें जिसे क्लाइंट वास्तव में उपयोग करते हैं, और लौटाया गया हर पता दर्ज करें। हर लौटाए गए पते की तुलना सर्वर के वास्तविक LAN और टनल इंटरफ़ेस से तथा उन नेटवर्क से करें जिनमें क्लाइंट हैं। कोई पता स्थानीय रूप से पूरी तरह वैध हो सकता है और फिर भी महत्वपूर्ण क्लाइंट के लिए अगम्य हो सकता है। रुक-रुक कर होने वाली प्रमाणीकरण विफलताएँ एक सामान्य लक्षण हैं, क्योंकि क्लाइंट अलग-अलग प्रयासों में अलग-अलग पते प्राप्त करते या चुनते हैं।

मशीन का अपना नाम सही ढंग से हल होना बहुत कम साबित करता है। असली परीक्षण क्लाइंट नेटवर्क से किया जाता है।

अडैप्टर केवल एक प्रकाशक है

अडैप्टर के TCP/IP गुणों में उस कनेक्शन का पता पंजीकृत करने के लिए एक चेकबॉक्स है, और टिक हटाने से ठीक एक प्रकाशक शांत हो जाता है। यह बाकी को नहीं रोकता, इसलिए रीस्टार्ट के बाद रिकॉर्ड फिर प्रकट हो सकता है। यदि डोमेन कंट्रोलर DNS सेवा भी चलाता है, तो उस सेवा की अपनी सुनने की कॉन्फ़िगरेशन और अपने नेम सर्वर रिकॉर्ड होते हैं। एक से अधिक इंटरफ़ेस वाले वातावरण के लिए Microsoft का मार्गदर्शन इंटरफ़ेस के व्यवहार, DNS सेवा और Netlogon को अलग-अलग प्रासंगिक प्रकाशक मानता है।

तीन स्विच, तीन स्वामी, और उनमें से केवल एक ही अडैप्टर के गुण पृष्ठ पर रहता है।

DNS सेवा के अपने पते हैं

जिस DNS सर्वर को VPN पता पर सुनने का कहा गया है, वह अडैप्टर का चेकबॉक्स जो भी दावा करे, उसे अपने रिकॉर्ड में प्रकाशित करता रहता है। सेवा के सुनने के पतों को इच्छित इंटरफ़ेस के साथ संरेखित करें और साथ ही ज़ोन की नेम सर्वर प्रविष्टियाँ भी देखें। श्रोताओं को बदलने से उन क्लाइंट में बाधा पड़ सकती है जो इस समय वही पता उपयोग कर रहे हैं जिसे आप हटा रहे हैं, इसलिए पहले तय करें कि कौन किस पर निर्भर है। केवल इसलिए श्रोता हटाना कि वह VPN पता है, उन क्लाइंट को काट सकता है जिनकी आप मदद करना चाहते थे।

Netlogon और सामान्य रूप से डोमेन कंट्रोलर की खोज भी अपने कर्तव्यों के भाग के रूप में पते पंजीकृत करती है। पूरे डोमेन में पंजीकरणों को दबाएँ नहीं, और पुराने रिमोट एक्सेस पंजीकरण समाधान को यह पुष्टि किए बिना कॉपी न करें कि वह आपके संस्करण और भूमिका पर लागू होता है।

सफाई से पहले स्वामित्व

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

अंत में आप जो चाहते हैं वह प्रकाशित पतों और श्रोताओं का एक ज्ञात समुच्चय है, जबकि रोज़मर्रा का डोमेन पंजीकरण अपना काम करता रहे। जिस मशीन का नाम मैन्युअल सफाई के ठीक बाद संयोगवश सही हल हो जाए, वह यह नहीं है।

दर्ज करें कि कौन सा प्रकाशक उत्तरदायी था, कौन से रिकॉर्ड बदले और किन क्लाइंट का परीक्षण हुआ। अगले एक से अधिक इंटरफ़ेस वाले सर्वर पर भी वही तीन संदिग्ध होंगे।