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 सत्र के रूप में दिखता है।

चयनित प्रीफ़िक्स के माध्यम से ट्रांज़िट ज़बरदस्ती टनलिंग की तुलना में कहीं अधिक संकीर्ण बदलाव है। इसे संकीर्ण रखें और वापसी एक रूट हटाना है।