पीअर केलेल्या 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 किंवा खाजगी एंडपॉइंट जोडल्यास विद्यमान ट्रान्झिट सेटिंग कव्हर करत नसलेल्या स्वतःच्या राउटिंग आणि प्रवेश आवश्यकता येतात।