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 मधील आणखी एक बदल नाही.