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 नियमहरू, र अनुगमनले त्यसको ठेगानाबाट अपेक्षा गर्न सिकेको सबै। समर्थित लक्ष्य छेउमै डिजाइन र प्रमाणित हुँदा आवश्यक मार्ग र परीक्षण गरिएको पुनःप्राप्ति मार्ग जोगाउनुहोस्।

समर्थनक्षमता र प्राविधिक निदानलाई सधैं अलग निष्कर्षका रूपमा राख्नुहोस्। असमर्थित व्यवस्थामा साधारण राउटिङ त्रुटि पनि हुन सक्छ, र त्यो त्रुटि सुधार्दा यसको समर्थन स्थिति बदलिँदैन। दुवै भनाइ प्रतिवेदनमा पर्छन्, र कुनैले अर्कोलाई रद्द गर्दैन।

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