NVA के बिना ExpressRoute पर Azure निजी IP VPN

मिथक यह है कि ExpressRoute निजी peering पर ट्रैफ़िक को एन्क्रिप्ट करने के लिए नेटवर्क वर्चुअल उपकरण आवश्यक है। ऐसा नहीं है। Azure एक Site-to-Site VPN Gateway का समर्थन करता है जिसका सुरंग एंडपॉइंट सर्किट के माध्यम से ले जाया गया निजी RFC1918 पता है, और उपकरण संरचनात्मक नहीं बल्कि वैकल्पिक है। उपकरण का मिथक जो छिपाता है वह वह हिस्सा है जो वास्तव में चुभता है: निजी एंडपॉइंट को दो के बजाय एक ऑब्जेक्ट पर सक्षम करना, और सीधे peering मार्ग को चुपचाप एन्क्रिप्टेड पथ पर जीतने देना।

मिथक कहाँ से आया

इस दावे की जड़ें सम्मानजनक हैं। वर्षों तक निजी peering पर IPsec का व्यावहारिक नुस्खा NVA था, क्योंकि प्रबंधित गेटवे केवल सार्वजनिक एंडपॉइंट उजागर करता था। वह बदल गया, और बदलाव से पहले लिखे गए उत्तर आज भी ऐसे थ्रेड में उद्धृत होते हैं जहाँ कोई तारीख नहीं जाँचता। सुधार सीमित है: निजी पते वाला VPN गेटवे मौजूद है, और वह एंडपॉइंट बदलता है, उसके आसपास का राउटिंग तर्क नहीं।

इनमें से कोई भी NVA को सेवानिवृत्त नहीं करता। यह उस धारणा को सेवानिवृत्त करता है कि उपकरण आवश्यकता तक पहुँचने का एकमात्र रास्ता है।

दोनों स्तरों पर निजी एंडपॉइंट सक्षम करें

VPN गेटवे वाले VNet से जुड़े काम कर रहे ExpressRoute निजी peering कनेक्शन से शुरू करें। ऑन-प्रिमाइज़ पक्ष को पहले से ही उस सर्किट के माध्यम से प्रासंगिक निजी पतों तक पहुँचना चाहिए, क्योंकि सुरंग उन पतों को परिवहन के रूप में उपयोग करेगी। फिर गेटवे की पूर्व शर्त: निजी-IP VPN के लिए Microsoft की प्रक्रिया के लिए Standard सार्वजनिक IP संसाधन पर बना गेटवे आवश्यक है। निजी सुरंग एड्रेसिंग उस शर्त को नहीं हटाती, जिससे वे लोग आश्चर्यचकित होते हैं जो मानते हैं कि „निजी“ का अर्थ „कहीं भी सार्वजनिक IP नहीं“ है।

अब दोनों जगह फ़्लैग सक्षम करें। गेटवे कॉन्फ़िगरेशन का निजी IP के लिए अपना स्विच है, और अलग Site-to-Site कनेक्शन का दूसरा है जो उस कनेक्शन को निजी पता उपयोग करवाता है। एक सेट करना और दूसरा न करना सबसे आम अधूरा कॉन्फ़िगरेशन है; सुरंग या तो बनती नहीं या गलत एंडपॉइंट पर बनती है।

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

अपने इंस्टॉल किए गए CLI संस्करण के सामने प्रॉपर्टी नाम सत्यापित करें, क्योंकि पोर्टल लेबल और CLI प्रॉपर्टी का शब्दांकन हमेशा एक जैसा नहीं होता। एक सक्रिय-सक्रिय गेटवे दो निजी सुरंग पते उजागर करता है, और ऑन-प्रिमाइज़ डिवाइस में दोनों पीयर कॉन्फ़िगर होने चाहिए यदि आप चाहते हैं कि वह अनावश्यकता कुछ मायने रखे। केवल इस निजी-पते वाली सुरंग को उठाने के लिए BGP आवश्यक नहीं है, हालाँकि यह आमतौर पर प्रीफ़िक्स वितरित करने के तरीके का हिस्सा होता है।

दूसरा मिथक: स्थापित सुरंग आपका ट्रैफ़िक एन्क्रिप्ट करती है

अब एप्लिकेशन नेटवर्क तक दो रास्ते पहुँचते हैं: सीधा निजी peering रास्ता और VPN के माध्यम से रास्ता। दोनों काम करते हैं। केवल एक ही यह IPsec परत लागू करता है। Microsoft दस्तावेज़ करता है कि जब समान प्रीफ़िक्स ExpressRoute और VPN दोनों पर घोषित होते हैं, तो Azure सीधे ExpressRoute रास्ते को प्राथमिकता देता है, इसलिए स्वस्थ सुरंग और स्वस्थ काउंटर इस बात का कुछ साबित नहीं करते कि एप्लिकेशन पैकेट कहाँ गए।

दस्तावेज़ित स्टीयरिंग विधियाँ ExpressRoute पर कवरिंग रेंज के साथ VPN पर अधिक विशिष्ट संरक्षित रेंज, या दोनों रास्तों पर असंयुक्त प्रीफ़िक्स हैं। उदाहरण के लिए, निजी peering 10.40.0.0/16 ले जा सकता है जबकि VPN 10.40.12.0/24 घोषित करता है। अधिक विशिष्ट प्रीफ़िक्स जीतता है और रेंज का बाकी हिस्सा सीधा रहता है।

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

ऑन-प्रिमाइज़ दिशा में भी वही जाँच करें, क्योंकि आपके राउटर की प्राथमिकता तय करती है कि आउटबाउंड ट्रैफ़िक किस ओर से निकलेगा। और सुरंग का अपना परिवहन ExpressRoute पथ पर रखें; जो मार्ग गेटवे के निजी एंडपॉइंट को सुरंग में खींच लेता है वह सुरंग को स्वयं पर निर्भर बना देता है।

तय करें कि सुरंग गिरने पर क्या होगा

अधिक विशिष्ट VPN मार्ग सुरंग गिरने पर गायब हो जाता है, जबकि व्यापक सीधा मार्ग रहता है। तब ट्रैफ़िक बिना एन्क्रिप्शन के बहता है और सब कुछ स्वस्थ दिखता है, जो ऐसी आवश्यकता के लिए सबसे बुरा विफलता मोड है जो एन्क्रिप्शन की गारंटी के लिए मौजूद है। यदि आवश्यकता वह फ़ॉलबैक मना करती है, तो राउटिंग और एक्सेस नीति को सुरंग की उपलब्धता पर निर्भर रहने के बजाय यह स्पष्ट रूप से कहना होगा।

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

यह ढाँचा आपको NVA को उसकी वास्तविक विशेषताओं पर मूल्यांकन करने की भी सुविधा देता है, जैसे कई सुरंगें, थ्रूपुट या विक्रेता निरीक्षण, केवल इसलिए एक खरीदने के बजाय कि एंडपॉइंट निजी है।