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 मा अर्को परिवर्तन होइन।