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 बाटोबाट पुग्न सकिने कन्ट्रोलर, र साइन-इन गरेको प्रयोगकर्ताले के गर्न सक्छ भन्ने निर्धारण गर्ने नीति। साइट फायरवाल नियम होइन र अलगाव सीमा होइन, र अर्को पूल परिवर्तनले टाढाका प्रयोगकर्तालाई डाइरेक्टरीको नेटवर्क मोडेलबाट चुपचाप अलग गर्नेछ यदि म्यापिङ, रुट र अभिलेखित विकल्पहरू सँगै नचले।