Azure VM वर RRAS समर्थित नाही: रचनेपूर्वी तपासा

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

खालील मार्गदर्शक समर्थन पृष्ठापासून सुरू होते, नंतर आवश्यकता आणि बदली पर्यायांकडे जाते।

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

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

पृष्ठ उघडे असतानाच रचना दस्तऐवजात उद्धरण लिहा। समर्थन स्थिती ही स्रोत असलेली वस्तुस्थिती आहे, आणि जी रचना पुनरावलोकन त्याचे उद्धरण देऊ शकत नाही तिला डेमो असलेला व्यक्ती वादात हरवेल।

OS समर्थनाला भूमिका व वैशिष्ट्य समर्थनापासून वेगळे करा

तेच मार्गदर्शन Network Policy and Access Services ला समर्थित भूमिकांमध्ये ठेवते, तर RRAS ला स्वतंत्रपणे असमर्थित असे सूचीबद्ध करते। या दोन नोंदी वेगवेगळ्या गोष्टी सांगतात, आणि त्यांना “दूरस्थ प्रवेश समर्थित आहे” असे एकत्र करणे हा चुकीच्या वाचनावर आधारित प्रकल्प मंजूर करण्याचा मार्ग आहे। ऑपरेटिंग सिस्टम समर्थित असणे स्वतःची ओळ असलेल्या वैशिष्ट्याबद्दल काहीही सांगत नाही।

मर्यादा कधीकधी उद्धृत केल्यापेक्षाही अरुंद आहे। ती Azure VM च्या आत चालणाऱ्या त्या वैशिष्ट्याबद्दल आहे; याचा अर्थ खाजगी नेटवर्क Azure शी जोडू शकत नाही असा नाही, आणि RRAS सर्वत्र असमर्थित आहे असेही ते म्हणत नाही। पॅकेट योग्यरित्या पुढे पाठवणारी जुनी प्रयोगशाळा पॅकेटबद्दलचा पुरावा आहे, समर्थन विधानाबद्दल नाही।

उर्वरित प्रकल्पात या दोन प्रश्न वेगळे ठेवा: ते चालते का, आणि ते समर्थित आहे का। तुम्हाला प्रत्येकासाठी वेगवेगळी उत्तरे आणि कधीकधी वेगवेगळे जबाबदार व्यक्ती लागतील।

रचनेने प्रत्यक्षात काय करावे ते लिहा

बदली निवडण्यापूर्वी साइटची यादी अशा आवश्यकतांमध्ये बदला ज्यांच्यावर उत्पादन मोजता येईल:

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

NAT हा तो मुद्दा आहे जो वगळला जातो आणि नंतर संपूर्ण रचना ठरवतो। IPsec स्थापित करू शकणारे उपकरण ते बदलत असलेल्या RRAS तैनातीपेक्षा वेगळ्या पद्धतीने पत्त्यांचे भाषांतर करू शकते, आणि यामुळे शाखेला कोणते पत्ते स्रोत म्हणून दिसतात आणि तुमचे लॉग काय नोंदवतात ते बदलते।

यादी नेटवर्क मालकांकडे न्या आणि कोणत्याही उत्पादन चर्चेपूर्वी ती पुष्टी करा। अस्पष्ट आवश्यकता प्रत्येक विक्रेता तुलनेला आवडीनिवडीच्या वादात बदलतात।

त्या आवश्यकतांविरुद्ध बदलींचे मूल्यांकन करा

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

दोन उपकरण VM समोरील लोड बॅलन्सर स्वतःच उच्च उपलब्धता नाही। तो फ्रंट एंड देतो, समक्रमित बोगदा स्थिती नाही, आणि प्रत्येक सत्र टाकून देणारे फेलओव्हर ही अशी रचना निवड आहे जी कोणीतरी जाणीवपूर्वक करावी लागते। उपकरण विक्रेत्याला विचारा की समर्थित HA नमुना कोणता आहे आणि तो साइटांना वचन दिलेल्या उपलब्धतेशी जुळतो का। त्या साइटी त्यावर अवलंबून राहण्यापूर्वी फेलओव्हरची चाचणी करा, आणि प्रत्येक गमावलेल्या सत्राला आश्चर्य नाही तर निष्कर्ष माना।

जिथे आवश्यकता खरोखर सोपी आहे — एक साइट, एक उपसर्ग, आच्छादन नाही — तिथे व्यवस्थापित सेवा सामान्यतः कार्यचालन खर्चात जिंकते। जिथे भाषांतर आणि गतिशील राउटिंग दोन्ही खेळात आहेत, तिथे उपकरणाचा मार्ग हाच एकमेव योग्य असू शकतो, आणि हे असमर्थित VM ठेवण्याऐवजी दीर्घ स्थलांतराची योजना करण्याचे कारण आहे।

RRAS VM आधीच चालत असेल तर

शोध हा तो हटवण्याचे कारण नाही। त्या VM ने जमा केलेल्या अवलंबनांभोवती बदलाची योजना करा: इतर सबनेट अवलंबून असलेले मार्ग, स्रोत पत्ते लपवणारे NAT नियम, आणि त्याच्या पत्त्याकडून अपेक्षा करायला देखरेखीने शिकलेले सर्व। समर्थित लक्ष्य शेजारी रचले जाते आणि पडताळले जाते तेव्हा आवश्यक मार्ग आणि चाचणी केलेला पुनर्प्राप्ती मार्ग जपा।

समर्थनक्षमता आणि तांत्रिक निदान हे संपूर्ण काळात स्वतंत्र निष्कर्ष म्हणून ठेवा। असमर्थित मांडणीत सामान्य राउटिंग त्रुटीही असू शकते, आणि ती त्रुटी दुरुस्त केल्याने तिची समर्थन स्थिती बदलत नाही। दोन्ही विधाने अहवालात आहेत, आणि एक दुसऱ्याला रद्द करत नाही।

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