क्या पीयर किए गए Azure VNet को अपना VPN गेटवे चाहिए?
पीयर किया गया VNet समर्थित SKU और peering की हर दिशा में एक सेटिंग के साथ hub के VPN गेटवे का उपयोग कर सकता है। peering स्थिति नहीं, प्रभावी मार्ग जाँचें।
एक नया spoke VNet सामने आता है, hub के पास पहले से एक काम करने वाला site-to-site गेटवे है, और स्पष्ट सवाल यह है कि क्या आपको दूसरे गेटवे के लिए भुगतान करना होगा। आमतौर पर नहीं: गेटवे ट्रांज़िट spoke को peering के ज़रिए hub के गेटवे का उपयोग करने देता है। तीन शर्तें तय करती हैं कि यह काम करेगा या नहीं, और उनमें से कोई भी peering स्थिति बैज से दिखाई नहीं देती। peering कनेक्टिविटी और किसी और के गेटवे का उपयोग करने की अनुमति अलग-अलग सेटिंग्स हैं, इसलिए दो VM जो पहले से एक-दूसरे को ping कर सकते हैं, 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, या एक निजी एंडपॉइंट, जोड़ने से उसकी अपनी रूटिंग और एक्सेस आवश्यकताएँ आती हैं जिन्हें मौजूदा ट्रांज़िट सेटिंग कवर नहीं करती।