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 होस्ट क्लायंटकडे नवीन सत्र उघडतो. पहिली दोन यशस्वी होऊन तिसरी अयशस्वी होणे ही या रचनेची अपेक्षित रचना आहे, फायरवॉल नियमांनी पाठलाग करावा असा दोष नाही.