विंडोज 7 पर प्रत्यक्ष। भाग 2

पहले भाग में, DirectAccess के लिए समर्पित, मैंने इस समाधान की तकनीकी नींव पर विचार करना शुरू किया। आपको याद दिला दूं कि इस फाउंडेशन में शामिल हैं: IPv6, IPv6 पर IPsec, नाम रिज़ॉल्यूशन पॉलिसी टेबल (NRPT)। हमने उन कारणों पर चर्चा की है कि DirectAccess अंतर्निहित प्रोटोकॉल के रूप में IPv6 का उपयोग क्यों करते हैं। इसका मतलब यह है कि अब, रूसी इंटरनेट सहित IPv4 के स्पष्ट प्रभुत्व के युग में, DirectAccess का उपयोग असंभव है? नहीं। पारगमन प्रौद्योगिकियों के लिए धन्यवाद, DirectAccess IPv4 वातावरण में बहुत अच्छा लगता है।



IPv6 पारगमन प्रौद्योगिकी



DirectAccess का उपयोग करते समय, IPv6 जानकारी इंटरनेट पर DA क्लाइंट से DA परिधि के माध्यम से परिधि क्षेत्र में किसी भी सर्वर (या क्लाइंट) पर कॉर्पोरेट नेटवर्क पर स्थानांतरित की जाती है। यही है, यह माना जाता है कि इस तरह के एक सूचना चैनल में सभी तीन प्रतिभागी आईपीवी 6 का समर्थन करते हैं। DA क्लाइंट और DA सर्वर के लिए, IPv6 समर्थन की सख्त आवश्यकता है। इसलिए, पारगमन प्रौद्योगिकियां तीन स्थितियों में मदद कर सकती हैं:

- जब DA क्लाइंट और DA सर्वर के बीच इंटरनेट सेगमेंट IPv6 का समर्थन नहीं करता है;

- जब DA नेटवर्क और गंतव्य सर्वर के बीच कॉरपोरेट नेटवर्क सेगमेंट जिसमें यातायात का इरादा है, IPv6 का समर्थन नहीं करता है;

- जब गंतव्य सर्वर स्वयं IPv6 का समर्थन नहीं करता है।

हम सूचीबद्ध क्रम में सभी तीन मामलों पर विचार करते हैं।



एक डीए क्लाइंट और एक डीए सर्वर के बीच पारगमन



एक बार जब DA क्लाइंट इंटरनेट पर होता है, तो वह DA सर्वर के साथ IPv6 टनल पर IPsec स्थापित करने की कोशिश करता है। ऐसी सुरंग कैसे बनाई जाती है यह सीधे इस बात पर निर्भर करता है कि आईपी क्लाइंट इंटरनेट प्रदाता से क्या कॉन्फ़िगरेशन प्राप्त करता है। आदर्श और, तदनुसार, कम से कम संभावित मामले में, DA क्लाइंट को IPv6 पता प्राप्त होता है। यही है, डीए क्लाइंट IPv6 इंटरनेट पर होने के लिए पर्याप्त भाग्यशाली था, इसके पैकेट केवल डीए सर्वर पर रूट किए गए हैं।

एक अधिक यथार्थवादी विकल्प यह है कि DA क्लाइंट प्रदाता से एक सार्वजनिक IPv4 पता प्राप्त करता है। इस स्थिति में, क्लाइंट 6to4 पारगमन तकनीक (RFC 3056) का उपयोग करता है। इस तकनीक के लिए धन्यवाद, फॉर्म 2002 का एक IPv6 पता: WWXX: YYZZ :: / 48 क्लाइंट पर बनाया गया है, जो 2002 से शुरू होता है (उपसर्ग 2002 केवल इंगित करता है कि 6to4 ट्रांजिट तकनीक है) और WWXX में एक सार्वजनिक vv4 पता है: YYZZ फ़ील्ड (अंजीर देखें। 1):



अंजीर। 1



अब इस प्रकार गठित IPv6 पैकेट को IPv4 पैकेट में पैक किया गया और IPv4 इंटरनेट के माध्यम से रूट किया गया।

इससे भी अधिक यथार्थवादी विकल्प यह है कि डीए क्लाइंट को प्रदाता से एक निजी आईपीवी 4 पता प्राप्त होता है, उदाहरण के लिए, 192.168.200.111। इस मामले में, एक और पारगमन तकनीक शामिल है - टेरेडो (RFC 4380)। टेरेडो का लक्ष्य यह सुनिश्चित करना है कि स्रोत आईपीवी 6 पैकेट न केवल आईपीवी 4 पर्यावरण से गुजरता है, बल्कि एनएटी के माध्यम से भी। इस संबंध में, टेरेडो के संचालन का सिद्धांत 6to4 की तुलना में कुछ अधिक जटिल है, और उत्पन्न IPv6 पते की संरचना का रूप है:



अंजीर। 2



सभी टेरेडो पते 2001 के उपसर्ग के साथ शुरू होते हैं, और अस्पष्ट बाहरी पोर्ट और अस्पष्ट बाहरी पता फ़ील्ड में क्रमशः नेट यूडीपी पोर्ट और बाहरी आईपी पते शामिल होते हैं। मैं केवल यह स्पष्ट करूंगा कि क्या स्पष्ट रूप से निहित नहीं है, लेकिन पूर्व निर्धारित संख्या के साथ एक्सओआर ऑपरेशन के परिणामस्वरूप। उत्पन्न पैकेट को UDP पैकेट में पैक किया जाता है, जो बदले में, एक IPv4 पैकेट में पैक किया जाता है। अब NAT के माध्यम से जानकारी भेजने के लिए सब कुछ तैयार है। आप 6to4 और टेरेडो पारगमन तकनीकों के बारे में अधिक जान सकते हैं, साथ ही बाद में उल्लेखित ISATAP तकनीक, उदाहरण के लिए, यहां ।

एक और काफी संभव विकल्प है जब डीए क्लाइंट को प्रदाता से एक निश्चित आईपीवी 4 पता प्राप्त होता है, लेकिन साथ ही, बाहरी दुनिया के साथ संचार केवल 80 और 443 टीसीपी बंदरगाहों पर अनुमति दी जाती है। इस स्थिति में, एक प्रोटोकॉल जो अब RFC मानक नहीं है, वह केवल Windows 7 और Windows Server 2008 R2 पर समर्थित होगा। प्रोटोकॉल को IP-HTTPS कहा जाता है और, जैसा कि नाम से ही स्पष्ट है, IPv4 पर HTTPS का उपयोग करके IPv6 पैकेट के हस्तांतरण को सक्षम करता है। मैं जोर देता हूं कि इस प्रोटोकॉल का उपयोग केवल तभी किया जाएगा जब ऊपर सूचीबद्ध पारगमन तकनीकों का उपयोग सफल न हो।

और अंत में, यदि केवल पोर्ट 80 की अनुमति है, तो, आश्चर्य-आश्चर्य, DirectAccess काम नहीं करेगा, और बाहर कॉर्पोरेट संसाधनों तक पहुंच असंभव होगी। किसने सोचा होगा। :)



डीए सर्वर और गंतव्य सर्वर के बीच पारगमन



खैर, आईपीवी 6 पैकेट डीए सर्वर तक पहुंच गया। अपनी सेटिंग के अनुसार, DA सर्वर कॉर्पोरेट नेटवर्क के आगे IPv6 पैकेट को अप्रत्यक्ष रूप से अप्रत्यक्ष रूप से या बिना एन्क्रिप्शन के साथ कर रहा है। और यहां यह सवाल उठता है कि क्या आपके संगठन का नेटवर्क वातावरण IPv6 का समर्थन करता है? अधिक विशेष रूप से, सक्रिय संचार उपकरण हैं, मुख्य रूप से राउटर, आईपीवी 6 के साथ काम करने में सक्षम हैं?

ऐसी स्थिति पर विचार करें जहां गंतव्य सर्वर IPv6 का समर्थन करता है, लेकिन कोई संचार उपकरण नहीं। फिर एक और पारगमन तकनीक बचाव की ओर आती है - ISATAP (इंट्रा-साइट ऑटोमैटिक टनल एड्रेसिंग प्रोटोकॉल, RFC 4214)। ISATAP का उपयोग करते समय, यह माना जाता है कि मेजबान के पास संगठन द्वारा स्वीकार किए गए किसी भी तरीके से कम से कम एक IPv4 पता है। अन्यथा, होस्ट आमतौर पर नेटवर्क पर अन्य मशीनों के साथ कैसे इंटरैक्ट करता है। तब होस्ट IPv6 पता स्वचालित रूप से उत्पन्न होता है, इसके IPv6 पते के अंतिम 32 बिट्स इसके IPv4 पते के अनुरूप होते हैं। उदाहरण के लिए, यदि विभिन्न खंडों के दो होस्ट आपस में बातचीत करना शुरू करते हैं, तो उनके पते इस तरह दिख सकते हैं (तालिका 1 देखें)



फ़ील्ड मान



IPv6 स्रोत पता FE80 :: 5EFE: 10.40.1.29

IPv6 गंतव्य पता FE80 :: 5EFE: 192.168.41.30

IPv4 स्रोत पता 10.40.1.29

IPv4 गंतव्य पता 192.168.41.30

तालिका 1



इसलिए, जब एक DA सर्वर को IPv4 राउटर के माध्यम से एक IPv6 पैकेट भेजने की आवश्यकता होती है, तो DA सर्वर प्राप्तकर्ता का IPv4 पता जानने के लिए DNS का उपयोग करेगा, इस जानकारी के आधार पर, एक ISATAP प्रकार का IPv6 पैकेट जनरेट करें, एक नियमित IPv4 पैकेट में पैक करें और इसे प्राप्तकर्ता को भेजें। बाद वाली जानकारी को रिवर्स ऑर्डर में अनपैक कर देता है और मूल IPv6 पैकेट प्राप्त करता है, जिसके हेडर से यह देखा जा सकता है कि पैकेट वास्तव में इस होस्ट के लिए अभिप्रेत है और इसे आगे संसाधित किया जा सकता है।



नेट-PT



अंतिम विकल्प जिसे नोट किया जाना चाहिए, जब गंतव्य सर्वर, सिद्धांत रूप में, आईपीवी 6 के साथ काम करना नहीं जानता है। वैसे, मैं ध्यान दूंगा कि अगर हम विंडोज के बारे में बात करते हैं, तो आईपीवी 6 समर्थन परिवार के ऑपरेटिंग सिस्टम में लागू होता है, विंडोज एक्सपी के साथ शुरू होता है। खैर, उदाहरण के लिए, विंडोज 2000? और मैं वास्तव में DirectAccess का उपयोग करके बाहर से ऐसी मशीनों तक पहुंच प्राप्त करना चाहता हूं। इस स्थिति में, NAT-PT विनिर्देशन (RFC 2766) का समर्थन करने वाले उपकरण की आवश्यकता होती है। NAT-PT IPv4 पतों को IPv4 पतों में अनुवाद करने के लिए जिम्मेदार है, जिससे हमारे मामले में DA ग्राहकों को IPv4-only होस्ट तक पहुंच प्राप्त करने की अनुमति मिलती है। NAT-PT या तो विंडोज 7 या विंडोज सर्वर 2008 R2 पर समर्थित नहीं है। हालाँकि, इस तंत्र के लिए समर्थन फ़ोरफ़्रंट यूनिफ़ाइड एक्सेस गेटवे (UAG) उत्पाद में लागू किया गया है। Windows Server 2008 R2 पर स्थापित और DA सर्वर के रूप में कॉन्फ़िगर किया गया, UAG NAT-PT सहित कुछ उन्नत DirectAccess सुविधाएँ प्रदान करता है। यूएजी की समीक्षा इस चर्चा के दायरे से बाहर है। ठीक है, इसके अलावा, NAT-PT का कार्यान्वयन अन्य उत्पादों में पाया जा सकता है, जिसमें Microsoft नहीं है।

पारगमन विषय को सारांशित करते हुए, यह ध्यान रखना महत्वपूर्ण है कि व्यवस्थापक से और इससे भी अधिक उपयोगकर्ता से, इन सभी प्रौद्योगिकियों के एक विशेष अलग कॉन्फ़िगरेशन की आवश्यकता नहीं है। डीए सर्वर स्थापित करते समय विज़ार्ड द्वारा पारगमन सुनिश्चित करने के लिए सभी की आवश्यकता होती है। DA- क्लाइंट पर, 6to4, Teredo, IP-HTTPS, ISATAP के लिए समर्थन स्वचालित रूप से सक्षम है और आवश्यक होने पर लागू किया जाता है।



IPv6 पर IPsec



IPsec एक DirectAccess समाधान में प्रतिभागियों के बीच यातायात की सुरक्षा के लिए आधार है। IP संस्करण 4 के लिए, IP प्रोटोकॉल के मुकाबले IPsec विनिर्देश बहुत बाद में दिखाई दिया। यह, विशेष रूप से, IPv4 पर IPsec के विभिन्न कार्यान्वयन के उद्भव के लिए, कभी-कभी पूरी तरह से एक दूसरे के साथ संगत नहीं होता है। IPv6 के लिए IPsec को नए IP प्रोटोकॉल के साथ समवर्ती रूप से डिजाइन किया गया था। IPvec हेडर के लिए समर्थन IPv6 स्टैक को लागू करने के लिए एक शर्त है। इसने विभिन्न आपूर्तिकर्ताओं से समाधानों की अधिकतम अनुकूलता के लिए आवश्यक शर्तें बनाईं। दूसरी ओर, इसका मतलब यह नहीं है कि IPv6 का उपयोग करते समय आपको IPsec का उपयोग करना चाहिए। लेकिन IPA6 पर आधारित DirectAccess के मामले में, IPsec का उपयोग संचारित यातायात की सुरक्षा के लिए सबसे तार्किक तरीका है।

चौथे संस्करण के साथ, IPv6 के लिए IPsec दो सुरक्षा विकल्पों का समर्थन करता है: प्रमाणीकरण हेडर (AH) और एन्कैप्सुलेटिंग सिक्योरिटी पेलोड (ESP)। पहले संस्करण में, प्रत्येक पैकेट, वास्तव में, डिजिटल रूप से हस्ताक्षरित है, जो डेटा के प्रमाणीकरण को सुनिश्चित करता है, संचरण के दौरान उनकी अखंडता की गारंटी देता है। हालांकि, पैकेट डेटा एन्क्रिप्शन के बिना स्पष्ट पाठ में प्रेषित होता है। दूसरे विकल्प में, प्लस बाकी सब कुछ, पैकेट डेटा भी एन्क्रिप्ट किया गया है, जो प्रेषित जानकारी की गोपनीयता सुनिश्चित करता है। DirectAccess की तैनाती करते समय इन विकल्पों के संयोजन तथाकथित एक्सेस मॉडल को परिभाषित करते हैं।

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

चयनित सर्वर एक्सेस (संशोधित एंड-एज) मॉडल में, ट्रैफ़िक अभी भी केवल DA सर्वर पर एन्क्रिप्ट किया गया है। और आंतरिक नेटवर्क पर, केवल प्रमाणीकरण (एएच) का उपयोग किया जाता है। यह दृष्टिकोण केवल कुछ DA ग्राहकों को कॉरपोरेट नेटवर्क पर कुछ सर्वरों और अनुप्रयोगों तक पहुँचने की अनुमति देता है (चित्र 3 देखें)।



अंजीर। 3



यह ध्यान में रखा जाना चाहिए कि IPv6 पर Vista IPsec से पहले OS में, पूरी तरह से लागू नहीं किया गया है, इसलिए, इस आंकड़े में, जिस सर्वर से DA क्लाइंट इस मॉडल तक पहुंच सकता है, उसे Windows Server 2008 या बाद के रूप में चिह्नित किया जाता है।

अंत में, एंड-टू-एंड मॉडल (छवि 4) में, पैकेट डीए क्लाइंट पर एन्क्रिप्ट किए गए हैं और गंतव्य सर्वर पर पहले से ही डिक्रिप्ट किए गए हैं। डीए सर्वर केवल इस ट्रैफ़िक को स्वयं के माध्यम से आगे बढ़ाता है।



अंजीर। 4



यह दृष्टिकोण उच्चतम स्तर की सुरक्षा प्रदान करता है।

अंततः, विशिष्ट IPsec सेटिंग्स समूह नीतियों में परिभाषित की जाती हैं, जिन्हें हमेशा बदला जा सकता है। इस प्रकार, IPsec सेटिंग्स में हेरफेर करके, आप हाइब्रिड मॉडल का उपयोग कर सकते हैं जो आपकी विशिष्ट स्थिति के लिए सबसे उपयुक्त हैं। यह एक DirectAccess आधारित समाधान का जोड़ा लचीलापन है।



नाम समाधान नीति तालिका



DirectAccess की अंतिम तकनीकी नींव नाम रिज़ॉल्यूशन पॉलिसी टेबल (NRPT), या यों कहें कि इस तालिका और DNS सिस्टम का उपयोग करके नामों को हल करने का एक तरीका है। जब एक DA क्लाइंट इंटरनेट पर होता है, तो उसे यह समझना चाहिए कि कौन से नाम आंतरिक हैं और इसलिए, कॉर्पोरेट DNS सर्वर द्वारा हल किया जाना चाहिए, और जो बाहरी रूप से, इंटरनेट पर DNS सर्वरों को हल करना होगा।

तो NRPT टेबल आपको DNS सर्वर को नेटवर्क इंटरफेस के लिए नहीं, बल्कि कुछ नामस्थान के लिए सेट करने की अनुमति देता है। हर बार, कॉर्पोरेट नेटवर्क के बाहर होने पर, जब कोई नाम हल किया जाता है, उदाहरण के लिए srv1.contoso.com, DA क्लाइंट पहले यह जाँचता है कि इस नाम या इसके भाग के लिए NRPT में कोई रेखा है या नहीं। यदि इस नाम को हल करने के लिए, क्लाइंट दिए गए नेमस्पेस के लिए संबंधित NRPT लाइन में संकेतित DNS सर्वर से संपर्क करता है (देखें 5%)। यदि नहीं, तो कॉल नेटवर्क इंटरफ़ेस सेटिंग्स में निर्दिष्ट DNS सर्वर में होता है, अर्थात DNS प्रदाता को।



अंजीर। 5



इसके अलावा, तथाकथित छूट नीतियां हैं। इन नीतियों में निर्दिष्ट नाम हमेशा बाहरी इंटरनेट DNS सर्वर द्वारा ही हल किए जाते हैं।

हालांकि, एक बार फिर इस बात पर जोर देना महत्वपूर्ण है कि NRPT का उपयोग करते हुए नाम समाधान के ऐसे "गैर-मानक" संस्करण को केवल तभी लागू किया जाता है जब DA ग्राहक "समझता है" कि यह इंटरनेट पर है, बाहर। यदि यह आंतरिक ग्रिड में है, तो इस तरह के बगीचे को बाड़ क्यों दें। इसलिए, डीए क्लाइंट के स्थान का निर्धारण करने के लिए एक एल्गोरिथ्म है। यह एल्गोरिथ्म, साथ ही साथ बुनियादी ढांचे की आवश्यकताओं और DA सर्वर की सेटिंग्स को DirectAccess पर तीसरे अंतिम पोस्ट में चर्चा की जाएगी।