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 डिजाइन प्रयोग गर्नुहोस्, र प्रमाणपत्रलाई ठेगानाको सट्टा नामका लागि वैध राख्नुहोस्। कामको क्रम: लक्ष्यको नाम दिनुहोस्, त्यसमा पर्ने ठेगाना छान्नुहोस्, त्यसपछि मार्ग, नीति र एउटा अनुरोध प्रमाणित गर्नुहोस्।