दोन शाखांमधील रहदारी 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 परतीचा मार्ग, आणि सेवेला परवानगी देणारे धोरण। यातले एकही गायब असल्यास सेटअप पहिल्या बदलापर्यंत चालतो, आणि नंतर कोणीही का ते सांगू शकत नाही।