Azure UDR ते VPN गेटवे: एक गंतव्य, संपूर्ण निर्गम नाही

तुम्ही एका बाह्य प्रीफिक्ससाठी वापरकर्ता-परिभाषित रूट जोडता, तो VPN गेटवेकडे निर्देशित करता, आणि रहदारी तरीही Azure च्या इंटरनेट मार्गाने बाहेर पडते. किंवा ती योग्यरीत्या बाहेर पडते आणि उत्तर कधीही परत येत नाही. दोन्ही निकाल एकाच चुकीतून येतात: Azure च्या पुढील हॉपला संपूर्ण रचना मानणे. रूट तक्ता फक्त ठरवतो की Azure मध्ये पॅकेट कोणता निर्गम घेतो. बोगद्यानंतर त्याचे काय होते आणि उत्तर कसे परते, हा तुम्ही बांधायचा दुसरा अर्धा भाग आहे.

पुढील हॉप एक गेटवे आहे, उपकरणाचा IP नाही

UDR जुळणारे प्रीफिक्स पुढील-हॉप प्रकाराकडे पाठवते, आणि VirtualNetworkGateway हा प्रकार आहे, पत्ता नाही. लोक गेटवेचा खाजगी IP VirtualAppliance मार्गात चिकटवतात आणि मग विचारतात की काहीही जुळत नाही का, कारण तो प्रकार त्याऐवजी NIC किंवा अंतर्गत लोड बॅलेन्सरची अपेक्षा करतो. Microsoft चे राउटिंग दस्तऐवजही गेटवेच्या पुढील हॉपला अशा व्हर्च्युअल नेटवर्कपर्यंत मर्यादित करते ज्याचा गेटवे VPN गेटवे आहे. ExpressRoute, Route Server आणि Virtual WAN हब या पर्यायाने संबोधले जात नाहीत.

मार्ग लिहिण्यापूर्वी व्हर्च्युअल नेटवर्कमध्ये प्रत्यक्षात काय आहे ते तपासा. रचना हबमार्फत राउट करत असेल, तर मार्ग हबच्या राउटिंग मालकाचा आहे, तुम्ही संपादित करत असलेल्या स्पोकचा नाही.

काहीही बदलण्यापूर्वी प्रभावी मार्ग वाचा

Azure प्रणाली मार्ग, BGP ने शिकलेले प्रीफिक्स आणि UDR एकत्र करून प्रत्येक NIC साठी प्रभावी रूट तक्ता बनवते, आणि सर्वात लांब जुळणारे प्रीफिक्स कुठूनही आले तरी जिंकते. त्याच प्रीफिक्ससाठी UDR BGP मार्गाला हरवते. याच क्रमामुळे पूर्वीच्या प्रयोगातील जुना UDR बोगद्यातून नुकतेच शिकलेल्या प्रीफिक्सवर शांतपणे मात करू शकतो.

प्रथम प्रभावी तक्ता पहा, नंतर तुम्ही मार्ग जोडत आहात की बदलत आहात ते ठरवा:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

प्रीफिक्ससोबत स्रोत स्तंभही वाचा. योग्य प्रीफिक्स आणि चुकीचा स्रोत असलेला मार्ग कोणती वस्तू संपादित करावी हे सांगतो, आणि पहिल्याकडून हरणारा दुसरा मार्ग जोडण्यापासून वाचवतो.

प्रत्यक्ष प्रीफिक्स आणि सबनेटनुसार मार्ग लिहा

फोरम पोस्टमधून कॉपी केलेल्या सार्वजनिक श्रेणीऐवजी तुम्ही प्रत्यक्षात पोहोचत असलेल्या सेवेतून घेतलेले गंतव्याचे खरे प्रीफिक्स वापरा. सर्व निर्गम हलवणाऱ्या डीफॉल्ट मार्गाचा विचार करण्यापूर्वी एका मंजूर सेवेपासून सुरुवात करा. नंतर रूट तक्ता वर्कलोड सबनेटला जोडा. गेटवे सबनेटच्या स्वतःच्या आवश्यकता आहेत, आणि तिथे तुमचा तक्ता जोडल्यास वर्कलोड निर्देशित करण्याऐवजी गेटवे तुटतो.

मार्ग तयार करा, नंतर तक्ता वर्कलोड असलेल्या सबनेटला बांधा:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

प्रसारही महत्त्वाचा. त्या तक्त्यावर BGP प्रसार सक्षम असल्यास शिकलेली प्रीफिक्स तुम्ही लिहिलेल्यांच्या शेजारी दिसतात, आणि अधिक विशिष्ट शिकलेले प्रीफिक्स मोठ्या UDR ला हरवू शकते. प्रसार केवळ तेव्हाच बंद करा जेव्हा तुम्हाला UDR संच त्या सबनेटसाठी अधिकृत हवा असेल.

ऑन-प्रिमाइस अर्धा भाग पूर्ण करा, नाहीतर प्रवाह तिथेच मरतो

ऑन-प्रिमाइस गेटवेने Azure स्रोत स्वीकारावा, तो गंतव्याकडे पाठवावा आणि अनुप्रयोगास परवानगी द्यावी. त्याचा पुढील मार्ग इंटरनेट निर्गम किंवा दुसरा खाजगी हॉप असू शकतो, पण तो निर्णय योजनेत आहे, Azure रूट तक्त्यात नाही. नेहमीचा अपयश म्हणजे परतीचा मार्ग. इंटरनेट गंतव्य खाजगी Azure स्रोत तुमच्याकडे परत राउट करणार नाही, म्हणून उत्तर त्याच्या स्वतःच्या डीफॉल्ट गेटवेवर जाऊन मरते, किंवा बाहेरच पडत नाही.

दोन रचना हे सोडवतात आणि त्या परस्पर बदलता येत नाहीत. निर्गमस्थानी स्रोताचे भाषांतर करा, जेणेकरून गंतव्य ऑन-प्रिमाइस नेटवर्ककडे असलेल्या सार्वजनिक पत्त्याला उत्तर देईल. किंवा स्रोत जपून ठेवा आणि उत्तरे बोगद्यातून परत येण्यासाठी राउटेड परतीचे नाते तयार करा. एक निवडा आणि अनुप्रयोग कोणता पत्ता पाहील ते लिहून ठेवा.

सिलेक्टर आणि परवानगी याद्या या सर्वांपासून वेगळ्या आहेत. Azure पुढील हॉप निवडल्याने VPN रहदारी सिलेक्टर रुंद होत नाहीत, आणि बाह्य सेवेची स्रोत परवानगी यादी बदलत नाही.

गंतव्य जो स्रोत पाहते त्याने पडताळा

विनंती दुसऱ्या सबनेटमधील जंप होस्टऐवजी प्रत्यक्ष वर्कलोडमधून पाठवा, नंतर गंतव्याने पाहिलेला स्रोत पत्ता वाचा. तो एकच मूल्य दोन परतीच्या रचनांपैकी कोणती लागू आहे हे सांगते. नंतर उत्तर मार्ग तपासा, आणि VM कडील सामान्य व्यवस्थापन रहदारी अजूनही चालते याची खात्री करा, कारण अपघाताने जोडलेला डीफॉल्ट मार्ग अनुप्रयोग तुटण्यापेक्षा खूप आधी तुटलेले SSH सत्र म्हणून दिसतो.

निवडलेल्या प्रीफिक्समधून जाणे सक्तीच्या टनेलिंगपेक्षा खूप अरुंद बदल आहे. तो अरुंद ठेवा आणि परतफेड म्हणजे एक मार्ग हटवणे.