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 होस्ट क्लाइंट की ओर नया सत्र खोलता है। पहले दो का सफल होना और तीसरे का विफल होना इस डिज़ाइन का अपेक्षित रूप है, फ़ायरवॉल नियमों से पीछा करने लायक खराबी नहीं।