Anypoint VPN या Transit Gateway NAT: अनुवाद कहाँ होता है
Anypoint VPN स्वयं पतों का अनुवाद नहीं करता। NAT का वादा करने से पहले फ़ायरवॉल PAT, AWS प्रीफ़िक्स मैप या किसी अन्य अटैचमेंट के बीच चुनें।
NAT की माँग तब तक माँग नहीं है जब तक वह उन पतों का नाम न ले जो बदलते हैं और उस घटक का जिसे उन्हें बदलने की अनुमति है। MuleSoft कनेक्टिविटी में उस निर्णय के तीन इनपुट हैं: क्या बैकएंड को अनेक-से-एक पोर्ट अनुवाद चाहिए या एक-से-एक प्रीफ़िक्स उपनाम, क्या आपके वास्तविक स्वामित्व वाला AWS अटैचमेंट वह मैपिंग कर सकता है, और क्या पूरा पथ विक्रेता द्वारा समर्थित संयोजन के भीतर रहता है। ये गलत हुए तो आप एक चलती लैब बनाएँगे जो समीक्षा में विफल होती है।
एक ही स्थिर बिंदु यह है कि Anypoint VPN स्वयं अनुवाद उपकरण नहीं है। CloudHub 2.0 का दस्तावेज़ वहाँ NAT को असमर्थित के रूप में सूचीबद्ध करता है, इसलिए कोई भी डिज़ाइन जो मानता है कि टनल आपके वर्कर पतों को छिपा देगा, पहले से ही टूटा हुआ है।
तय करें कि अनुवाद को क्या करना है
यदि बहुत से एप्लिकेशन वर्कर बैकएंड के सामने एक ही पते के रूप में दिखने चाहिए, तो आवश्यकता साझा स्रोत अनुवाद है, आमतौर पर उस फ़ायरवॉल पर स्टेटफ़ुल SNAT या PAT जिसे आप नियंत्रित करते हैं। उस घटक को स्वीकृत पथ पर बैठना चाहिए, फ़्लो के पूरे जीवनकाल तक अपनी स्थिति रखनी चाहिए और हर उस कनेक्शन का लौटता ट्रैफ़िक देखना चाहिए जिसे उसने फिर से लिखा। सत्र के बीच में स्थिति खोने से कनेक्शन कमज़ोर नहीं होता; वह उसे समाप्त कर देता है। अनुवाद स्थिति साझा करने से इनकार करने वाला फ़ायरवॉल युग्म फ़ेलओवर के बाद स्टैंडबाय सदस्य पर आने वाले हर सत्र को गिरा देगा। उस घटक का आकार एक साथ चलने वाले फ़्लो के लिए तय करें, थ्रूपुट के लिए नहीं।
यदि इसके बजाय दो नेटवर्क ओवरलैप करते हैं और हर होस्ट को अलग उपनाम चाहिए, तो आवश्यकता स्पष्ट मैप किए गए प्रीफ़िक्स, मेल खाते रूट और मैपिंग से सहमत नाम विभेदन वाली एक-से-एक पता योजना है। हर वर्कर को एक पते के पीछे छिपाना उसका सस्ता संस्करण नहीं है, और डिज़ाइन समीक्षा में एक को दूसरे से बदलना वही है जिससे परियोजनाएँ एक तिमाही गँवाती हैं।
उत्पाद चुनने से पहले निर्णय ठोस शब्दों में दर्ज करें: मूल स्रोत, मूल गंतव्य, अनूदित मान, आरंभ की दिशा, अनुवादक का स्वामी और अपेक्षित उत्तर मार्ग। यह भी जोड़ें कि बैकएंड लॉग कौन-सी पहचान रखेंगे, क्योंकि सभी स्रोत छिपाने वाला डिज़ाइन प्रति-ग्राहक ऑडिट भी नष्ट कर देता है।
जाँचें कि क्या AWS आपके लिए मैपिंग कर सकता है
AWS अब Transit Gateway और Cloud WAN अटैचमेंट पर प्रबंधित एक-से-एक NAT का दस्तावेज़ देता है, जिसकी घोषणा अक्टूबर 2026 के अंत में हुई, इसलिए यह पुराना सामान्य दावा कि ट्रांज़िट गेटवे कभी अनुवाद नहीं कर सकता, अब पुराना पड़ गया है। Transit Gateway NAT दस्तावेज़ स्टेटलेस IPv4 प्रीफ़िक्स मैपिंग का वर्णन करता है: मूल और अनूदित प्रीफ़िक्स समान लंबाई रखते हैं, और होस्ट बिट तथा ट्रांसपोर्ट पोर्ट अनुवाद के बाद भी बने रहते हैं। इनग्रेस और एग्रेस दिशाओं को अलग डिज़ाइन निर्णय के रूप में पढ़ें, क्योंकि वे अलग-अलग कॉन्फ़िगर होती हैं और एक तैयार हो सकती है जबकि दूसरी नहीं। उस वर्णन में कुछ भी प्रति-फ़्लो स्थिति का संकेत नहीं देता, इसलिए यह अपेक्षा न रखें कि मैपिंग आपके लिए कनेक्शन ट्रैक करेगा।
इसका अर्थ है कि 10.80.0.0/16 को 172.28.0.0/16 पर मैप करने से 10.80.10.23 172.28.10.23 बन जाता है। यह /16 को एक पते में नहीं समेटता और PAT की आवश्यकता को प्रतिस्थापित नहीं करता। यह चुने हुए अटैचमेंट प्रकारों को भी कवर करता है, जिनमें VPC और Site-to-Site VPN शामिल हैं, पर Client VPN अटैचमेंट नहीं, और कॉन्फ़िगरेशन ट्रांज़िट गेटवे के स्वामी के पास रहता है, Anypoint पक्ष के पास नहीं।
इस सुविधा को एक और संभावित नियंत्रण बिंदु मानें, इस बात का प्रमाण नहीं कि आपका परिनियोजन इसका उपयोग कर सकता है। CloudHub 2.0 ग्राहक के अपने AWS खाते में ट्रांज़िट गेटवे पर निजी-स्थान अटैचमेंट का दस्तावेज़ देता है, क्षेत्रीय और हक़ शर्तों के साथ, इसलिए नए विकल्प के इर्द-गिर्द डिज़ाइन करने से पहले वास्तविक अटैचमेंट प्रकार, उसके स्वामी और विक्रेता की समर्थन स्थिति की पुष्टि करें।
पथ को समर्थित सीमा के भीतर रखें
फ़ायरवॉल अनुवादक के लिए, चलती टनल में सामान्य NAT नियम चिपकाने के बजाय उस उत्पाद का समर्थित VPN, अनुवाद और रूटिंग मॉडल उपयोग करें। बैकएंड का उत्तर उसी अनुवाद घटक से लौटना चाहिए, और स्वस्थ आउटबाउंड टनल उस वापसी मार्ग के बारे में कुछ नहीं कहती।
ट्रांज़िट गेटवे मार्ग के लिए, निजी-स्थान अटैचमेंट, संबंधित रूट तालिकाओं, ऑन-प्रिमाइस अटैचमेंट और उन हिस्सों की सूची बनाएँ जिन्हें ग्राहक वास्तव में कॉन्फ़िगर कर सकता है। यह अलग कनेक्टिविटी वास्तुकला है, मौजूदा Anypoint VPN कनेक्शन पर लगा NAT चेकबॉक्स नहीं, और समर्थन सीमा उसके साथ खिसकती है।
तीन विकल्पों की एक तालिका में तुलना करें
अधिकांश टीमों को केवल दो प्रश्नों के उत्तर देने होते हैं: अनेक-से-एक या एक-से-एक, और अटैचमेंट का स्वामी कौन है। नीचे की तालिका उन उत्तरों को आरंभिक विकल्प में बदल देती है।
| Requirement | Starting option | What breaks it |
|---|---|---|
| Many workers, one backend address | Stateful PAT on your firewall | Asymmetric return path, expired state |
| Overlapping /16s, one-to-one | AWS prefix mapping on a supported attachment | Client VPN attachment, no explicit config |
| Per-client audit must survive | Keep original sources, translate downstream | Any many-to-one hiding of sources |
तीसरे स्तंभ को बाद का विचार नहीं, समीक्षा का प्रश्न पढ़ें। काग़ज़ पर अनुमत पर उस अटैचमेंट पर कॉन्फ़िगर किया गया प्रीफ़िक्स मैप जिसका आप स्वामी नहीं हैं, फिर भी अवरुद्ध परियोजना है, और ट्रैफ़िक पार कराने वाला पर प्रति-ग्राहक लॉगिंग तोड़ने वाला PAT नियम आगे आने वाले ऑडिट में विफल होता है।
वादा करने से पहले मैपिंग की पुष्टि करें
पथ से एक नया एप्लिकेशन संचालन भेजें और केवल अनुरोध नहीं, उत्तर की भी पुष्टि करें। बैकएंड स्वामी से पूछें कि उनके लॉग ने कौन-सा स्रोत पता दर्ज किया, जाँचें कि दोनों दिशाओं में पता-परिवार का व्यवहार योजना से मेल खाता है, और सत्यापित करें कि जिस मार्ग को अस्वीकार होना चाहिए वह अब भी अस्वीकार होता है। पुराना कनेक्शन उस मैपिंग के बारे में कुछ सिद्ध नहीं करता जिसे आपने अभी बदला है।
बैकएंड प्रमाणीकरण को इससे स्वतंत्र रखें कि उसकी अनुमति-सूची को कौन-सा अनूदित पता संतुष्ट करता है, क्योंकि मैपिंग नेटवर्क की प्लंबिंग है, अभिगम नियंत्रण का निर्णय नहीं। जिस क्षण पासवर्ड रीसेट किसी NAT प्रीफ़िक्स पर निर्भर होता है, उसी क्षण हर भावी रेंज परिवर्तन व्यवधान बन जाता है।
स्वीकृति से पहले तीन उत्तर लिखें: अनुवाद का प्रकार, अनुवादक का स्वामी, और वह समर्थित अटैचमेंट या उत्पाद पथ जो इसे वहन करता है। यदि इनमें से कोई भी अब भी अनुमान है, तो डिज़ाइन परिवर्तन-विंडो के लिए तैयार नहीं है।