पोइन्ट-टु-साइटलाई रुट-आधारित Azure VPN गेटवे किन चाहिन्छ
नीति-आधारित गेटवेमा क्लाइन्ट रुटका लागि टनेल इन्टरफेस हुँदैन। के फेरि बनाउनुपर्छ, कुन क्रममा, र प्रतिस्थापनपछि कुन सीमाहरू रहन्छन्।
नीति-आधारित गेटवेले ट्राफिक चयनकर्ताहरूद्वारा छानिएको IPsec टनेल बनाउँछ, र क्लाइन्ट रुटहरू हस्तान्तरण गर्न कुनै इन्टरफेस हुँदैन। पोइन्ट-टु-साइट एक रुटिङ सुविधा हो: गेटवेसँग क्लाइन्ट ठेगानाको पूल हुन्छ र भर्चुअल नेटवर्कमा ती क्लाइन्टहरूका लागि रुट स्थापना गर्छ। यही असमञ्जस्य पोर्टलमा त्यो थप्ने कुनै विकल्प नदेखाउनुको कारण हो। विद्यमान गेटवेमा इन्टरफेस बनाउन टगल गर्न सकिने केही छैन, त्यसैले परिवर्तन कन्फिगरेसन सम्पादन होइन, प्रतिस्थापन हो।
व्यक्तिगत चरणहरूभन्दा क्रम बढी महत्त्वपूर्ण छ। क्रम गलत भएमा साइट-टु-साइट अवरोध मर्मत विन्डोभन्दा पर जान्छ।
नीति-आधारित गेटवेले वास्तवमा के गर्छ
नीति-आधारित गेटवेले प्याकेटहरूलाई जडानमा कन्फिगर गरिएका ट्राफिक चयनकर्ताहरूसँग मिलाउँछ र मिल्नेहरूलाई एउटै टनेलमा पठाउँछ। ठेगानासहितको टनेल इन्टरफेस हुँदैन, र भर्चुअल नेटवर्कमा कतै पनि प्रति-क्लाइन्ट रुट देखिँदैन। रुट तालिकाले गेटवेतर्फ देखाउने स्थानीय प्रिफिक्सहरू मात्र प्राप्त गर्छ। दुई स्थिर ठेगाना स्थानहरूबीचको साइट-टु-साइट जडानका लागि यो मोडेल पर्याप्त छ।
रुट-आधारित गेटवे उल्टो काम गर्छ: यसले टनेल इन्टरफेस प्रस्तुत गर्छ, र त्यसमा के प्रवेश गर्ने भन्ने रुटहरूले निर्धारण गर्छन्। पोइन्ट-टु-साइट, र सहकर्मीहरूको समूह बदलिने कुनै पनि डिजाइन, त्यो इन्टरफेस हुनुमा निर्भर छ।
क्लाइन्ट पूललाई त्यो इन्टरफेस किन चाहिन्छ
ल्यापटप जोडिँदा गेटवेले त्यसलाई पोइन्ट-टु-साइट पूलबाट ठेगाना दिन्छ। त्यसपछि भर्चुअल नेटवर्कलाई यो ठेगाना गेटवेमार्फत पुग्न सकिने भनी बताउने रुट चाहिन्छ। टनेल इन्टरफेस बिना त्यो रुट जोड्न केही हुँदैन।
पूल तपाईंले तोक्नुभएको दायराबाट आउँछ, र गेटवे त्यहाँबाट बाँडफाँट गर्छ। यदि त्यो दायरा स्थानीय नेटवर्क वा पियर गरिएको भर्चुअल नेटवर्कसँग ओभरल्याप हुन्छ भने द्वन्द्व क्लाइन्ट जोडिएपछि मात्र देखिन्छ, जुन यो पत्ता लगाउन नराम्रो समय हो। स्थानान्तरण सुरु हुनुअघि पूल आरक्षित गर्नुहोस्।
प्रकार पनि प्रति-जडान सेटिङ होइन। एउटा गेटवेको एउटै प्रकार हुन्छ, र यसले राख्ने हरेक जडान त्यसैअनुसार व्यवहार गर्छ, त्यसैले मिश्रित डिजाइनलाई दोस्रो जडान होइन, दोस्रो गेटवे चाहिन्छ।
प्रकार सिर्जनाको समयमै निश्चित हुन्छ
Microsoft भन्छ कि भर्चुअल नेटवर्क गेटवेलाई तैनाथीपछि नीति-आधारित र रुट-आधारितबीच परिवर्तन गर्न सकिँदैन। रूपान्तरण आदेश वा पोर्टलमा टगल छैन। एउटै सबनेटमा दोस्रो गेटवे बनाउनु पनि वैकल्पिक उपाय होइन, किनकि Azure प्रति भर्चुअल नेटवर्क एउटा गेटवे अनुमति दिन्छ। त्यसैले स्थानान्तरण भनेको हटाउनु, फेरि बनाउनु र फेरि जोड्नु हो।
यसले SKU को निर्णय पनि उही निर्माणमा समावेश गर्छ। पछि ठूलो SKU मा जानु अर्को अवरोधसहितको अर्को गेटवे प्रतिस्थापन हो।
एउटा गेटवे, एउटा GatewaySubnet
गेटवे GatewaySubnet नामक सबनेटमा बस्छ, र त्यसलाई एउटा मात्र गेटवे ओगट्छ। त्यो सबनेटको आकार निर्धारण तयारीको भाग हो, किनकि ठूलो SKU लाई बढी ठेगाना चाहिन्छ र सबनेट पछि सानो गर्न सकिँदैन। केही पनि छुनुअघि हालको साइट-टु-साइट सेटिङ, साझा कुञ्जी, स्थानीय नेटवर्क गेटवे र प्रभावकारी रुटहरू अभिलेख गर्नुहोस्। त्यसपछि विन्डोलाई अवरोध मान्नुहोस्, किनकि नयाँ जडान कन्फिगर नभएसम्म साइट-टु-साइट टनेल बन्द रहन्छ।
अवरोध सीमित राख्ने पुनर्निर्माण क्रम: रुट-आधारित गेटवे बनाउनुहोस्, उही स्थानीय नेटवर्क गेटवेमा साइट-टु-साइट जडान फेरि बनाउनुहोस्, टनेल र एउटा होस्ट-टु-होस्ट अनुरोध पुष्टि गर्नुहोस्, र त्यसपछि मात्र पोइन्ट-टु-साइट थपेर नयाँ क्लाइन्ट प्याकेज बनाउनुहोस्।
प्रतिस्थापनले के सुधार्दैन
दोस्रो सीमा Azure को होइन, सहकर्मीको हो। नीति-आधारित स्थानीय उपकरणले आफू जोडिएको भर्चुअल नेटवर्कमा मात्र पुग्न सक्छ, र उही गेटवेबाट अन्य स्थानीय नेटवर्क वा अन्य भर्चुअल नेटवर्कमा जान सक्दैन। Azure पक्ष प्रतिस्थापन गर्दा सहकर्मीले के छान्न सक्छ भन्ने परिवर्तन हुँदैन।
यदि आवश्यकता साँच्चै साइटहरूबीचको पारवहन हो भने, उत्तर रुट-आधारित सहकर्मी उपकरण वा प्रत्येक गन्तव्य छुट्टै अन्त्य हुने टोपोलोजी हो। मिति वाचा गर्नुअघि यो टुङ्गो लगाउनुहोस्, किनकि गेटवे प्रतिस्थापन मात्रले त्यो दिँदैन।
कार्य र जाँचको क्रम
हरेक क्षमता छुट्टै प्रमाणित गर्नुहोस्। पहिले साइट-टु-साइट टनेलको स्थिति र एउटा होस्ट-टु-होस्ट अनुरोध, त्यसपछि पोइन्ट-टु-साइट जडान र एउटा निजी स्रोत, त्यसपछि डिजाइनले दाबी गर्ने कुनै पनि पारवहन मार्ग। हरियो गेटवे स्थितिले सुरक्षा सम्बन्ध माथि आयो भन्ने मात्र प्रमाणित गर्छ, त्यसभन्दा बढी होइन। जाँचहरू त्यही क्रममा राख्नुहोस् ताकि असफलताले त्यो ल्याउने चरणतर्फ सङ्केत गरोस्।
कुनै पनि टोपोलोजी परिवर्तनपछि क्लाइन्ट प्याकेज फेरि बनाउनुहोस्, र पूललाई हरेक स्थानीय र पियर गरिएको दायराबाट टाढा राख्नुहोस्। सीमा र SKU भिन्नताहरू Azure VPN Gateway सेटिङ सन्दर्भमा सङ्कलित छन्।