EC2 Elastic IP हा इन्स्टन्सचा खाजगी VPN पत्ता नाही

इन्स्टन्सला खाजगी पत्ता आहे, Elastic IP त्याला जोडलेला आहे, आणि त्या सार्वजनिक /32 साठी मार्ग VPN मध्ये जोडला जातो, दोन्ही एकच गोष्ट होतील या आशेने. होत नाहीत. Elastic IP हे गेस्टच्या बाहेर, इंटरनेट गेटवेने, इंटरनेट मार्ग घेणाऱ्या ट्रॅफिकवर केलेले भाषांतर आहे. गेस्टची ऑपरेटिंग सिस्टम तो पत्ता कधीही कोणत्याही इंटरफेसवर कॉन्फिगर केलेला पाहत नाही. तो टनेल इंटरफेसवर जोडल्याने वरील भाषांतर पुन्हा तयार होत नाही आणि त्याच मशीनसाठी दुसरी, विरोधाभासी ओळख निर्माण होते.

दोन पत्ते, एक इन्स्टन्स

इन्स्टन्सचा नेटवर्क इंटरफेस VPC मध्ये खाजगी पत्ता ठेवतो, आणि तोच पत्ता गेस्टला माहीत असतो. Elastic IP त्याच इंटरफेसला जोडलेला आहे पण मॅपिंगच्या सार्वजनिक बाजूला राहतो.

इंटरनेटमार्फत इन्स्टन्सपर्यंत पोहोचणारे सर्व खाजगी पत्त्यावर भाषांतरित होऊन येते. इन्स्टन्स इंटरनेटवर पाठवणारे सर्व Elastic IP स्रोत म्हणून बाहेर पडते, पुन्हा त्याच भाषांतरामुळे.

गेस्टच्या आत एक पत्ता आहे. बाहेर दोन आहेत. ही विषमताच या क्षेत्रातील बहुतेक गोंधळ स्पष्ट करते. गेस्ट गेटवे काय भाषांतरित करतो हे कॉन्फिगर करू शकत नाही. तो फक्त स्वतःकडे खरोखर असलेल्या पत्त्यावर उत्तर देऊ शकतो.

इंटरनेट गेटवे प्रत्यक्षात काय करतो

AWS चे इंटरनेट गेटवे दस्तऐवज ही व्यवस्था वर्णन करते: इन्स्टन्सला त्याचा खाजगी IPv4 पत्ता माहीत असतो, आणि गेटवे इंटरनेट मार्गावरील ट्रॅफिकसाठी संबंधित सार्वजनिक IPv4 किंवा Elastic IP भाषांतर पुरवतो.

हे नेटवर्क पत्ता भाषांतर आहे, उपनाव नाही. मॅपिंग गेटवे ठेवतो, ते असोसिएशनला बांधलेले आहे आणि त्यातून जाणाऱ्या पॅकेटवरच लागू होते. असोसिएशन काढून टाका आणि सार्वजनिक ओळख गेस्टला काहीही कळण्याआधीच नाहीशी होते.

म्हणूनच सार्वजनिक /32 ला उद्देशून असलेले खाजगी VPN पॅकेट गेस्टच्या स्थानिक पत्त्यावर जाणारे खाजगी पॅकेट म्हणून पुन्हा अर्थ लावले जात नाही. पॅकेट ज्या मार्गाशी जुळते तो अनुसरते, जो ते इंटरनेट गेटवेकडे पाठवतो, आणि गेटवेचे वर्तन मार्ग दोन्ही दिशांनी परवानगी असल्यावर अवलंबून असते.

टनेल इंटरफेसची युक्ती का अयशस्वी होते

Elastic IP टनेल इंटरफेसला नेमून देणे म्हणजे गेस्टला सार्वजनिक पत्त्याला स्थानिक म्हणून वागवायला सांगणे. आता दोन गोष्टी एकाच पत्त्याचा दावा करतात: इंटरनेट मार्गावरील गेटवेचे भाषांतर आणि टनेलमधील स्थानिक इंटरफेस. परत येणाऱ्या ट्रॅफिककडे कोणते लागू होते याचे सुसंगत उत्तर नाही.

कार्यरत वाटले तरी डिझाइनने खरा प्रश्न लपवला आहे. क्लायंट एकतर टनेलमार्फत खाजगी पत्त्यावर पोहोचतात किंवा इंटरनेटमार्फत सार्वजनिक एंडपॉइंटवर पोहोचतात, आणि या दोन मार्गांचे सुरक्षा गट, लॉगिंग आणि अयशस्वी होण्याच्या पद्धती वेगळ्या आहेत.

पत्ता कधीही समस्या नव्हता. मार्गाची निवड होती.

तीन उद्दिष्टे, तीन डिझाइन

उद्दिष्ट सार्वजनिक VPN एंडपॉइंट असल्यास, Elastic IP हे योग्य साधन आहे: दूरचे पीअर्स इंटरनेटमार्फत त्याला जोडतात आणि एन्क्रिप्टेड ट्रान्सपोर्ट इन्स्टन्सवर संपतो. त्यानंतर अंतर्गत अनुप्रयोग ट्रॅफिक खाजगी पत्ता वापरते.

उद्दिष्ट अनुप्रयोगातील खाजगी प्रवेश असल्यास, गंतव्य खाजगी पत्ता किंवा त्यावर रिझॉल्व्ह होणारे खाजगी DNS नाव आहे, आणि VPN मार्ग, सुरक्षा गट आणि परतीचा मार्ग सर्वांनी जुळले पाहिजे. त्या डिझाइनमध्ये Elastic IP अजिबात येत नाही.

उद्दिष्ट VPN वापरकर्त्यांसाठी स्थिर सार्वजनिक इग्रेस ओळख असल्यास, ते इग्रेस बाजूचे NAT डिझाइन आहे, क्लायंटच्या टनेलवरील पत्ता नाही. सारखीच वाटणारी तीन उद्दिष्टे तीन वेगळे आकृती देतात, आणि त्यातील फक्त एकात Elastic IP नव्या ठिकाणी ठेवणे समाविष्ट आहे.

तुम्ही निवडलेला मार्ग तपासा

खाजगी प्रवेशासाठी, VPN मार्ग खाजगी उपसर्ग व्यापतो, VPC मार्ग तक्ता ट्रॅफिक टनेलकडे परत पाठवतो, सुरक्षा गट क्लायंटचा स्रोत परवानगी देतो आणि क्लायंटचा स्वतःचा फायरवॉल उत्तर परवानगी देतो याची खात्री करा. नंतर ping ऐवजी एक वास्तविक विनंती तपासा.

सार्वजनिक प्रवेशासाठी, क्लायंटचा इंटरनेट इग्रेस, सार्वजनिक प्रवेशाचे राउटिंग आणि त्याचे सुरक्षा धोरण तपासा. VPN क्लायंट टनेलमार्फत सार्वजनिक एंडपॉइंटपर्यंत पोहोचू शकतो का हे टनेलच्या इग्रेस आणि फायरवॉल नियमांवर अवलंबून आहे, Elastic IP असोसिएशनवर नाही.

सार्वजनिक होस्टनाव दोन्ही बाजूंनी कार्यरत असावे लागल्यास, VPN क्लायंटसाठी खाजगी पत्त्याने आणि इतर सर्वांसाठी सार्वजनिक पत्त्याने उत्तर देणारे DNS डिझाइन वापरा, आणि प्रमाणपत्र पत्त्यासाठी नाही तर नावासाठी वैध ठेवा. कामाचा क्रम: उद्दिष्टाला नाव द्या, त्याला जोडलेला पत्ता निवडा, नंतर मार्ग, धोरण आणि एक विनंती तपासा.