AWS का NAT गेटवे VPN की ओर कौन-सा स्रोत IP उपयोग करता है?

आप VPC कंसोल खोलते हैं क्योंकि किसी साझेदार ने पूछा कि साइट-टू-साइट VPN से कौन-सी स्रोत श्रेणी आएगी। NAT गेटवे पृष्ठ एक सार्वजनिक गेटवे दिखाता है जिससे Elastic IP जुड़ा है, और ललक यह है कि वही पता भेजकर आगे बढ़ जाएं। इंटरनेट पथ के लिए यह सही उत्तर है और VPN पथ के लिए गलत उत्तर, और अंतर यह है कि रूट तालिका किस गेटवे की ओर इशारा करती है। अनुमति सूची लिखने से पहले रास्ता चल कर देखें।

अनुमति सूची से नहीं, NAT गेटवे पृष्ठ से शुरू करें

NAT गेटवे पृष्ठ आपको सबनेट, प्रकार और Elastic IP बताता है, और ये तीन फ़ील्ड शुरू करने के लिए पर्याप्त हैं। जो यह नहीं बताता वह है ट्रैफ़िक बाद में जो रास्ता लेता है। वह NAT गेटवे के सबनेट से जुड़ी रूट तालिकाओं से आता है।

पहले प्रकार पढ़ें, क्योंकि सार्वजनिक या निजी यह तय करता है कि श्रृंखला में बाद में इंटरनेट गेटवे आएगा या नहीं। फिर सबनेट पढ़ें, क्योंकि दूसरा रास्ता वहीं रहता है।

दोनों रूपांतरणों का पालन करें

सार्वजनिक और निजी दोनों NAT गेटवे वर्कलोड के निजी IPv4 स्रोत को NAT गेटवे के अपने निजी IPv4 पते में बदलते हैं। यह पहला रूपांतरण प्रकार से स्वतंत्र होकर होता है। दूसरा रूपांतरण वह है जिसे लोग भूल जाते हैं: सार्वजनिक NAT गेटवे ट्रैफ़िक को इंटरनेट गेटवे को सौंपता है, जो पते को जुड़े Elastic IP से मैप करता है।

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

निजी पथ में श्रृंखला में कोई इंटरनेट गेटवे नहीं होता। जब ट्रैफ़िक ट्रांज़िट गेटवे या वर्चुअल निजी गेटवे से बाहर जाता है, तो NAT गेटवे मार्गदर्शिका NAT गेटवे के निजी पते को उस स्रोत के रूप में दर्ज करती है जो दूरस्थ पक्ष प्राप्त करता है। साझेदार को यही पता अनुमत करना चाहिए, Elastic IP नहीं।

VPN पथ आमतौर पर निजी पता दिखाता है

10.20.1.0/24 में रहने वाले वर्कलोड के लिए जो साझेदार के प्रीफ़िक्स तक पहुंचता है, वर्कलोड सबनेट की रूट तालिका NAT गेटवे की ओर और NAT गेटवे के सबनेट की रूट तालिका निजी गेटवे के पथ की ओर इशारा करती है। दोनों हॉप महत्वपूर्ण हैं, और केवल दूसरा तय करता है कि साझेदार क्या देखता है। यदि NAT सबनेट के पास VPN पथ तक कोई रूट नहीं है, तो पैकेट कभी नहीं पहुंचता, और यह गलत स्रोत पते से भिन्न विफलता है।

पतों पर बात करने से पहले ही उस दूसरे रास्ते को सत्यापित करें। गायब रूट और गलत बताया गया स्रोत उस साझेदार के लिए बिल्कुल एक जैसे दिखते हैं जो बस ट्रैफ़िक नहीं देख रहा है।

जब दूसरा रूपांतरण उत्तर बदल देता है

AWS ट्रांज़िट गेटवे अटैचमेंट पर एक स्पष्ट, मेल खाता एक-से-एक NAT मैपिंग भी देता है। वह मैपिंग दूरस्थ सेवा के देखने से पहले स्रोत को फिर से बदल सकती है, और यह केवल रूट करने वाला डिफ़ॉल्ट व्यवहार नहीं है। चूंकि इसे जानबूझकर कॉन्फ़िगर करना पड़ता है, इसे डिज़ाइन अपवाद मानें, न कि ऐसी चीज़ जो संयोग से विरासत में मिले। यदि आपकी टीम में किसी को याद नहीं कि उसे चालू किया था, तो अटैचमेंट पढ़ने तक उसे अनुपस्थित मानें।

यदि आपका डिज़ाइन इसे उपयोग करता है, तो अनुमति सूची में NAT गेटवे का पता नहीं, अंतिम मैपिंग बताई जानी चाहिए। यही सावधानी उपलब्धता पथों पर भी लागू है: जब कई गेटवे पते भाग लेते हैं, तो अपेक्षित स्रोत समुच्चय संघ होता है, कोई एक प्रतिनिधि पता नहीं। लिख लें कि प्रत्येक पता किस रूपांतरण का है, क्योंकि उद्गम के बिना सूची का बाद में ऑडिट करना असंभव है।

निजी NAT गेटवे को इंटरनेट गेटवे की ओर इंगित करके इंटरनेट सेवा नहीं दी जा सकती; AWS दर्ज करता है कि ऐसा ट्रैफ़िक छोड़ दिया जाता है। प्रकार पूरे पथ से चुनें, आवश्यकता में लिखे VPN शब्द से नहीं।

वह अनुबंध लिखें जिस पर आपका साझेदार कार्य कर सके

उपयोगी अनुबंध के चार भाग होते हैं: वह दिशा जिससे प्रवाह आरंभ होते हैं, वह रूपांतरित पहचान जो साझेदार देखेगा, उस पहचान के लिए वापसी मार्ग, और लागू सुरक्षा दायरा। NAT गेटवे के प्रवाह समर्थित स्रोत पक्ष से आरंभ होते हैं, इसलिए यह निजी वर्कलोड उजागर करने के लिए आने वाला पोर्ट फ़ॉरवर्डिंग सेवा नहीं है। इसे जल्दी ज़ोर से कहना ऐसी डिज़ाइन समीक्षा रोकता है जिसमें हर पक्ष मान रहा था कि दूसरा पक्ष आरंभ कर रहा है।

रूपांतरण पता-अतिव्यापी से राहत और पूर्वानुमेय स्रोत नीति खरीदता है, और साझेदार के लॉग में व्यक्तिगत वर्कलोड पहचान आपको महंगी पड़ती है। यदि ऑडिट को प्रति-वर्कलोड एट्रिब्यूशन चाहिए, तो वह पहचान एप्लिकेशन परत पर रखें, न कि उसे रूपांतरित स्रोत पते से पुनः प्राप्त करने का प्रयास करें।

फिर किसी भी बदलाव के बाद दोनों रूट तालिकाएं दोबारा जांचें, क्योंकि नया अटैचमेंट या फिर से जुड़ा सबनेट उत्तर को चुपचाप फिर से लिख देता है।