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 टनेलले पियरहरू क्रिप्टोग्राफीमा सहमत छन् भन्छ; गन्तव्यहरू छुट्याउन योग्य भए कि भएन भन्नेबारे यसले केही भन्दैन।
त्यसपछि अस्वीकृत मार्गहरू चलाउनुहोस्: अगम्य रहनुपर्ने ठेगाना, र नीतिले रोक्नुपर्ने सेवा। दुवै अझै सफल भएमा, अनुवाद डिजाइनको मनसायभन्दा फराकिलो छ।
पछि यो सेटअप व्याख्या गर्ने तथ्यहरूसँग टुङ्ग्याउनुहोस्: मूल दायरा, प्रस्तुत दायरा, अनुवाद गर्ने यन्त्र, र प्रत्येक पक्षले सुरु गर्न सक्ने दिशा। यीमध्ये कुनै छुटेमा, अर्को इन्जिनियरले दुई होस्टले एउटै नाम साझा गर्ने र किन एउटाले जवाफ दिन्छ कसैले सम्झना नगर्ने नेटवर्क उत्तराधिकारमा पाउँछ।