दो शाखाओं के बीच ट्रैफ़िक को Azure VPN गेटवे से रूट करें
एक Azure VPN गेटवे पर दो साइट-टू-साइट कनेक्शन शाखाओं का ट्रैफ़िक पार कर सकते हैं, लेकिन केवल तब जब दोनों सिरे प्रीफ़िक्स सीखें और LAN में वापसी पथ मौजूद हो।
दो शाखाएँ आपस में किसी सीधी सुरंग के बिना Azure VPN गेटवे के ज़रिए ट्रैफ़िक का आदान-प्रदान कर सकती हैं। हर शाखा उसी गेटवे से एक साइट-टू-साइट कनेक्शन खोलती है, और गेटवे सीखे गए प्रीफ़िक्स को दोनों कनेक्शनों के बीच पास करता है। यह काम करता है दूसरी सुरंग से नहीं, बल्कि रूट के आदान-प्रदान से: शाखा A को शाखा B का प्रीफ़िक्स सीखना होता है, और B को A का। नीचे दिए जाँचों को क्रम से पूरा करें और पहली असफल जाँच पर रुकें, क्योंकि हर आगे का चरण उस पर निर्भर करता है।
पूर्व शर्तें, कुछ भी कॉन्फ़िगर करने से पहले
चार शर्तें तय करती हैं कि यह डिज़ाइन आख़िर काम कर सकता है या नहीं। गेटवे रूट-आधारित होना चाहिए और ऐसे SKU पर होना चाहिए जो BGP का समर्थन करे, दोनों कनेक्शनों पर BGP सक्षम होना चाहिए, शाखाओं के पता-स्थान ओवरलैप नहीं होने चाहिए, और कोई भी पक्ष अपना असली प्रीफ़िक्स छिपाने के लिए NAT पर निर्भर नहीं हो सकता।
ASN की योजना जानबूझकर बनाएँ। Azure का प्रलेखित डिफ़ॉल्ट 65515 है, और हर शाखा राउटर को अपना निजी ASN चाहिए जो गेटवे या दूसरी शाखा से टकराए नहीं। मौजूदा गेटवे कॉन्फ़िगरेशन जाँचे बिना डिफ़ॉल्ट का दोबारा उपयोग करना वही तरीका है जिससे बाद में AS पथ अस्वीकार हो जाता है।
यह भी पुष्टि करें कि आप VNet पियरिंग व्यवहार की अपेक्षा नहीं कर रहे हैं। गेटवे उन दो कनेक्शनों के बीच रूट का आदान-प्रदान करता है जिन्हें आपने कॉन्फ़िगर किया; यह मनमाने पियरिंग को पारगम्य नहीं बनाता। अगर किसी तीसरे नेटवर्क को दोनों शाखाओं तक पहुँचना है, तो उसे अपना कनेक्शन या अपना रूट पथ चाहिए, यह मान नहीं कि गेटवे ट्रैफ़िक बाँट देगा। पहली बदलाव विंडो से पहले वह सीमा लिख लें, क्योंकि बाद में साइट जोड़े जाने पर लोग उसी डिज़ाइन निर्णय पर लौटते हैं।
इस क्रम में कॉन्फ़िगर करें
हर चरण का एक देखने योग्य परिणाम है, इसलिए वह दिखने तक आगे न बढ़ें।
- वर्चुअल नेटवर्क गेटवे पर BGP सक्षम करें और उसका ASN तथा पीयर पता नोट करें।
- हर शाखा के लिए उस शाखा के असली पता-स्थान, उसके ASN और उसके BGP पीयर पते के साथ एक स्थानीय नेटवर्क गेटवे बनाएँ।
- हर साइट-टू-साइट कनेक्शन बनाएँ और कनेक्शन पर ही BGP सक्षम करें।
- शाखा राउटर को Azure द्वारा दिए गए गेटवे पते के साथ पीयर करने के लिए कॉन्फ़िगर करें, अनुमान के आधार पर गेटवे के सार्वजनिक IKE एंडपॉइंट के साथ नहीं।
चौथा चरण वह जगह है जहाँ ज़्यादातर प्रयास अटकते हैं। Azure जो BGP पीयर पता बताता है वही शाखा राउटर को पड़ोसी के रूप में उपयोग करना होता है, और यह हमेशा वह पता नहीं होता जिसकी लोग सुरंग आरेख से अपेक्षा करते हैं।
शाखा का प्रीफ़िक्स ही विज्ञापित करें, उदाहरण के लिए A से 10.10.0.0/16 और B से 10.20.0.0/16। किसी गुम विशिष्ट नेटवर्क को ढकने के लिए डिफ़ॉल्ट रूट या चौड़ा एग्रीगेट विज्ञापित न करें; अंतराल बाद में एक शांत ब्लैकहोल के रूप में लौटता है।
दोनों सिरों पर रूट का आदान-प्रदान सत्यापित करें
कनेक्शन स्थिति जाँच नहीं है। दोनों कनेक्शनों पर IPsec ऊपर हो सकता है जबकि उनके बीच कोई प्रीफ़िक्स न गुज़रे। गेटवे के BGP पीयर और उसके सीखे गए रूट पढ़ें, फिर पुष्टि करें कि दूसरी शाखा की ओर का रूट एक उपयोगी पथ के रूप में दिखता है।
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
BGP तालिका में मौजूद प्रीफ़िक्स अभी भी किसी स्थिर रूट या अधिक विशिष्ट प्रीफ़िक्स के सामने फ़ॉरवर्डिंग निर्णय हार सकता है। केवल प्राप्त रूट नहीं, चयनित रूट जाँचें।
LAN की ओर वापसी पथ का पालन करें
यह वह हिस्सा है जो Azure में सही दिखता है और साइट पर विफल हो जाता है। शाखा A का एक होस्ट अपना पैकेट A के VPN राउटर को तभी भेजता है जब वह राउटर उसका डिफ़ॉल्ट गेटवे हो, या होस्ट या उसके गेटवे के पास B के प्रीफ़िक्स के लिए रूट हो। दूसरी दिशा में भी यही सच होना चाहिए।
अगर कोई अलग कोर स्विच LAN का डिफ़ॉल्ट गेटवे है, तो उसे दूसरी शाखा की ओर वह रूट चाहिए जो VPN राउटर की ओर इशारा करे। उसके बिना अनुरोध आता है और उत्तर इंटरनेट पथ से निकल जाता है, और उपयोगकर्ता को ऐसा कनेक्शन दिखता है जो खुलता है और फिर अटक जाता है।
इसे ठीक करने के लिए गेटवे सबनेट पर नेटवर्क सुरक्षा समूह की ओर न जाएँ। उस सबनेट की अपनी आवश्यकताएँ हैं और वहाँ NSG शाखा-पक्ष की नीति का समर्थित विकल्प नहीं है। फ़िल्टरिंग शाखाओं के फ़ायरवॉल और स्वयं वर्कलोड पर होनी चाहिए, जहाँ मालिक नियमों की समीक्षा कर सकें। उन नियमों को सबनेट NSG में ले जाने से वे उस टीम से भी छिप जाते हैं जो अगली खराबी को डीबग करेगी।
संचालन की अनुमति दें, फिर अस्वीकृत परीक्षण से साबित करें
सीखा गया रूट अनुमति नहीं है। जो स्रोत, गंतव्य और सेवा आपको वास्तव में चाहिए उसे शाखाओं के फ़ायरवॉल और एंडपॉइंट नीति से अनुमति दें, और बाकी अस्वीकृत रहने दें।
शाखा A के सामान्य वर्कलोड से शाखा B की असली सेवा तक परीक्षण करें, उत्तर की पुष्टि करें, फिर ऐसा संचालन आज़माएँ जो निषिद्ध रहना चाहिए। VPN उपकरण स्वयं जो ट्रैफ़िक बनाता है वह अलग स्रोत पता उपयोग कर सकता है और LAN रूटिंग चरण छोड़ सकता है, इसलिए राउटर से सफल ping दिखने से कम साबित करता है।
चार तथ्य लिखकर समाप्त करें: आदान-प्रदान किए गए प्रीफ़िक्स, उपयोग किए जा रहे ASN, हर पक्ष के लिए LAN वापसी पथ, और वह नीति जो सेवा की अनुमति देती है। अगर इनमें से एक भी गुम हो, तो सेटअप पहले बदलाव तक काम करता है, और फिर कोई नहीं समझा सकता कि क्यों।