VPN क्लाइंट के लिए AD साइट मैपिंग बनाम डोमेन कंट्रोलर पिन करना

VPN पूल पर रिमोट-एक्सेस क्लाइंट अंततः दुनिया के दूसरे छोर पर स्थित डोमेन कंट्रोलर से बात कर सकते हैं, और इसे ठीक करने के दो तरीके हैं: पूल को सही कंट्रोलर वाली साइट से जुड़े Active Directory सबनेट के रूप में वर्णित करें, या क्लाइंट या एप्लिकेशन को एक विशिष्ट कंट्रोलर पर पिन करें। पहला एक टोपोलॉजी कथन है जिस पर DC Locator कार्य कर सकता है। दूसरा प्रति-एप्लिकेशन ओवरराइड है जो टोपोलॉजी को पूरी तरह अनदेखा करता है। दोनों की लागत अलग है, और आज तेज़ वाले को पकड़ना ही वह तरीका है जिससे डायरेक्टरी टीम अंततः दोनों को बनाए रखती है।

प्रत्येक दृष्टिकोण वास्तव में क्या बदलता है

सबनेट ऑब्जेक्ट डायरेक्टरी में एक रिकॉर्ड है जो बताता है कि कोई पता-सीमा किस साइट की है। Active Directory मॉड्यूल और मौजूदा साइट के साथ, क्रिया इतनी छोटी है कि पूर्वावलोकन किया जा सके:

New-ADReplicationSubnet -Name "10.90.0.0/24" -Site "Remote-Access-Hub" -WhatIf
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

-WhatIf डायरेक्टरी लेख का पूर्वावलोकन करता है। यह ऑब्जेक्ट नहीं बनाता और यह जाँच नहीं करता कि उस सीमा का कोई क्लाइंट किसी चीज़ तक पहुँच सकता है या नहीं, और लोग ठीक इसी हिस्से की अपेक्षा करते हैं। DC Locator साइट मॉडल पढ़ता है जब वह सेवा रिकॉर्ड हल करता है, इसलिए सटीक सबनेट ऑब्जेक्ट बदल देता है कि क्लाइंट को क्या प्रस्तावित किया जाता है।

पिनिंग दूसरी परत पर काम करती है। एप्लिकेशन कॉन्फ़िग में स्थिर कंट्रोलर नाम, भीतर होस्ट वाली LDAP स्ट्रिंग, या पसंदीदा सर्वर का नाम देने वाला रजिस्ट्री मान—ये सभी खोज को पथ से हटा देते हैं। एप्लिकेशन उस कंट्रोलर से बात करता है जब तक कोई सेटिंग न बदले, और विफलता पर स्विचओवर वही है जो वह एप्लिकेशन लागू करता है।

सबनेट मैपिंग कहाँ जीतती है

पूल को मैप करना नेटवर्क स्थान को एक बार वर्णित करता है, हर उस क्लाइंट के लिए जो DC Locator का उपयोग करता है। जब पूल एक /24 से तीन तक बढ़ता है, मॉडल दो या तीन ऑब्जेक्ट में बदलता है, एप्लिकेशन सूची में नहीं। यही पूरा लाभ है, और यह बड़ा है जब क्लाइंट आबादी आपके नियंत्रण में न हो।

दिक्कत यह है कि ऑब्जेक्ट को उस पते से मेल खाना चाहिए जो कंट्रोलर वास्तव में देखता है। यदि VPN गेटवे हर क्लाइंट को हब पते में अनुवादित करता है, तो बिना अनुवाद वाला पूल जोड़ना ऐसा नेटवर्क स्थान बताता है जिसे कोई कंट्रोलर कभी नहीं देखता। जल्दी तय करें कि डिज़ाइन क्लाइंट के स्रोत पते को सुरक्षित रखता है या नहीं, और यदि नहीं, तो VPN सर्वर पर कॉन्फ़िगर किए गए पूल के बजाय अनुवादित सीमा को मैप करें।

दूसरी सीमा: साइट मॉडल एक प्राथमिकता और टोपोलॉजी कथन है। यह कंट्रोलर को पहुँचने योग्य नहीं बनाता और उपयोगकर्ता को कुछ नहीं देता। पहुँच क्षमता रूट और फ़ायरवॉल नीति देती है; अनुमति खाता नीति देती है।

पिनिंग कहाँ जीतती है

पिनिंग सही उत्तर है जब खोज काम नहीं कर सकती: कोई पुराना एप्लिकेशन जो ऐसे नाम से कंट्रोलर हल करता है जिसे आप बदल नहीं सकते, ऐसा फ़िल्टर जो ठीक एक कंट्रोलर पते की अनुमति देता है, या सर्वरों का स्थिर समूह जहाँ कंट्रोलर एप्लिकेशन डिज़ाइन का हिस्सा है। उन मामलों में पिन असली बाधा का दस्तावेज़ीकरण है, शॉर्टकट नहीं।

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

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

तीन शर्तों पर चुनें

इन्हें इसी क्रम में पूछें और निर्णय आमतौर पर स्वयं हो जाता है। पहले, क्या एप्लिकेशन बिल्कुल DC Locator का उपयोग करता है, या पहले से कंट्रोलर पता ले चलता है? दूसरे, क्या कंट्रोलर पूल का पता देखता है, या अनुवादित पता? तीसरे, पूल कितनी बार बदलता है, इसकी तुलना में पिन को कितनी जगहों पर अद्यतन करना पड़ेगा?

डायरेक्टरी-जागरूक एप्लिकेशन्स साथ स्रोत-संरक्षक रूटिंग साथ बदलता पूल: सबनेट मैप करें। वह एप्लिकेशन जो खोज नहीं कर सकता, या वह फ़िल्टर जो एक पता स्वीकार करता है: उसे पिन करें, और क्यों लिखें। बाकी सब टोपोलॉजी ठीक करने का मामला है, एक और ओवरराइड जोड़ने का नहीं।

VPN क्लाइंट से सत्यापित करें और अनुबंध अलग रखें

वास्तविक दूरस्थ पथ से परीक्षण करें, उस LAN वर्कस्टेशन से नहीं जो पहले से साइट में है। केवल क्लाइंट का अपना दृश्य मायने रखता है:

nltest /dsgetsite
nltest /dsgetdc:corp.example.com /force
echo %LOGONSERVER%

यदि रिपोर्ट की गई साइट वही है जो आपने मैप की, तो ऑब्जेक्ट मेल खाता है। यदि क्लाइंट कोई साइट नहीं बताता, तो वह जो पता प्रस्तुत करता है वह किसी सबनेट ऑब्जेक्ट के भीतर नहीं आता, जिसका अर्थ आमतौर पर अनुवाद या पुराना प्रीफ़िक्स है। फिर मैपिंग विफल मानने से पहले जाँचें कि चुना गया कंट्रोलर वही है जो आपका इरादा था, क्योंकि क्लाइंट खोज परिणाम कैश करते हैं और विफलता पर स्विचओवर वैध रूप से दूसरा कंट्रोलर चुन सकता है।

तीनों अनुबंध एक दस्तावेज़ में रखें: पूल और उसके सबनेट ऑब्जेक्ट, VPN पथ से पहुँचने योग्य कंट्रोलर, और वह नीति जो तय करती है कि साइन-इन किया गया उपयोगकर्ता क्या कर सकता है। साइट फ़ायरवॉल नियम नहीं है और सीमांकन सीमा नहीं है, और अगला पूल परिवर्तन दूरस्थ उपयोगकर्ताओं को डायरेक्टरी के नेटवर्क मॉडल से चुपचाप अलग कर देगा जब तक मैपिंग, रूट और प्रलेखित विकल्प साथ न चलें।