मल्टीहोम सर्वर के लिए सक्रिय निर्देशिका डिज़ाइन पर सलाह


10

मुझे निम्नलिखित आवश्यकताओं (सरलीकृत, वे वास्तव में बहुत खराब हैं) के परिदृश्य के लिए एक सक्रिय सक्रिय निर्देशिका डिजाइन के साथ आने के लिए एक ग्राहक द्वारा सौंपा गया है:

  • क्लाइंट सिस्टम के लिए एक सबनेट है।
  • सर्वर सिस्टम के लिए एक सबनेट है।
  • दोनों नेटवर्क कनेक्ट नहीं हैं।
  • प्रत्येक सर्वर में दो नेटवर्क कार्ड, एक सर्वर नेटवर्क पर, दूसरा क्लाइंट नेटवर्क पर होना चाहिए।
  • क्लाइंट और सर्वर के बीच ट्रैफ़िक केवल क्लाइंट के नेटवर्क पर प्रवाहित होना चाहिए।
  • सर्वर के बीच ट्रैफ़िक केवल सर्वर के नेटवर्क पर प्रवाहित होना चाहिए।
  • यह डोमेन नियंत्रकों पर भी लागू होना चाहिए।

कहने की जरूरत नहीं है, यह बहुत अच्छी तरह से नहीं जाता है कि कैसे सक्रिय निर्देशिका डोमेन नियंत्रकों का पता लगाने के लिए डीएनएस का उपयोग करती है; किसी भी संभावित दृष्टिकोण से निम्न में से एक परिदृश्य सामने आएगा:

  • DC डोमेन में अपना "क्लाइंट-साइड" आईपी पता पंजीकृत करते हैं; ग्राहक उनके साथ उस पते का उपयोग करके बात करेंगे, लेकिन ऐसा सर्वर और AD प्रतिकृति ट्रैफ़िक करेंगे।
  • डीसी डोमेन डोमेन में अपने "सर्वर-साइड" आईपी पते को पंजीकृत करते हैं; सर्वर उनके साथ उस पते का उपयोग करके बात करेंगे और प्रतिकृति ट्रैफ़िक उस नेटवर्क पर प्रवाहित होगी, लेकिन क्लाइंट उन तक पहुंचने में असमर्थ होंगे।
  • डीसी डोमेन डोमेन में दोनों आईपी ​​पते पंजीकृत करेंगे ; यह किसी का अनुमान है कि उन तक पहुंचने के लिए कोई भी प्रणाली क्या करेगी।

बेशक, ये आवश्यकताएं पूरी तरह से पागल हैं और उन सभी को एक ही समय में संतुष्ट नहीं किया जा सकता है, जब तक कि दो नेटवर्क पर डीएनएस सेवा को विभाजित करने और अपने एसआरवी रिकॉर्ड्स को हाथ से (argh) या सर्वरों का पता लगाने जैसे पागल समाधानों का उपयोग न करें डीएनएस का उपयोग करने वाले डीसी और क्लाइंट विन (डबल-अर्ग) का उपयोग करके डीसी का पता लगाते हैं।

मैं जिस समाधान के साथ आया था वह "सर्वर" नेटवर्क पर दो डीसी और "क्लाइंट" एक पर दो डीसी है, दो एडी साइटों को परिभाषित करता है और केवल डीसी प्रतिकृति ट्रैफ़िक के साथ दो नेटवर्क के बीच की सीमा को पार करता है। इसके लिए अभी भी कुछ DNS मैनबलिंग की आवश्यकता होगी , क्योंकि प्रत्येक सर्वर में अभी भी दो नेटवर्क कार्ड (दो सर्वर-साइड डीसी के अलावा और विशुद्ध रूप से बैक-एंड सर्वर) होंगे, लेकिन इसमें कम से कम काम करने की संभावना है।

किसी भी सलाह, के रूप में तेजी से भागने के अलावा अन्य?


7
तेजी से भागे ... अगर आप कर सकते हैं ...
SpacemanSpiff

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

1
क्या इन लोगों ने रूटिंग के बारे में नहीं सुना है? "अधिक NICS !! 1" नेटवर्क सुरक्षा नहीं बनाता है। कहा कि, मैन्युअल SRV रिकॉर्ड के साथ DNS को विभाजित करना बहुत बुरा नहीं लगता।
शेन मैडेन

2
आपका ग्राहक स्पष्ट रूप से व्यावहारिकता को नहीं समझता है। मैं उन्हें बार-बार और बहुतायत से बिलिंग करने की सलाह देता हूं यदि आप बस भागने में सक्षम नहीं हैं।
इवान एंडरसन

1
ग्राहक को आग लगाओ।
ग्वेल्डो

जवाबों:


5

मुझे यह कहने से शुरू करें कि मैं कई अन्य लोगों के साथ सहमत हूं - या तो ग्राहक को मना लें या फिर चलाएं।

हालाँकि, आपकी सूचीबद्ध आवश्यकताओं को देखते हुए (बहुत सारे असूचीबद्ध हैं), मैं यह बनाने के लिए (और आंशिक रूप से परीक्षण किए गए) कम से कम जमीनी कार्य के बारे में सोच सकता हूं।

कई विशिष्ट पहलू हैं जिन पर विचार करने की आवश्यकता है।

  1. सक्रिय निर्देशिका डोमेन सेवा प्रतिकृति
  2. डीसी लोकेटर प्रक्रिया ग्राहकों / सदस्य सर्वर की
  3. गैर-AD DS सेवाओं के लिए नाम रिज़ॉल्यूशन और ट्रैफ़िक

एक और दो में बहुत कुछ है - सामान्य तौर पर हम इस एक पर Microsoft के चक्कर में हैं और Microsoft के AD DS प्रक्रियाओं की सीमा में काम करना है।

नंबर तीन पर हमारे पास काम करने के लिए थोड़ा सा कमरा है। हम सेवाओं (फ़ाइलों, डेटाबेस उदाहरणों, आदि) तक पहुंचने के लिए उपयोग किए गए लेबल चुन सकते हैं।

यहाँ मैं क्या प्रस्ताव है:

अपने डोमेन नियंत्रकों (DC) का निर्माण करें

  • कम से कम दो।
  • प्रत्येक DC के पास दो NIC, प्रत्येक IP नेटवर्क / AD DS साइट में से एक होगा - उन्हें अभी के लिए clt और srv कहते हैं।
  • Srv नेटवर्क में अभी प्रत्येक DC में केवल एक NIC कॉन्फ़िगर करें।

AD साइट और सेवाओं को ठीक से कॉन्फ़िगर करें

  • svv साइट और सबनेट
  • clt साइट और सबनेट
  • साइट से> "सभी साइट लिंक ब्रिज करें" को अनचेक करें -> इंटर-साइट ट्रांसपोर्ट -> राइट-क्लिक करें "आईपी"
  • मौजूद होने पर DEFAULTIPSITELINK को हटाएं (या यदि आपने इसका नाम बदला है) तो कोई साइट लिंक कॉन्फ़िगर नहीं हैं। ध्यान दें कि यह मेरे लिए अज्ञात है - केसीसी के डायरेक्टरी सर्विस इवेंट लॉग में डंप त्रुटियों की संभावना होगी, जिसमें कहा गया था कि दो साइटें (srv और clt) अलग-अलग अंतराल पर जुड़ी नहीं हैं। हालांकि, दो डीसी के बीच प्रतिकृति अभी भी जारी रहेगी क्योंकि वे एक ही साइट में आईपी के उपयोग से एक-दूसरे से संपर्क कर सकते हैं।

AD DS एकीकृत DNS में अतिरिक्त क्षेत्र कॉन्फ़िगर करें

  • यदि आपका AD DS डोमेन acme.local है , तो एक दूसरा प्राइमरी AD इंटीग्रेटेड ज़ोन बनाएँ जिसमें डायनेमिक अपडेट सक्षम हों, जिसे clt.acme.local कहा जाता है ।

अपने डीसी पर दूसरे एनआईसी को कॉन्फ़िगर करें

  • ये एनआईसी क्लैट नेटवर्क / साइट में एनआईसी हैं।
  • उनके आईपी सेट करें
  • यहाँ जादू हिस्सा है - एडाप्टर गुण -> IPv4 गुण -> उन्नत -> DNS टैब -> इस कनेक्शन के लिए DNS प्रत्यय सेट करें clt.acme.local -> चेक इस कनेक्शन को पंजीकृत करें ... -> चेक इस कनेक्शन का उपयोग करें DNS प्रत्यय ... -> के माध्यम से सभी तरह ठीक है।
  • ipconfig / registerdns
  • यह clt.acme.local ज़ोन में clt NIC IP को पंजीकृत करेगा - हमें यह नियंत्रित करने के लिए एक विधि प्रदान करता है जिसे बाद में IP / नेटवर्क का उपयोग किया जाता है।

सदस्य सर्वर NIC कॉन्फ़िगर करें

  • सदस्य सर्वर एनआईसी के clt साइट में अपने DNS प्रत्यय और चेकबॉक्स के अनुसार और साथ ही ऊपर सेट होना चाहिए।
  • इन सेटिंग्स का उपयोग स्थिर और डीएचसीपी के साथ किया जा सकता है, इससे कोई फर्क नहीं पड़ता।

साइटों में डीएनएस [ठूंठ] रिसॉल्वर व्यवहार को कॉन्फ़िगर करें

  • DC का -> DC srv NIC को स्वयं और अन्य DC srv NIC IP का उपयोग करने के लिए कॉन्फ़िगर करें। DC clt NIC DNS को खाली छोड़ दें (हालांकि स्थिर IP की आवश्यकता है)। (डीसी DNS सर्वर अभी भी डिफ़ॉल्ट रूप से सभी आईपी पर सुनेंगे )।
  • सदस्य सर्वर -> डीसी सर्वर साइट आईपी का उपयोग करने के लिए सदस्य सर्वर srv एनआईसी कॉन्फ़िगर करें। सदस्य सर्वर clt एनआईसी DNS को खाली छोड़ दें (स्थिर आईपी का उपयोग किया जा सकता है)।
  • ग्राहक / कार्यस्थान -> डीएनएस को कॉन्फ़िगर करें (या तो डीएचसीपी या स्थिर के माध्यम से) डीसी के क्लेक्ट एनआईसी आईपी का उपयोग करने के लिए।

मैपिंग / संसाधनों को उचित रूप से कॉन्फ़िगर करें

  • जब सर्वर आपस में बात करते हैं तो .acme.local -> का उपयोग करना सुनिश्चित करें।
  • जब ग्राहक सर्वर से बात करते हैं तो .clt.acme.local -> का उपयोग करना सुनिश्चित करें।

मैं किस बारे में बात कर रहा हूं?

  • AD DS प्रतिकृति अभी भी होगी क्योंकि DC एक दूसरे को हल कर सकता है, और एक दूसरे से जुड़ सकता है। Acme.local और _msdcs.acme.local ज़ोन में केवल DC srv होगा NIC IP का AD DS प्रतिकृति केवल srv नेटवर्क पर होगा।
  • सदस्य सर्वर और कार्यस्थानों के लिए डीसी लोकेटर प्रक्रिया कार्य करेगी - हालांकि साइट के अज्ञात होने पर विभिन्न एडी डीएस प्रक्रियाओं के विभिन्न हिस्सों में देरी की संभावना मौजूद होती है, यदि कई डीसी आईपी वापस आ जाते हैं - उन्हें कोशिश की जाएगी, विफल हो जाएगा, और आगे बढ़ेंगे जब तक कोई काम न करे। DFS-N पर प्रभावों का पूरी तरह से मूल्यांकन नहीं किया गया है - लेकिन फिर भी कार्य करेगा।
  • यदि आप उपर्युक्त .acme.local और .clt.acme.local लेबल का उपयोग करते हैं तो गैर AD DS सेवाएं ठीक काम करेंगी।

मैंने इसका पूरी तरह से परीक्षण नहीं किया है, क्योंकि यह बहुत आकर्षक है। हालांकि, इस (वाह, लंबा) जवाब का बिंदु यह मूल्यांकन करना शुरू करना है कि यह संभव है या नहीं - यह नहीं किया जाना चाहिए या नहीं।

@टिप्पणियाँ

@ मसिमो १/२ एक्मे.लोकोल ज़ोन में कई एडी डीएस साइटों को भ्रमित न करें, और इस तरह एसआरवी रिकॉर्ड्स डीसी द्वारा उन acme.local ज़ोन में उन साइटों में पॉप किया जाता है जिनमें एसएलवी रिकॉर्ड्स की आवश्यकता clt.acme.local ज़ोन में होती है। क्लाइंट का प्राथमिक DNS प्रत्यय (और Windows डोमेन जिसमें वे शामिल हैं) अभी भी acme.local होगा। क्लाइंट / वर्कस्टेशन में केवल एक ही NIC होता है, जिसमें प्राथमिक DNS प्रत्यय DHCP से प्राप्त होता है, जो acme.local पर सेट होता है।

Clt.acme.local ज़ोन को SRV रिकॉर्ड की आवश्यकता नहीं है क्योंकि इसका उपयोग DC लोकेटर प्रक्रिया में नहीं किया जाएगा। इसका उपयोग केवल क्लाइंट / वर्कस्टेशन द्वारा सदस्य सर्वर के गैर-AD DS सेवाओं से कनेक्ट करने के लिए किया जाता है, जो clt नेटवर्क में सदस्य सर्वर IP का उपयोग करता है। AD DS संबंधित प्रक्रियाएं (DC लोकेटर) clt.acme.local ज़ोन का उपयोग नहीं करेगी, लेकिन AD DS साइट्स (और सबनेट) acme.local ज़ोन में।

@ मासिमो ३

वहाँ दोनों clt और srv AD DS साइटों के लिए SRV रिकॉर्ड होंगे - बस वे acme.local क्षेत्र में मौजूद होंगे - ऊपर नोट देखें। Clt.acme.local ज़ोन को DC से संबंधित SRV रिकॉर्ड की आवश्यकता नहीं है।

ग्राहक डीसी जुर्माना लगाने में सक्षम होंगे। क्लाइंट DNS सर्वर DC के clt IP की ओर इशारा करते हैं।

जब क्लाइंट पर डीसी लोकेटर प्रक्रिया बंद हो जाती है

  • यदि ग्राहक को पता है कि उसकी साइट DNS प्रश्न _ldap._tcp होगी। [साइट] ._ sites.dc._msdcs.acme.local SRV। यह साइट विशिष्ट DC को वापस कर देगा जिसके पास SRV रिकॉर्ड दर्ज है।
  • यदि क्लाइंट को इसकी साइट नहीं पता है तो DNS सवाल _ldap._tcp.dc._msdcs.acme.local SRV होगा। इससे सभी DC वापस आ जाएंगे। ग्राहक डीसी के LDAP को तब तक बाँधने का प्रयास करेगा जब तक कि वह एक का जवाब नहीं देता। जब क्लाइंट एक पाता है, तो यह क्लाइंट की साइट को निर्धारित करने के लिए साइट लुकअप करता है, और रजिस्ट्री में साइट को कैश करता है ताकि भविष्य में डीसी लोकेटर इंस्टेंसेस जल्दी हो सके।

@ मासिमो ४

ऊ, अच्छा कैच। जिस तरह से मैं इसे देखता हूं इस समस्या के आसपास दो तरीके हैं।

  1. कम प्रभाव (2 नीचे की तुलना में) dc1.acme.local और dc2.acme.lme के ग्राहकों / कार्यस्थानों पर होस्ट फ़ाइल में एक प्रविष्टि बनाने के लिए DC के clt NIC IP की ओर इशारा करता है।

या

  1. डीसी के प्रत्येक पर netlogon.dns फ़ाइल में मैन्युअल रूप से आवश्यक SRV रिकॉर्ड बनाएं। इस संभावना के सर्वर नेटवर्क पर कुछ परिणाम होंगे। यदि यह कॉन्फ़िगर किया गया है, तो सदस्य सर्वर कई बार डीसी नेटवर्क पर संवाद कर सकते हैं।

सभी में से कोई भी यह सुंदर नहीं है, लेकिन यह जरूरी नहीं कि अंतिम लक्ष्य है। हो सकता है कि क्लाइंट सिर्फ आपके टेक चॉप्स का परीक्षण कर रहा हो। इसे उनकी कॉन्फ्रेंस टेबल पर रखें और उन्हें बताएं "यहाँ, यह काम करेगा, लेकिन मैं आपको इसे कॉन्फ़िगर और समर्थन करने के लिए अपनी सामान्य दर से 4 गुना वसूल रहा हूं। आप इसे घटाकर मेरी सामान्य दर - .5x पीटा चार्ज को 1.5x कर सकते हैं। [सही समाधान]। "

जैसा कि पहले उल्लेख किया गया है, मेरी सिफारिश है कि अन्यथा मनाओ या भागो। लेकिन यह सुनिश्चित है कि हास्यास्पद में एक छोटा सा व्यायाम है। :)


यह दिलचस्प है, मैंने दो अलग-अलग DNS नामस्थानों का उपयोग करने के बारे में नहीं सोचा था। लेकिन मैं यहां विभिन्न समस्याओं को देख सकता हूं ... 1) clt.acme.local ज़ोन के लिए कोई डीसी लोकेटर रिकॉर्ड नहीं हैं; तो, ग्राहकों को डीसी कैसे मिलेगा? 2) ग्राहकों का प्राथमिक DNS प्रत्यय अभी भी acme.local होगा, क्योंकि वे डोमेन सदस्य हैं; इसलिए, मुझे लगता है कि वे अभी भी इस क्षेत्र में डीसी लोकेटर रिकॉर्ड की तलाश कर रहे हैं, भले ही उनका एनआईसी का डीएनएस प्रत्यय अलग हो। 3) वैसे भी, ग्राहक साइट के लिए कोई पंजीकृत डीसी नहीं होगा, इसलिए ग्राहक कोई भी खोजने में असमर्थ होंगे।
मास्सिमो

सबसे अधिक संभावना परिणाम है, या तो ग्राहक एक डीसी को खोजने में सक्षम नहीं होंगे (जीत यहां जगह में नहीं है और नेटवर्क रूट किए गए हैं), या वे डीसी के सर्वर-साइड आईपी पते से कनेक्ट करने का प्रयास करेंगे, जो नहीं होगा पहुंच योग्य।
मासिमो

@ मसिमो - पोस्ट के अंत में टिप्पणियों का जवाब दिया।
बुनकर

लेकिन जब क्लाइंट को "आपका DC यह dc1.acme.local" (जो भी साइट हो) कहकर एक SRV रिकॉर्ड मिलता है, तो क्या वह इसके FQDN का उपयोग करके संपर्क करने की कोशिश नहीं करेगा? मुझे नहीं लगता कि यह अपने एनआईसी के डीएनएस प्रत्यय के बारे में परवाह करेगा, यानी मुझे नहीं लगता कि यह "dc1.acme.local जवाब नहीं देता है, चलो" dc1.clt.acme.local "का प्रयास करें। यह। केवल dc1.acme.local का प्रयास करें, जो डीसी के सर्वर-साइड आईपी पते पर मैप करता है ... और यह विफल हो जाएगा। या क्या मैं यहां कुछ याद कर रहा हूं?
मास्सिमो

@ मसिमो - पोस्ट के अंत में टिप्पणियों का जवाब दिया।
बुनकर

3

अंत में मैं दो साइटों के समाधान के साथ गया:

  • "सर्वर" नेटवर्क के लिए दो डीसी, "क्लाइंट" नेटवर्क के लिए दो डीसी।
  • दो विज्ञापन साइट, एक "सर्वर" नेटवर्क के लिए और एक "क्लाइंट" के लिए।
  • "सर्वर" नेटवर्क में डीसी केवल उस पर बैठे एक एनआईसी होगा (ग्राहकों को उन पर बात करने के लिए नहीं जा रहे हैं), तो यह आसान है।
  • "क्लाइंट" ज़ोन में डीसी के पास दो होंगे, लेकिन केवल DNS में उनके क्लाइंट-साइड वाले रजिस्टर होंगे।
  • सर्वर अपने डीसी से बात करेंगे, ग्राहक अपने लोगों से बात करेंगे।

बेशक, इसका मतलब दो नेटवर्क के बीच प्रतिकृति ट्रैफ़िक को सक्षम करना है; "क्लाइंट" नेटवर्क के DCs में अभी भी "सर्वर" नेटवर्क पर एक NIC बैठा होगा, लेकिन चूंकि यह DNS में पंजीकृत नहीं होगा, इसलिए उस नेटवर्क के DC अपने क्लाइंट-साइड IP पते का उपयोग करके उनसे संपर्क करेंगे; ताकि एनआईसी वास्तव में पूरी तरह से बेकार हो जाए, और कुछ फ़ायरवॉल पोर्ट खोलने की आवश्यकता होगी। एकमात्र दूसरा विकल्प डीसी की hostsफाइलों को मेनटेन करना होगा , लेकिन आइए उम्मीद करते हैं कि इससे बचा जा सकता है।

ठीक है, मुझे लगता है कि यह सबसे अच्छा है जो संभव के रूप में कई (पागल) आवश्यकताओं को पूरा करने के लिए किया जा सकता है।

सभी सलाह के लिए धन्यवाद :-)


2

सबसे पहले, जब हम अपने ग्राहकों को सेवा प्रदान करते हैं, तो हमें यह सवाल करना चाहिए कि उनकी आवश्यकताएं क्या हैं। क्लाइंट को यह समझने में सक्षम करना कि उनकी जटिलता का स्तर अनावश्यक है।

  • ग्राहकों का # क्या था?
  • यह सब आंतरिक यातायात है?
  • डोमेन का कार्यात्मक स्तर क्या है?
  • क्या टीएलएस प्रोटोक का उपयोग किया जा रहा है?

का उपयोग करते हुए KISS चाहेंगे method- दो VLANs "SVR" और "CLT" SSL / TLS को सक्षम करने और इसे एक दिन फोन कर बनाने जा ....

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.