Azure VPN NAT ओवरलैपिंग VNet पतों को ठीक नहीं करता
एक ही निजी रेंज वाले दो VNet केवल NAT होने से नहीं जुड़ेंगे। पहले कनेक्शन का प्रकार देखें, फिर नंबर बदलें या अनुवाद उपनाम का स्वामित्व रखें।
दोनों VNet 10.40.1.0/24 का उपयोग करते हैं, टनल ऊपर आते हैं, और कुछ भी काम नहीं करता। दूसरा VPN गेटवे जोड़ने से यह नहीं बदलता, और न ही कम रूट मीट्रिक से, क्योंकि समस्या पथ चयन में नहीं है। एक ही निजी पते पर उत्तर देने वाले दो वर्कलोड हर पैकेट को अस्पष्ट गंतव्य और असत्यापनीय वापसी पथ के साथ छोड़ देते हैं। किसी भी अनुवाद की योजना बनाने से पहले पता लगाएँ कि आपने वास्तव में कौन-सा कनेक्शन प्रकार बनाया है, क्योंकि वही एक चुनाव तय करता है कि Azure की NAT सुविधा बिल्कुल उपलब्ध है या नहीं।
यह लक्षण वास्तव में आपको क्या बता रहा है
जब VNet A का कोई होस्ट 10.40.1.10 पर भेजता है, तो रूटिंग तालिका उसे केवल कहीं इंगित कर सकती है। यदि VNet B में भी 10.40.1.10 है, तो वह पता ऐसा गंतव्य नहीं है जिसे पथ अलग कर सके; यह दो स्वामियों वाला एक पता है।
लोग जो दूसरा गेटवे तैनात करते हैं वह मदद नहीं करता। यह आपको दूसरी टनल देता है, दूसरा पता नहीं, और डुप्लिकेट रेंज टनल के अंदर अपरिवर्तित यात्रा करती है। यह उस कॉन्फ़िगरेशन को भी दोगुना करता है जिसे आपको सुसंगत रखना है। जो यह नहीं कर सकता वह है एक पते का अर्थ दो होस्ट कर देना।
VPN पीयर के सार्वजनिक पतों को बदलने से भी कुछ नहीं होता। वे पते टनल के अंतिम बिंदुओं की पहचान करते हैं, जबकि टकराव उस निजी रेंज में है जो इसके अंदर ले जाई जाती है।
कनेक्शन प्रकार तय करता है कि NAT उपलब्ध है या नहीं
Azure VPN Gateway में वास्तव में NAT क्षमता है, और यह विशिष्ट गेटवे SKU पर रूट-आधारित IPsec अंतर-साइट कनेक्शन के लिए प्रलेखित है। वही दस्तावेज़ीकरण VNet-to-VNet और point-to-site कनेक्शनों को बाहर रखता है, इसलिए यह सुविधा ऐसा चेकबॉक्स नहीं है जो हर गेटवे संबंध पर दिखे।
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
मूल VNet-to-VNet के लिए भी शुरू से ही VNet और स्थानीय-नेटवर्क रेंज का ओवरलैप न होना आवश्यक है, जो इस अपवाद के अनुरूप है। इसी कारण VNet पीयरिंग भी ओवरलैप का समाधान नहीं है।
एक समर्थित विकल्प है जिसे लोग मूल प्रकार के साथ मिला देते हैं: दूसरे VNet को स्थानीय नेटवर्क के रूप में मॉडल करें और उसे साइट-से-साइट कनेक्शन के रूप में जोड़ें। यह भिन्न संसाधन और भिन्न डिज़ाइन है, इसलिए नाम बदले कनेक्शन को केवल नाम-परिवर्तन नहीं, बल्कि सत्यापन योग्य परिवर्तन मानें।
फिर से नंबर दें, या ऐसी चीज़ से अनुवाद करें जो उपनाम का स्वामी हो
यदि दोनों VNet आपके हैं, तो नियोजित पुनर्नंबरन की तुलना अनुवाद की निरंतर लागत से करें। पुनर्नंबरन एप्लिकेशन कॉन्फ़िगरेशन, DNS रिकॉर्ड, सुरक्षा नियमों और हर मौजूदा कनेक्शन को छूता है, पर बाद में सामान्य रूप से पढ़े जाने वाला नेटवर्क छोड़ता है। इसे एक बार में एक सबनेट करें, DNS परिवर्तन सबसे अंत में। आधा पुनर्नंबरित रेंज किसी भी विकल्प से बुरी है, क्योंकि तब दोनों प्रीफ़िक्स अगली बार तालिका पढ़ने वाले को आधिकारिक लगते हैं।
जहाँ पुनर्नंबरन व्यावहारिक नहीं है, वहाँ उपनाम के वास्तविक स्वामी वाला अनूदित डिज़ाइन अपनाएँ। VNet A के कॉलर VNet B के 10.40.1.10 तक 10.140.1.10 के रूप में पहुँच सकते हैं, पर उस उपनाम को अनुवाद करने वाला उपकरण, उसकी ओर मार्ग और उत्तर के लिए मेल खाता व्यवहार चाहिए। केवल DNS में जोड़ा गया पता अनुवाद नहीं है।
दोनों रेंज को दोनों दिशाओं में दर्ज करें: कॉलर क्या डायल करता है, गंतव्य स्रोत के रूप में क्या देखता है, और कौन-सा पक्ष पहल कर सकता है। Azure के अपने NAT नियम अपने SNAT मैपिंग के लिए उलटा अनुवाद शामिल करते हैं, इसलिए आप हाथ से मेल खाता DNAT नियम नहीं लिखते, पर वह सुविधा उन्हीं कनेक्शन प्रकारों तक सीमित है जिन्हें यह सुविधा समर्थन देती है।
क्या काम नहीं करेगा
उपयोगकर्ता-परिभाषित मार्ग या रूट मीट्रिक अनुपस्थित पता-भेद नहीं बना सकते। दोनों अभी भी अस्पष्ट गंतव्य पर काम करते हैं, और पैकेट उसी अगले हॉप पर पहुँचता है जिसे तालिका पसंद करती है।
डुप्लिकेट रेंज को अधिक विशिष्ट प्रीफ़िक्स के रूप में रूट तालिका में जोड़ना अस्पष्टता को केवल एक कदम आगे बढ़ाता है। यह दूसरी दिशा को भी तोड़ता है, जहाँ उत्तर के अब दो संभावित स्रोत हैं।
दोनों दिशाओं में ट्रैफ़िक के साथ डिज़ाइन स्वीकारें
डिज़ाइन को टनल स्थिति से नहीं, बल्कि हर पक्ष से नए अनुमत संचालन से सिद्ध करें। जुड़ी IPsec टनल कहती है कि पीयर क्रिप्टोग्राफ़ी पर सहमत हैं; यह नहीं बताती कि गंतव्य अलग-अलग हो गए या नहीं।
फिर अस्वीकृत पथ चलाएँ: एक पता जो अगम्य रहना चाहिए, और एक सेवा जिसे नीति को अवरुद्ध करना चाहिए। यदि दोनों अब भी सफल होते हैं, तो अनुवाद डिज़ाइन के इरादे से अधिक व्यापक है।
उन तथ्यों के साथ समाप्त करें जो बाद में सेटअप समझाएँगे: मूल रेंज, प्रस्तुत रेंज, अनुवाद करने वाला उपकरण, और वह दिशा जिसमें हर पक्ष पहल कर सकता है। यदि इनमें से कोई अनुपस्थित है, तो अगला इंजीनियर ऐसा नेटवर्क विरासत में पाता है जहाँ दो होस्ट एक नाम साझा करते हैं और किसी को याद नहीं कि उनमें से एक उत्तर क्यों देता है।