दुई शाखाबीचको ट्राफिक Azure VPN गेटवेमार्फत रुट गर्नुहोस्
एउटै Azure VPN गेटवेमा दुई साइट-टू-साइट जडानले शाखाहरूको ट्राफिक पार गर्न सक्छन्, तर दुवै छेउले प्रिफिक्स सिकेको र LAN फिर्ता मार्ग भएको खण्डमा मात्र।
दुई शाखाले आफूबीच कुनै सीधा सुरुङ नभई Azure VPN गेटवेमार्फत ट्राफिक आदानप्रदान गर्न सक्छन्। प्रत्येक शाखाले उही गेटवेमा साइट-टू-साइट जडान खोल्छ, र गेटवेले सिकेका प्रिफिक्सहरू दुई जडानबीच पास गर्छ। यसलाई काम गराउने दोस्रो सुरुङ होइन, रुटको आदानप्रदान हो: शाखा A ले शाखा B को प्रिफिक्स सिक्नुपर्छ, र B ले A को। तलका जाँचहरू क्रममा गर्नुहोस् र पहिलो असफल जाँचमै रोक्नुहोस्, किनकि हरेक पछिल्लो चरण त्यसमा निर्भर छ।
केही पनि कन्फिगर गर्नुअघि पूर्वशर्तहरू
यो डिजाइन आखिर काम गर्न सक्छ कि सक्दैन भन्ने चार सर्तले निर्धारण गर्छ। गेटवे रुट-आधारित हुनुपर्छ र BGP समर्थन गर्ने SKU मा हुनुपर्छ, दुवै जडानमा BGP सक्रिय हुनुपर्छ, शाखाहरूको ठेगाना क्षेत्र एकअर्कामा नपर्नुपर्छ, र कुनै पक्षले आफ्नो वास्तविक प्रिफिक्स लुकाउन NAT मा भर पर्नु हुँदैन।
ASN हरू जानाजान योजना गर्नुहोस्। Azure को कागजातमा उल्लेखित पूर्वनिर्धारित मान 65515 हो, र प्रत्येक शाखा राउटरलाई गेटवे वा अर्को शाखासँग नटकराउने आफ्नै निजी ASN चाहिन्छ। अहिलेको गेटवे कन्फिगरेसन जाँच नगरी पूर्वनिर्धारित मान दोहोर्याउनु नै AS मार्ग पछि अस्वीकृत हुने तरिका हो।
तपाईंले VNet पियरिङ व्यवहार अपेक्षा गर्नुभएको छैन भन्ने पनि पुष्टि गर्नुहोस्। गेटवेले तपाईंले कन्फिगर गरेका दुई जडानबीच रुट आदानप्रदान गर्छ; यसले मनपरी पियरिङलाई पारगम्य बनाउँदैन। यदि तेस्रो सञ्जालले दुवै शाखासम्म पुग्नुपर्ने भए, त्यसलाई आफ्नै जडान वा आफ्नै रुट मार्ग चाहिन्छ, गेटवेले ट्राफिक बाँड्छ भन्ने अनुमान होइन। पहिलो परिवर्तन विन्डोअघि त्यो सीमा लेखेर राख्नुहोस्, किनकि पछि साइट थपिँदा मानिसहरू यही डिजाइन निर्णयमा फर्केर आउँछन्।
यही क्रममा कन्फिगर गर्नुहोस्
हरेक चरणको अवलोकनयोग्य नतिजा हुन्छ, त्यसैले त्यो नदेखिएसम्म अगाडि नबढ्नुहोस्।
- भर्चुअल नेटवर्क गेटवेमा BGP सक्रिय गर्नुहोस् र त्यसको ASN र पियर ठेगाना नोट गर्नुहोस्।
- प्रत्येक शाखाका लागि त्यो शाखाको वास्तविक ठेगाना क्षेत्र, त्यसको ASN र BGP पियर ठेगानासहित स्थानीय नेटवर्क गेटवे बनाउनुहोस्।
- प्रत्येक साइट-टू-साइट जडान बनाउनुहोस् र जडानमै BGP सक्रिय गर्नुहोस्।
- शाखा राउटरलाई अनुमानका आधारमा गेटवेको सार्वजनिक IKE अन्त्यबिन्दुसँग होइन, Azure ले तोकेको गेटवे ठेगानासँग पियर गर्न कन्फिगर गर्नुहोस्।
चौथो चरण नै धेरैजसो प्रयास अड्किने ठाउँ हो। 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 फिर्ता मार्ग, र सेवालाई अनुमति दिने नीति। यीमध्ये एउटा पनि हराएमा सेटअप पहिलो परिवर्तनसम्म काम गर्छ, र त्यसपछि कसैले किन भनी बुझाउन सक्दैन।