EC2 तपाईंको AWS Client VPN ल्यापटपसम्म किन पुग्न सक्दैन
Client VPN ले IPv4 क्लाइन्ट स्रोतहरूलाई endpoint को इन्टरफेसमा अनुवाद गर्छ। त्यसैले जवाफ काम गर्छ र EC2 बाट नयाँ जडान गर्दैन।
AWS Client VPN मार्फत जोडिएको ल्यापटप EC2 अनुप्रयोगसम्म कुनै समस्या बिना पुग्छ। त्यसपछि तपाईं उल्टो प्रयास गर्नुहुन्छ, EC2 बाट क्लाइन्टलाई दिइएको ठेगानासम्म, र जडान अड्किन्छ वा अस्वीकार गरिन्छ। यो असमानता विरलै छुटेको सुरक्षा समूह नियम हुन्छ। VPC सबनेटसँग सम्बद्ध Client VPN endpoint मा AWS ले IPv4 क्लाइन्ट स्रोतहरूलाई endpoint को सञ्जाल इन्टरफेसमा अनुवाद गर्छ, त्यसैले तपाईंको ल्यापटप प्रतिनिधित्व गर्ने कुनै पनि इनबाउन्ड VPC ठेगाना हुँदैन।
क्याप्चरले देखाउने कुराबाट सुरु गर्नुहोस्
क्लाइन्ट जोडिँदै गर्दा EC2 होस्टमा क्याप्चर लिनुहोस् र अनुप्रयोगले वास्तवमा देख्ने स्रोत ठेगाना पढ्नुहोस्। यदि त्यो क्लाइन्ट पूलको ठेगाना नभई VPC पक्षको endpoint इन्टरफेस हो भने, एउटा पनि नियम बदल्नुअघि नै अनुवाद पुष्टि भइसकेको छ।
क्लाइन्ट पूल एक आवंटन दायरा हो, फिर्ता मार्ग भएको सबनेट होइन। यही भिन्नतामा यस्ता अन्वेषणहरूको अधिकांश भाग गल्ती हुन्छ।
असमानता व्याख्या गर्ने अनुवाद
तीन प्रवाहहरू एकआपसमा मिसाइन्छन्, र तीमध्ये एउटा मात्र मानिसहरूले परीक्षण गर्ने प्रवाह हो।
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN कम्पोनेन्टहरूको विवरण ले IPv4 क्लाइन्ट स्रोतहरू endpoint इन्टरफेसमा अनुवाद हुने स्पष्ट बताउँछ, र मध्य पङ्क्तिसँग मिलाउन केही किन छैन भन्ने देख्न त्यति नै पर्याप्त छ।
नयाँ जडानलाई मार्ग, ठेगाना समाधानको चरण र अधिकारको निर्णय चाहिन्छ। अरू कसैको सत्रबाट आएको अनुवाद स्थितिले यी तीनमध्ये एउटा पनि दिँदैन।
जवाफ नयाँ जडान किन होइन
TCP जवाफ विद्यमान प्रविष्टिसँग मिलाइन्छ, त्यसैले कुनै पनि इनबाउन्ड नियम बिना नै फर्कने बाटो काम गर्छ। EC2 होस्टबाट आएको नयाँ SYN सँग मिलाउने प्रविष्टि हुँदैन, त्यसैले यो VPC लाई कसरी पुग्ने भन्ने थाहा नभएको गन्तव्यतर्फ सामान्य आउटबाउन्ड प्रयास बन्छ।
त्यसैले यसलाई एउटै दिशामा मात्र जाने ट्राफिक भनी वर्णन गर्नु भ्रामक हुन्छ। यी सत्रहरूमा फर्कने ट्राफिक निरन्तर बहन्छ। मार्ग नभएको भाग भनेको सुरुवात हो।
काम गर्नुपर्ने सत्रलाई अझै के ले तोड्छ
सुरक्षा समूह, सञ्जाल ACL र ल्यापटपको आफ्नै फायरवाल — सफल हुनुपर्ने जडानहरूका लागि यी सबै महत्त्वपूर्ण छन्। असफल ping ले सबैभन्दा कम बताउँछ, किनकि ICMP नीति प्रायः तपाईंलाई चासो लाग्ने TCP नीतिबाट अलग हुन्छ।
यी नियमहरू अनुवादित स्रोतका आधारमा लेख्नुहोस्, क्लाइन्ट ठेगानाका आधारमा होइन। सञ्जालमा कहिल्यै नदेखिने ठेगानासँग बाँधिएका नियमहरू यो डिजाइनमा सबैभन्दा सामान्य आफैंले निम्त्याएको खराबी हुन्।
जब VPC ले साँच्चै कुराकानी सुरु गर्नुपर्छ
यदि कुनै सेवाले कार्यस्थानलाई जानकारी दिनुपर्छ भने, दिशा उल्टाउनुहोस् र क्लाइन्टलाई सेवाले जवाफ दिने स्थायी आउटबाउन्ड च्यानल राख्न दिनुहोस्। यदि सम्पूर्ण टाढाको सञ्जाल VPC बाट पहुँचयोग्य हुनुपर्छ भने, Client VPN ले यो पहिले नै गर्छ भनी मान्नुको सट्टा आफ्ना प्रिफिक्स र पहुँच नीति प्रकाशित गर्ने वास्तुकला छान्नुहोस्। क्लाइन्ट-देखि-क्लाइन्ट पहुँच तेस्रो, अझ साँघुरो अवस्था हो, जसका आफ्नै मार्ग र अधिकार वस्तुहरू छन्। यीमध्ये कुनै पनि विद्यमान endpoint मा केवल चेकबक्स होइन।
IPv4 व्याख्याको दायरा पनि इमानदार राख्नुहोस्। हालको AWS दस्तावेजले IPv6 लाई अलग गर्छ, जहाँ त्यो अनुवाद लागू हुँदैन, र फरक रूपमा मार्गनिर्देशन गर्ने अन्य जडान मोडेलहरूलाई पनि।
तीन लेबल गरिएका चरणमा परीक्षण गर्नुहोस्: क्लाइन्टले अनुमति दिइएको सत्र खोल्छ, VPC सेवाले त्यो सत्रको जवाफ दिन्छ, र VPC होस्टले क्लाइन्टतर्फ नयाँ सत्र खोल्छ। पहिलो दुई सफल भई तेस्रो असफल हुनु यो डिजाइनको अपेक्षित रूप हो, फायरवाल नियमले खेद्नुपर्ने त्रुटि होइन।