Azure VM पर RRAS समर्थित नहीं है: डिज़ाइन से पहले जाँचें

आप पोर्टल खोलते हैं, Windows Server 2022 को एक सबनेट में तैनात करते हैं, और Remote Access भूमिका बिना किसी समस्या के स्थापित हो जाती है। यह क्रम साबित करता है कि इंस्टॉलर काम करता है, यह नहीं कि Microsoft इस कॉन्फ़िगरेशन का समर्थन करता है। Azure वर्चुअल मशीनों के लिए प्रकाशित सर्वर सॉफ़्टवेयर समर्थन मार्गदर्शन RRAS को उन Windows Server सुविधाओं में सूचीबद्ध करता है जो Azure VM पर समर्थित नहीं हैं, और यह एक आर्किटेक्चर निर्णय है, समस्या-निवारण का विवरण नहीं। जो टनल ऊपर आ जाती है वह तैनाती को समर्थन सीमा के अंदर नहीं ले जाती।

नीचे दिया गया मार्गदर्शन समर्थन पृष्ठ से शुरू होता है, फिर आवश्यकताओं और प्रतिस्थापन विकल्पों की ओर बढ़ता है।

प्रयोगशाला में नहीं, समर्थन पृष्ठ से शुरू करें

कुछ भी मापने से पहले Azure VM समर्थन मार्गदर्शन पढ़ें। यह Windows Server को एक अविभाजित खंड मानने के बजाय समर्थित उत्पादों, भूमिकाओं और सुविधाओं को अलग करता है। ध्यान दें कि आपका इच्छित कार्यभार वास्तव में किस पंक्ति के अंतर्गत आता है, क्योंकि कंसोल में संबंधित दिखने वाले दो घटक अलग-अलग पंक्तियों में हो सकते हैं।

पृष्ठ खुला रहने के दौरान ही डिज़ाइन दस्तावेज़ में उद्धरण लिखें। समर्थन स्थिति स्रोत वाला तथ्य है, और जो डिज़ाइन समीक्षा इसका उद्धरण नहीं दे सकती, उसे डेमो रखने वाला व्यक्ति बहस में हरा देगा।

OS समर्थन को भूमिका और सुविधा समर्थन से अलग रखें

वही मार्गदर्शन Network Policy and Access Services को समर्थित भूमिकाओं में रखता है, जबकि RRAS को अलग से असमर्थित बताता है। ये दोनों प्रविष्टियाँ अलग-अलग चीज़ें बताती हैं, और इन्हें “दूरस्थ पहुँच समर्थित है” में मिला देना ही गलत पढ़ने के आधार पर परियोजना को मंज़ूरी दिलाने का तरीका है। ऑपरेटिंग सिस्टम का समर्थित होना ऐसी सुविधा के बारे में कुछ नहीं कहता जिसकी अपनी पंक्ति है।

यह सीमा कभी-कभी जितनी उद्धृत की जाती है उससे भी संकरी है। यह उस सुविधा के बारे में है जो Azure VM के अंदर चलती है; इसका अर्थ यह नहीं कि कोई निजी नेटवर्क Azure से जुड़ नहीं सकता, और यह भी नहीं कहता कि RRAS हर जगह असमर्थित है। पुरानी प्रयोगशाला जो पैकेट सही ढंग से अग्रेषित करती है, पैकेट के बारे में प्रमाण है, समर्थन वक्तव्य के बारे में नहीं।

बाकी परियोजना के दौरान इन दो प्रश्नों को अलग रखें: क्या यह काम करता है, और क्या यह समर्थित है। आपको हर एक के लिए अलग उत्तर और कभी-कभी अलग ज़िम्मेदार व्यक्ति चाहिए होंगे।

लिखें कि डिज़ाइन को वास्तव में क्या करना है

प्रतिस्थापन चुनने से पहले साइट सूची को ऐसी आवश्यकताओं में बदलें जिन पर उत्पाद को मापा जा सके:

• वे टनल प्रोटोकॉल जो शाखा उपकरण पहले से बोलते हैं, और क्या किसी साइट को गतिशील रूटिंग चाहिए।
• दूरस्थ प्रीफ़िक्स, जिनमें कोई भी अतिव्यापी पता स्थान शामिल है जिसे रूटिंग के बजाय अनुवाद चाहिए।
• Azure के साथ रूट का आदान-प्रदान, और रूटिंग तालिका की हर प्रविष्टि का स्वामी कौन है।
• वह थ्रूपुट और कनेक्शन संख्या जो सबसे व्यस्त घंटे को सहना है।
• वह फ़ेलओवर व्यवहार जिस पर साइट मालिक सहमत हुए हैं, केवल वह नहीं जो आप बना सकते हैं।

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

सूची को नेटवर्क मालिकों के पास ले जाएँ और किसी भी उत्पाद चर्चा से पहले उसकी पुष्टि करें। अस्पष्ट आवश्यकताएँ हर विक्रेता तुलना को पसंद-नापसंद की बहस में बदल देती हैं।

उन्हीं आवश्यकताओं पर प्रतिस्थापनों का मूल्यांकन करें

Azure की प्रबंधित कनेक्टिविटी सेवाओं और विक्रेता-समर्थित नेटवर्क वर्चुअल उपकरणों, दोनों को एक ही सूची पर अंक दिए जाने चाहिए। यह न मानें कि इनमें से कोई RRAS VM का सीधा समतुल्य है केवल इसलिए कि वह IPsec समाप्त कर सकता है: NAT मॉडल और रूट स्वामित्व तथा उच्च उपलब्धता का डिज़ाइन तय करते हैं कि मौजूदा साइटें कैसे जुड़ती हैं और उनके उत्तर कहाँ लौटते हैं। हर उम्मीदवार को कागज़ पर सूची के सामने अंक दें और लिखें कि वह किन आवश्यकताओं में विफल है, क्योंकि वही टिप्पणी चयन को बाद में समीक्षा-योग्य बनाती है।

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

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

यदि RRAS VM पहले से चल रहा है

खोज उसे हटाने का कारण नहीं है। बदलाव को उन निर्भरताओं के आसपास योजनाबद्ध करें जो उस VM ने जमा की हैं: वे रूट जिन पर अन्य सबनेट निर्भर हैं, स्रोत पतों को छिपाने वाले NAT नियम, और वह सब जो निगरानी ने उसके पते से अपेक्षा करना सीखा है। ज़रूरी रूट और परीक्षित पुनर्प्राप्ति मार्ग बनाए रखें, जबकि समर्थित लक्ष्य साथ-साथ डिज़ाइन और सत्यापित होता रहे।

समर्थन-क्षमता और तकनीकी निदान को हर समय अलग निष्कर्ष के रूप में रखें। एक असमर्थित व्यवस्था में साधारण रूटिंग त्रुटि भी हो सकती है, और उस त्रुटि को ठीक करने से उसकी समर्थन स्थिति नहीं बदलती। दोनों कथन रिपोर्ट में होने चाहिए, और कोई एक दूसरे को रद्द नहीं करता।

समर्थन उद्धरण, आवश्यकताओं की सूची, चुना गया प्रतिस्थापन और कटओवर क्रम दर्ज करके मार्गदर्शन समाप्त करें। लेखा परीक्षक या नया टीम सदस्य पहले यही चार चीज़ें पूछेगा।