Azure VPN प्रीफ़िक्स जोड़ने से कनेक्शन क्यों टूटता है

गलत Azure ऑब्जेक्ट पर जोड़ा गया प्रीफ़िक्स ऐसा कनेक्शन बनाता है जो Connected बताता है और कुछ भी आगे नहीं भेजता, और यह इस स्टैक में सबसे महँगी ग़लती है। इसमें तीन संसाधन शामिल हैं और उनमें से केवल एक के पास दूरस्थ पता स्थान है: वर्चुअल नेटवर्क गेटवे, दूरस्थ पक्ष का वर्णन करने वाला स्थानीय नेटवर्क गेटवे, और उन्हें जोड़ने वाला कनेक्शन। प्रीफ़िक्स स्थानीय नेटवर्क गेटवे का है, बदलाव लागू होने के लिए कनेक्शन को फिर से बनाना पड़ता है, और गेटवे स्वयं सामान्यतः अछूता रहता है। क्रम पर बातचीत नहीं हो सकती, और पोर्टल उसका केवल एक हिस्सा दिखाता है।

तीन ऑब्जेक्ट, जिनमें से एक प्रीफ़िक्स रखता है

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

एक तीसरा आरक्षण भी है जिसे ध्यान में रखना चाहिए। GatewaySubnet प्रबंधित गेटवे इंस्टेंस होस्ट करता है, ठीक यही नाम रखना चाहिए, और गैर-Basic SKU के लिए यह अपेक्षित है कि यह कम से कम /27 हो।

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

कनेक्शन ही क्यों हटाया जाता है

कनेक्शन ऑब्जेक्ट अपने पूरे जीवनकाल के लिए तय की गई कॉन्फ़िगरेशन को स्थिर रखता है। इसलिए दस्तावेज़ीकृत प्रक्रिया पहले कनेक्शन हटाती है, स्थानीय नेटवर्क गेटवे को अद्यतन करती है, और फिर उसी साझा कुंजी के साथ कनेक्शन दोबारा बनाती है। केवल प्रीफ़िक्स बदलाव के लिए गेटवे इंस्टेंस दोबारा नहीं बनाए जाते, जिससे व्यवधान गेटवे को फिर से तैनात करने के बजाय कनेक्शन तोड़ने तक सीमित रहता है।

वह हटाना ही व्यवधान है, इसलिए इसे त्वरित संपादन के बजाय आरंभ और अपेक्षित अंत वाले नियोजित बदलाव के रूप में लें। PowerShell में क्रम छोटा है: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, फिर Set-AzLocalNetworkGateway नए -AddressPrefix सरणी के साथ, फिर New-AzVirtualNetworkGatewayConnection उसी -SharedKey और उन्हीं गेटवे के साथ। कुंजी का पुनः उपयोग महत्वपूर्ण है, क्योंकि दूरस्थ पक्ष को फिर से कॉन्फ़िगर नहीं किया जा रहा है और नई कुंजी का अर्थ है दूरस्थ डिवाइस के मालिक के साथ समन्वय। यदि कोई दूसरी टीम उस डिवाइस को चलाती है, तो कुछ भी हटाने से पहले उनके साथ समय-खिड़की तय करें।

गेटवे को ही कब दोबारा बनाना पड़ता है

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

पॉइंट-टू-साइट के लिए बनाए गए गेटवे को सीधे साइट-टू-साइट कनेक्शन नहीं दिया जा सकता। पॉइंट-टू-साइट कॉन्फ़िगरेशन हटाना पड़ता है और गेटवे दोबारा बनाना पड़ता है, जिससे नई साझा कुंजी और नया क्लाइंट पैकेज भी बनता है।

पॉइंट-टू-साइट पैकेज अपना अलग नोट रखता है क्योंकि वह समाप्त हो जाता है। पोर्टल कम जीवनकाल वाली फ़ाइल बनाता है, इसलिए व्यावहारिक तरीका यह है कि उसे एक बार डाउनलोड करें और क्लाइंट प्रमाणपत्र के साथ वितरित करें, न कि उपयोगकर्ताओं को पोर्टल लिंक भेजें जो उनके क्लिक करने तक मृत होगा। प्रीफ़िक्स के प्रश्न पर इसमें से कुछ भी लागू नहीं होता। दोनों प्रक्रियाओं को अलग रखना ही पूरा अनुशासन है: प्रीफ़िक्स कनेक्शन-स्तर का बदलाव हैं, और गेटवे के गुण गेटवे-स्तर का बदलाव हैं।

स्थिति पढ़ें, पोर्टल का बैज नहीं

स्थिति संसाधन से पढ़ें, पोर्टल के बैज से नहीं। Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 लौटाता है ConnectionStatus इनग्रेस और एग्रेस बाइट काउंटर के साथ, और काउंटर ही जुड़े हुए पर कुछ न ले जाने वाले टनल को कभी स्थापित न हुए टनल से अलग करते हैं।

जो काउंटर स्थानांतरण के बीच बढ़ना बंद कर देते हैं, वे प्रमाणीकरण के बजाय पथ की ओर संकेत करते हैं. जो काउंटर बिलकुल नहीं हिलते वे प्रीफ़िक्स सेट या साझा कुंजी की ओर संकेत करते हैं।

टाइमर डिस्कनेक्ट के एक वर्ग को समझाते हैं जिसे ग़लती से VPN पर मढ़ा जाता है। Azure का लोड बैलेंसर अपने निर्धारित टाइमआउट के बाद निष्क्रिय फ़्लो बंद कर देता है, इन नोट्स के लिखे जाने के समय डिफ़ॉल्ट चार मिनट और ऊपर की ओर कॉन्फ़िगर करने योग्य, इसलिए keepalive के बिना VM पर OpenVPN सर्वर हर कुछ मिनट में गिर सकता है जबकि बाकी सब कुछ स्वस्थ दिखता है। जिस गेटवे को प्लेटफ़ॉर्म चक्रीय रूप से पुनः आरंभ करता है वह भी VNet कनेक्शन को Web App से बाधित कर सकता है, और वह विफलता क्लाइंट कॉन्फ़िगरेशन में नहीं, प्लेटफ़ॉर्म की ओर है। संकेत यह है कि डिस्कनेक्ट निश्चित अंतराल का पालन करता है या आपके किए बदलाव का।

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

फिर उसी क्रम में जाँचें जिसमें आपने बदला: स्थानीय नेटवर्क गेटवे नई प्रीफ़िक्स सूची दिखाता है, कनेक्शन फिर Connected है, और नई रेंज के होस्ट पर ट्रैफ़िक भेजने पर काउंटर हिलते हैं। यदि पहले दो पास होने पर तीसरा चरण विफल हो, तो दूरस्थ पक्ष ने नया ट्रैफ़िक चयनकर्ता स्वीकार नहीं किया है और दूरस्थ डिवाइस को मेल खाती चरण 2 प्रविष्टि चाहिए। यह टनल के दूसरे सिरे से बातचीत है, Azure में एक और बदलाव नहीं।