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 गेटवेचे प्रवाह समर्थित स्रोत बाजूने सुरू होतात, म्हणून ही खाजगी वर्कलोड उघड करण्यासाठी येणारी पोर्ट फॉरवर्डिंग सेवा नाही। हे लवकर मोठ्याने सांगितल्यास प्रत्येक बाजूने दुसरी बाजू सुरू करत असल्याचे गृहीत धरलेल्या रचना आढाव्याला प्रतिबंध होतो।

रूपांतरण पत्त्यांच्या अतिव्यापनातून आराम आणि अंदाज करण्यायोग्य स्रोत धोरण विकत घेते, आणि भागीदाराच्या लॉगमध्ये वैयक्तिक वर्कलोड ओळख तुम्हाला गमावते। ऑडिटला प्रत्येक वर्कलोडसाठी श्रेय हवे असल्यास, ती ओळख रूपांतरित स्रोत पत्त्यातून पुनर्प्राप्त करण्याचा प्रयत्न करण्याऐवजी अनुप्रयोग स्तरावर ठेवा।

नंतर कोणत्याही बदलानंतर दोन्ही रूट तक्ते पुन्हा तपासा, कारण नवीन जोडणी किंवा पुन्हा जोडलेला सबनेट उत्तर गुपचूप पुन्हा लिहितो।