VPN क्लायंटसाठी AD साइट मॅपिंग विरुद्ध डोमेन कंट्रोलर पिन करणे
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 मार्गावरून पोहोचणारे कंट्रोलर, आणि साइन-इन केलेला वापरकर्ता काय करू शकतो हे ठरवणारे धोरण. साइट फायरवॉल नियम नाही आणि सीमा रेषा नाही, आणि पुढील पूल बदल दूरस्थ वापरकर्त्यांना डिरेक्टरीच्या नेटवर्क मॉडेलपासून शांतपणे वेगळे करेल, जर मॅपिंग, मार्ग आणि दस्तऐवजीत पर्याय एकत्र हलले नाहीत.