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 बोगदा पीअर्स क्रिप्टोग्राफीवर सहमत आहेत असे सांगतो; गंतव्ये वेगळी झाली आहेत का याबद्दल तो काहीही सांगत नाही.
नंतर नाकारलेले मार्ग चालवा: ज्या पत्त्यावर पोहोचता येऊ नये आणि जी सेवा धोरणाने अडवायला हवी. दोन्ही अजूनही यशस्वी झाल्यास भाषांतर रचनेच्या हेतूपेक्षा विस्तृत आहे.
नंतर हे संयोजन स्पष्ट करणाऱ्या तथ्यांसह समारोप करा: मूळ श्रेणी, सादर केलेली श्रेणी, भाषांतर करणारे उपकरण आणि प्रत्येक बाजू सुरुवात करू शकणारी दिशा. यापैकी काही गहाळ असल्यास पुढील अभियंत्याला असे नेटवर्क वारसा मिळते जिथे दोन होस्ट एकच नाव सामायिक करतात आणि त्यातील एक उत्तर का देतो हे कोणालाच आठवत नाही.