AWS Client VPN जोडिएको छ, तर EC2 अझै जवाफ दिँदैन
जोडिएको भन्नुको अर्थ प्रमाणपत्र वा SAML लगइन चल्यो भन्ने मात्र हो। अनुमति नियम, endpoint रुट र सुरक्षा समूहले निजी होस्टसम्मको बाटोको एक-एक भाग पहरा दिन्छन्।
मेरो ल्यापटपले जोडिएको देखाइरहेको थियो। 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 बाहिर लैजान्छ र अर्कै नियम भएको अर्कै बाटोबाट फर्काउँछ, त्यसैले सार्वजनिक ठेगानामा गरिएको परीक्षणले निजी बाटोबारे केही भन्दैन।
पहिलो विफलतामा रोकिने अलगाव क्रम
यी क्रममा गर्नुहोस् र जहाँ एउटा असफल हुन्छ त्यहीँ रोक्नुहोस्। हरेक कदमले सबै तह होइन, एउटा तह हटाउँछ।
- सत्रले कुन पहिचान प्रयोग गर्यो र 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 को जडान लग निकालेर अनुमति प्रविष्टिहरू पढ्नुहोस्। लगले जाँचिएको गन्तव्य र मिलेको वा नमिलेको नियमको नाम बताउँछ, र त्यसले चार तहको प्रश्नलाई एउटै उत्तरमा झार्छ।