के पियर गरिएको Azure VNet लाई आफ्नै VPN गेटवे चाहिन्छ?
पियर गरिएको VNet ले समर्थित SKU र प्रत्येक पियरिङ दिशामा एउटा सेटिङसँग हबको VPN गेटवे प्रयोग गर्न सक्छ। पियरिङ स्थिति होइन, प्रभावकारी मार्गहरू जाँच्नुहोस्।
एउटा नयाँ spoke VNet देखा पर्छ, hub सँग पहिले नै काम गर्ने site-to-site गेटवे छ, र स्पष्ट प्रश्न यो हो कि दोस्रो गेटवेका लागि तपाईंले तिर्नुपर्ने हो कि होइन। सामान्यतया पर्दैन: गेटवे ट्रान्जिटले spoke लाई peering मार्फत hub को गेटवे प्रयोग गर्न दिन्छ। यो काम गर्छ कि गर्दैन भन्ने तीन सर्तले निर्धारण गर्छ, र तीमध्ये कुनै पनि peering स्थिति ब्याजबाट देखिँदैन। peering कनेक्टिभिटी र अरू कसैको गेटवे प्रयोग गर्ने अनुमति छुट्टै सेटिङहरू हुन्, त्यसैले पहिले नै एकअर्कालाई ping गर्न सक्ने दुई VM ले VPN मार्गबारे केही पनि प्रमाणित गर्दैनन्।
पहिलो सर्त: गेटवे, र spoke मा त्यसको अभाव
Azure ले Basic बाहेक अन्य VPN Gateway SKU का लागि गेटवे ट्रान्जिट समर्थन गर्छ, र क्षेत्रीय तथा विश्वव्यापी दुवै peering ले यसलाई बोक्न सक्छन्। spoke ले आफ्नो नभएको गेटवे उपभोग गर्छ, त्यसैले आफ्नै गेटवे हुन सक्दैन: यदि spoke मा पहिले नै गेटवे छ, वा टाढाको गेटवे विकल्प पहिले नै चयन गरिएको छ, तपाईंले चाहेको ट्रान्जिट सेटिङ उपलब्ध हुँदैन वा प्रभावकारी हुँदैन। केही पनि डिबग गर्नु अघि यो जाँच्नुहोस्, किनकि निष्क्रिय चेकबक्स लक्षण हो, त्रुटि होइन। पहिले SKU र भएको गेटवे पढ्नुहोस्, त्यसपछि peering सेटिङहरू हेर्नुहोस्।
विकल्प देखिनका लागि भएको spoke गेटवेमा के निर्भर छ भन्ने थाहा नभएसम्म नमेट्नुहोस्। माइग्रेसन क्रम चेकबक्सभन्दा महत्त्वपूर्ण छ।
दोस्रो सर्त: प्रत्येक peering दिशामा एक सेटिङ
peering दुई वस्तु हुन्, प्रत्येक VNet मा एक, र ट्रान्जिट सेटिङहरू त्यो जोडीको फरक फरक पट्टिमा बस्छन्। hub बाट spoke तर्फको peering ले hub गेटवेलाई spoke को सेवा गर्न अनुमति दिनुपर्छ; spoke बाट hub तर्फको peering ले hub को गेटवे स्वीकार गर्नुपर्छ। Microsoft को गेटवे-ट्रान्जिट निर्देशिका ले तिनीहरूलाई दिशा अनुसार नाम दिन्छ, र तिनलाई सही राख्ने यही एक मात्र तरिका हो:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
remote लेबल भएको नियन्त्रणले तपाईं कुन VNet को peering सम्पादन गर्दै हुनुहुन्छ भन्ने आधारमा अर्थ बदल्छ, त्यसैले शब्द होइन, दिशा पढ्नुहोस्। दुवै पक्ष सेट गर्नुहोस्, सुरक्षित गर्नुहोस् र peering दुवै ठाउँमा जोडिएको रूपमा रिपोर्ट गर्छ भनी पुष्टि गर्नुहोस्।
तेस्रो सर्त: ठेगाना स्थान र अनुमति सीमाहरू
ट्रान्जिटले एउटै गन्तव्य प्रिफिक्सलाई दुई नेटवर्कको अर्थ दिन सक्दैन, त्यसैले hub, spoke र स्थानीय नेटवर्कका दायराहरू यीमध्ये केही पनि काम गर्नु अघि अलग हुनुपर्छ। VNet हरू फरक सदस्यताहरू वा फरक भाडावालहरूमा पनि हुन सक्छन्; त्यो निषेध होइन, तर प्रत्येक peering सिर्जना वा अद्यावधिक गर्ने पहिचानसँग त्यो नेटवर्कमा आवश्यक अनुमतिहरू हुनुपर्छ। सदस्यताहरू बीचका परिवर्तनहरू प्रायः अनुमतिमा असफल हुन्छन्, र त्रुटिलाई टोपोलोजी समस्या रूपमा गलत पढ्न सजिलो छ।
परिवर्तन अघि दायराहरू र मालिकहरू लेख्नुहोस्। दुवैमध्ये कुनैमा अनुमान गर्दा जोडिने तर केही पनि रुट नगर्ने peering बन्छ।
peering स्थितिले होइन, प्रभावकारी मार्गहरूले प्रमाणित गर्नुहोस्
spoke वर्कलोडको नेटवर्क इन्टरफेसमा प्रभावकारी मार्गहरू हेर्नुहोस् र वास्तविक स्थानीय प्रिफिक्स पत्ता लगाउनुहोस्। सबनेटको रुट तालिका र गेटवे रुट प्रसार निष्क्रिय छ कि जाँच्नुहोस्, किनकि प्रयोगकर्ता-परिभाषित रुट वा निरीक्षण उपकरणले peering फ्ल्यागहरूले सुझाएको मार्गलाई उल्लंघन गर्न सक्छ। त्यसपछि अर्को दिशा पुष्टि गर्नुहोस्: स्थानीय नेटवर्कले site-to-site जडानमार्फत spoke प्रिफिक्ससम्म पुग्ने तरिका जान्नुपर्छ, त्यो सिकेका विज्ञापनहरूद्वारा होस् वा स्पष्ट रुट र ग्राहक उपकरणमा मिल्ने सुरक्षित-नेटवर्क प्रविष्टिद्वारा। कुनै पनि पट्टिमा प्रिफिक्स छैन भने, परिवर्तन गर्नुपर्ने कुरा peering फ्ल्यागहरू होइनन्।
spoke वर्कलोडबाट एउटा सेवा परीक्षण गर्नुहोस् र प्रतिक्रिया पछ्याउनुहोस्। VPN गेटवे वा hub VM बाट परीक्षणले फरक स्रोत प्रिफिक्स र फरक मार्ग प्रयोग गर्छ।
यदि टोपोलोजीले point-to-site ग्राहकहरूलाई पनि सेवा दिन्छ भने, तिनका स्थापित मार्गहरू छुट्टै प्रमाणित गर्नुहोस्। टोपोलोजी परिवर्तन पछि Windows ग्राहक प्याकेजहरू पुनः उत्पन्न गर्न आवश्यक हुन सक्छ, र यो गेटवे साझेदारी असफल भएको प्रमाण होइन, ग्राहक रुटिङको काम हो।
गेटवे साझा गर्नाले के दिँदैन
गेटवे ट्रान्जिट रुटिङ सुविधा हो, अधिकार होइन। नेटवर्क सुरक्षा समूह, स्थानीय फिल्टर र सेवा-स्तरीय नियमहरूले अझै spoke वर्कलोड कहाँसम्म पुग्न सक्छ भन्ने निर्धारण गर्छन्, त्यसैले साझा टनेलले यसको पछाडिको सबै कुरा अनुमति दिन्छ भन्ने मान्नुको सट्टा विशिष्ट स्रोत-देखि-गन्तव्य सेवा सक्षम गर्नुहोस्।
peering पनि मानिसहरूले आशा गरेजस्तो पारगम्य छैन। अर्को spoke वा निजी एन्डप्वाइन्ट थप्दा यसको आफ्नै रुटिङ र पहुँच आवश्यकताहरू आउँछन् जुन विद्यमान ट्रान्जिट सेटिङले समेट्दैन।