AWS Client VPN कनेक्ट आहे, तरीही EC2 उत्तर देत नाही

माझा लॅपटॉप कनेक्ट दाखवत होता. AWS Client VPN क्लायंट त्याची हिरवी स्थिती दाखवत होता, endpoint ने सत्र नोंदवले, आणि तरीही मला खाजगी सबनेटमधील EC2 इन्स्टन्सवर MongoDB पोर्ट उघडता आला नाही. काहीही स्पष्टपणे तुटलेले नव्हते: प्रमाणपत्र वैध होते, प्रोफाइल कन्सोलमधून आले होते आणि टनल ट्रॅफिक वाहत होते. चूक माझी होती, कारण मी कनेक्ट हे अधिकृत असे वाचत होतो.

लॉगिन नेमका एकाच प्रश्नाचे उत्तर देते: ही ओळख सत्र स्थापित करू शकते का? त्यानंतरचे सर्व काही वेगळ्या नियमांनी ठरते, जे तुमचे प्रमाणपत्र कधीही पाहत नाहीत. प्रमाणीकरण पास होणारे सत्र आणि पोहोचणारे पॅकेट या दोन वेगळ्या यशस्वीता आहेत, आणि त्यांच्यातील अंतर हेच VPN सुरू आहे पण होस्ट पोहोचत नाही अशा बहुतेक तक्रारी राहतात ते ठिकाण.

खालील तपासण्या मी आता वापरतो तो क्रम आहे.

कनेक्टेड सत्र प्रत्यक्षात काय सिद्ध करते

हँडशेक दरम्यान endpoint क्लायंट प्रमाणपत्र त्याच्या trust store विरुद्ध तपासते, किंवा SAML कॉन्फिगर केलेले असताना ब्राउझरला तुमच्या ओळख पुरवठादाराकडे पाठवते. ते पास झाल्यास क्लायंटला 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 बाहेर नेते आणि वेगळ्या नियमांसह वेगळ्या मार्गाने परत आणते, त्यामुळे सार्वजनिक पत्त्यावरील चाचणी खाजगी मार्गाबद्दल काहीही सांगत नाही.

पहिल्या अपयशावर थांबणारा अलगीकरणाचा क्रम

हे क्रमाने करा आणि एक अयशस्वी होईल तिथे थांबा. प्रत्येक पायरी सर्व स्तर नाही, एक स्तर वगळते.

1. सत्राने कोणती ओळख वापरली आणि endpoint कोणत्या गटाचे मूल्यांकन करते याची खात्री करा. एका trust store मधील प्रमाणपत्र डिरेक्टरीमधील SAML दाव्यासारखे एकच प्रिन्सिपल नाही.
2. परवानगी नियम त्या गटासाठी संसाधनाचा CIDR व्यापतो याची खात्री करा.
3. endpoint रूट अस्तित्वात आहे आणि संबद्ध सबनेटला लक्ष्य करतो, आणि नंतर सबनेटचे रूट तक्ते पुढे पाठवू शकते याची खात्री करा.
4. सुरक्षा गट पोर्टला क्लायंट पूलमधून नाही, endpoint इंटरफेसवरून परवानगी देतो याची खात्री करा.
5. अ‍ॅप्लिकेशन समस्या क्लायंट मार्गाच्या समस्येपासून वेगळी करण्यासाठी VPC च्या आतून, त्याच सबनेटमधील दुसऱ्या इन्स्टन्सवर SSM सत्राने चाचणी करा.

पायऱ्या निर्णायक नसतील तेव्हा मी या तक्त्यावर अवलंबून असतो:

खात्याचे दोन तपशील परवानगी अपयशासारखी लक्षणे निर्माण करतात. प्रत्येक वापरकर्त्याला वेगळे क्लायंट प्रमाणपत्र आवश्यक आहे; एक दोन मशीनमध्ये वाटल्यास सत्रे एकमेकांना ढकलतात, आणि परिणाम नकार नाही तर पुन्हा कनेक्ट होण्याचा लूप असतो. नवीन endpoint तयार होताना कन्सोल DNS नाव दाखवते, जे काही क्लायंट आवृत्त्या endpoint पृष्ठावर दाखवलेल्या यादृच्छिक उपसर्गासहच स्वीकारतात, म्हणून नाव पुन्हा तयार करण्याऐवजी पूर्ण नाव कॉपी करा.

पाचवी पायरी तुम्हाला अडकवत असेल, तर काहीही बदलण्यापूर्वी endpoint चा कनेक्शन लॉग काढा आणि परवानगी नोंदी वाचा. लॉग तपासलेले गंतव्य आणि जुळलेला किंवा न जुळलेला नियम नावाने सांगतो, आणि त्यामुळे चार स्तरांचा प्रश्न एका उत्तरात आटोपतो.