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