AWS Client VPN कनेक्ट है, फिर भी EC2 जवाब नहीं देता
कनेक्ट का मतलब सिर्फ़ यह है कि प्रमाणपत्र या SAML लॉगिन चला। अनुमति नियम, endpoint रूट और सुरक्षा समूह हर एक निजी होस्ट तक के रास्ते का एक हिस्सा संभालता है।
मेरा लैपटॉप कनेक्ट दिखा रहा था। AWS Client VPN क्लाइंट अपनी हरी स्थिति दिखा रहा था, endpoint ने सत्र दर्ज किया, और फिर भी मैं निजी सबनेट में EC2 इंस्टेंस पर MongoDB पोर्ट नहीं खोल सका। ज़ाहिर में कुछ टूटा नहीं था: प्रमाणपत्र वैध था, प्रोफ़ाइल कंसोल से आया था और टनल ट्रैफ़िक ढो रही थी। गलती मेरी थी, क्योंकि मैं कनेक्ट को अनुमत के रूप में पढ़ रहा था।
लॉगिन ठीक एक सवाल का जवाब देता है: क्या यह पहचान सत्र स्थापित कर सकती है? उसके बाद का सब कुछ अलग नियम तय करते हैं जो आपका प्रमाणपत्र कभी नहीं देखते। जो सत्र प्रमाणीकरण पास करता है और जो पैकेट पहुँचता है, वे दो अलग सफलताएँ हैं, और उनके बीच का फ़ासला वह जगह है जहाँ VPN चालू है पर होस्ट पहुँच में नहीं जैसी ज़्यादातर शिकायतें रहती हैं।
नीचे दी जाँचें वही क्रम हैं जो मैं अब इस्तेमाल करता हूँ।
कनेक्टेड सत्र असल में क्या साबित करता है
हैंडशेक के दौरान endpoint क्लाइंट प्रमाणपत्र को अपने trust store के सामने जाँचता है, या जब SAML कॉन्फ़िगर हो तो ब्राउज़र को आपके identity provider पर भेज देता है। अगर वह पास हो जाए, तो क्लाइंट को endpoint के क्लाइंट CIDR से पता मिलता है और कंसोल सक्रिय कनेक्शन दिखाता है। उस अदला-बदली में कभी कोई नहीं पूछता कि आप 10.0.4.17 तक पोर्ट 27017 पर पहुँच सकते हैं या नहीं।
किसी गंतव्य की अनुमति endpoint पर एक अलग ऑब्जेक्ट है। हर फ़्लो को अनुमति नियमों से मिलाया जाता है, और हर नियम गंतव्य CIDR को उस समूह के साथ जोड़ता है जिसे नियम दिया गया है। जब कोई नियम गंतव्य को नहीं ढकता, endpoint सत्र स्वीकार कर लेता है और ट्रैफ़िक गिरा देता है। कोई बैनर नहीं, कोई पुनःकनेक्ट लूप नहीं, और क्लाइंट UI में कुछ भी नहीं जो अस्वीकृत कहे।
अनुमति नियम की तुलना VPC से नहीं, संसाधन से करें
नियमों की सूची बनाएँ और उन्हें उस पते के पास रखें जो इंस्टेंस के पास असल में है:
aws ec2 describe-client-vpn-authorization-rules \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8आउटपुट हर नियम के लिए गंतव्य CIDR और समूह ID दिखाता है। इसमें दो विफलताएँ छिपी हैं। नियम 10.0.0.0/16 को अनुमति दे सकता है जबकि इंस्टेंस 10.1.0.0/16 पर पीयर किए गए VPC में बैठा है; पीयरिंग रूट मौजूद है, पर किसी ने दूसरी श्रेणी के लिए अनुमति नियम नहीं लिखा। या नियम ऐसे डायरेक्टरी समूह की ओर इशारा करता है जिसमें उपयोगकर्ता डायरेक्टरी में शामिल है पर उस समूह में नहीं जिसका endpoint मूल्यांकन करता है।
गंतव्य को ढकने वाला सबसे सँकरा नियम लिखें, और दूसरा नियम तभी जोड़ें जब दूसरा CIDR सचमुच ज़रूरी हो। तेज़ शुरुआत से आया चौड़ा 0.0.0.0/0 नियम काम करता है, और इसीलिए वह प्रोडक्शन तक ज़िंदा रहता है और मॉडल छिपा देता है।
दो रूट टेबल तय करते हैं कि पैकेट आगे बढ़ेगा या नहीं
endpoint रूट किसी गंतव्य CIDR को उन सबनेट में से एक पर मैप करता है जिनसे endpoint जुड़ा है। यह आधा रास्ता है। सबनेट की अपनी रूट टेबल को अब भी जानना होता है कि पैकेट कैसे आगे भेजा जाए, और यह उस पल मायने रखता है जब गंतव्य पीयरिंग कनेक्शन, ट्रांज़िट गेटवे या साइट-टू-साइट टनल से पहुँचने योग्य ऑन-प्रिमाइसेस श्रेणी के पीछे हो।
aws ec2 describe-client-vpn-routes \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8ऐसा रूट खोजें जिसका गंतव्य संसाधन के CIDR से मेल खाता हो और जिसका लक्ष्य जुड़ा हुआ सबनेट हो। अगर रूट न हो तो जोड़ें। अगर हो और होस्ट फिर भी चुप हो, तो फ़ासला VPC की ओर है, इसलिए संबद्ध सबनेट की रूट टेबल से तुलना करें।
क्लाइंट की ओर की एक सेटिंग टनल तोड़े बिना रूटिंग तोड़ देती है: route-nopull वाली प्रोफ़ाइल। यह निर्देश OpenVPN-आधारित क्लाइंट से कहता है कि सर्वर जो रूट धकेलता है उन्हें अनदेखा करे, इसलिए इंटरफ़ेस सिर्फ़ endpoint के अपने पते के साथ ऊपर आता है और गंतव्य का बस कोई रूट नहीं होता। Linux पर ip route show या macOS पर netstat -rn से जाँचें कि tun इंटरफ़ेस से कोई रूट है या नहीं। अगर नहीं, तो निर्यात की गई प्रोफ़ाइल से route-nopull हटाएँ और फिर से कनेक्ट करें ताकि धकेले गए रूट लागू हों।
सुरक्षा समूह आपका क्लाइंट पता नहीं देखते
यही वह हिस्सा है जिसमें मैं पूरी दोपहर गलत रहा। सबनेट से जुड़े IPv4 endpoint के लिए, सेवा क्लाइंट के स्रोत पते को उस सबनेट में endpoint के नेटवर्क इंटरफ़ेस के पते में बदल देती है. इंस्टेंस तक पहुँचने वाले पैकेट में वह पता नहीं होता जो आपके क्लाइंट ने दिखाया था, इसलिए क्लाइंट पूल, मान लीजिए 172.16.0.0/22, को अनुमति देने वाला सुरक्षा समूह नियम किसी चीज़ से नहीं मिलता।
पोर्ट को क्लाइंट CIDR से नहीं, endpoint के सुरक्षा समूह से अनुमति दें, जो संबद्धता के इंटरफ़ेस से जुड़ा है। समूह का संदर्भ देना पते को हार्डकोड करने से ज़्यादा टिकाऊ है, क्योंकि इंटरफ़ेस का पता आपके नियंत्रण में नहीं है। नेटवर्क ACL स्टेटलेस होते हैं, इसलिए जहाँ कस्टम प्रविष्टियाँ हैं वहाँ आने और जाने दोनों दिशाओं को फ़्लो की अनुमति देनी होती है।
इंस्टेंस के निजी पते से भी कनेक्ट करें। सार्वजनिक IP पैकेट को VPC से बाहर ले जाता है और दूसरे नियमों वाले दूसरे रास्ते से वापस लाता है, इसलिए सार्वजनिक पते पर की गई जाँच निजी रास्ते के बारे में कुछ नहीं कहती।
पहली विफलता पर रुकने वाला अलगाव क्रम
इन्हें क्रम से करें और जहाँ एक विफल हो वहीं रुकें। हर कदम सारी परतें नहीं, एक परत हटाता है।
- पुष्टि करें कि सत्र ने कौन-सी पहचान इस्तेमाल की और endpoint किस समूह का मूल्यांकन करता है। एक trust store का प्रमाणपत्र डायरेक्टरी से आए SAML दावे जैसा एक ही प्रिंसिपल नहीं है।
- पुष्टि करें कि कोई अनुमति नियम उस समूह के लिए संसाधन का CIDR ढकता है।
- पुष्टि करें कि endpoint रूट मौजूद है और जुड़े सबनेट को लक्षित करता है, फिर पुष्टि करें कि सबनेट की रूट टेबल आगे भेज सकती है।
- पुष्टि करें कि सुरक्षा समूह पोर्ट को क्लाइंट पूल से नहीं, endpoint इंटरफ़ेस से अनुमति देता है।
- अनुप्रयोग की समस्या को क्लाइंट-पथ की समस्या से अलग करने के लिए VPC के अंदर से, उसी सबनेट के किसी दूसरे इंस्टेंस पर SSM सत्र से जाँचें।
जब कदम निर्णायक न हों, तो मैं इस तालिका पर लौटता हूँ:
| Symptom | Layer to inspect |
|---|---|
| Client shows connected, host times out, no byte growth on the interface | Authorization rule, then security group |
| Ping fails but a TCP connect to the port succeeds | ICMP is blocked; not an access failure |
| Tunnel reconnects every few minutes | Two machines sharing one client certificate |
| Works on one laptop, fails on another | Local profile has route-nopull or stale pushed routes |
खाते की दो बातें ऐसे लक्षण पैदा करती हैं जो अनुमति विफलता जैसे लगते हैं। हर उपयोगकर्ता को अलग क्लाइंट प्रमाणपत्र चाहिए; एक को दो मशीनों में बाँटने से सत्र एक-दूसरे को हटाने लगते हैं, और नतीजा अस्वीकृति नहीं बल्कि पुनःकनेक्ट लूप होता है। जब नया endpoint बनता है, तो कंसोल एक DNS नाम दिखाता है जिसे कुछ क्लाइंट संस्करण सिर्फ़ endpoint पृष्ठ पर दिखाए गए यादृच्छिक प्रीफ़िक्स के साथ स्वीकार करते हैं, इसलिए नाम दोबारा बनाने के बजाय पूरा नाम कॉपी करें।
अगर पाँचवाँ कदम आपको अटका दे, तो कुछ भी बदलने से पहले endpoint का कनेक्शन लॉग निकालें और अनुमति प्रविष्टियाँ पढ़ें। लॉग उस गंतव्य का नाम बताता है जिसकी जाँच हुई और वह नियम जो मिला या नहीं मिला, और यह चार परतों वाले सवाल को एक जवाब में बदल देता है।