AWS Client VPN प्रमाणीकरण: IAM अनुमतिहरू लगइन विधि होइनन्
कन्सोल अनुमतिहरूले टनेल प्रमाणीकरण गर्दैनन्। प्रमाणपत्र, AD र SAML विधिहरू तुलना गर्नुहोस्, त्यसपछि SSM पोर्ट फर्वार्डिङ एक निजी डेटाबेसका लागि कहिले उपयुक्त हुन्छ हेर्नुहोस्।
प्रयोगकर्तालाई AWS Client VPN एन्डपोइन्ट सिर्जना वा वर्णन गर्ने अनुमति दिनुले उसलाई त्यसमा जडान गर्न दिँदैन। यी दुई फरक प्रकारका पहिचान हुन्: IAM ले AWS API कलहरू नियन्त्रण गर्छ, र एन्डपोइन्टले त्यसमा कन्फिगर गरिएका क्लाइन्ट प्रमाणीकरण विधिहरू मात्र स्वीकार गर्छ। त्यसैले प्रयोगकर्तासँग व्यापक कन्सोल अधिकार हुन सक्छ र तैपनि VPN क्लाइन्टले प्रस्तुत गर्न सक्ने केही नहुन सक्छ। एन्डपोइन्ट कुन विधिमा भरोसा गर्छ निर्धारण गर्नुहोस्, त्यसपछि तपाईंले दिइरहेको पहुँचका लागि पूर्ण टनेल सही आकार हो वा होइन निर्धारण गर्नुहोस्।
API पहिचान टनेल पहिचान होइन
जब कोही भन्छ «IAM भूमिका जोडिएको छ, तैपनि VPN किन असफल हुन्छ», उत्तर सामान्यतया यो हुन्छ कि जडान प्रवाहको कुनै पनि चरणले त्यो भूमिका कहिल्यै पढ्दैन। क्लाइन्टले प्रमाणपत्र, AD प्रयोगकर्तानाम र पासवर्ड, वा SAML दाबी प्रस्तुत गर्छ। एन्डपोइन्टले तीमध्ये एउटा प्रमाणित गर्छ र त्यसपछि ठेगाना तोक्छ।
IAM अझै महत्त्वपूर्ण छ, केवल पछि र अन्तै: एन्डपोइन्ट सिर्जना गर्नु, सबनेट जोड्नु, मार्ग प्रकाशित गर्नु र अनुमति नियम लेख्नु API क्रियाहरू हुन्। ती अनुमतिहरू आवश्यक पर्ने अपरेटरहरूमा मात्र सीमित राख्नुहोस्, हरेक प्रयोगकर्तालाई एन्डपोइन्टको पहुँच नियम पुनःलेखन गर्ने क्षमता दिनुको सट्टा।
एन्डपोइन्टले समर्थन गर्ने विधिहरूबाट छान्नुहोस्
AWS Client VPN ले प्रमाणपत्र-आधारित पारस्परिक प्रमाणीकरण, Active Directory प्रमाणीकरण र SAML-आधारित संघीय प्रमाणीकरण स्वीकार गर्छ। तपाईंले कुनै पनि क्लाइन्ट विधि रोज्नुभए पनि सर्भर प्रमाणपत्र आवश्यक हुन्छ, र विधिहरू संयोजन गर्ने कन्फिगरेसनले दुवै सफल हुनुपर्छ, एउटा होइन।
| Client method | What the user presents | Where the work sits |
|---|---|---|
| Mutual certificate | A client certificate the endpoint trusts | Certificate authority, issuing and revoking per user |
| Active Directory | Domain credentials | Directory reachable from the endpoint's VPC |
| SAML federation | An assertion from an identity provider | IdP application, attribute mapping, client support |
प्रमाणपत्रहरू स्थापना गर्न सबैभन्दा सस्तो र ठूलो मात्रामा गल्ती गर्न सबैभन्दा सजिलो हुन्छन्, किनभने हरेक प्रयोगकर्तालाई प्रमाण आवश्यक हुन्छ र हरेक बहिर्गमनका लागि रद्द गर्नु आवश्यक हुन्छ। डाइरेक्टरी प्रमाणीकरणले त्यो जीवनचक्र विद्यमान प्रणालीमा सार्छ। संघले यसलाई पहिचान प्रदायकमा सार्छ र क्लाइन्टमा ब्राउजर चरण थप्छ।
क्लाइन्ट डिबग गर्नु अघि एन्डपोइन्टको आफ्नै कन्फिगरेसन पढ्नुहोस्। यदि प्रयोगकर्ता-आधारित विधिसँगै पारस्परिक प्रमाणीकरण सक्षम छ भने, वैध प्रमाणपत्र भए पनि डाइरेक्टरी खाता नभएको क्लाइन्ट अझै असफल हुनेछ, र त्रुटि सामान्यतया सामान्य ह्यान्डशेक समस्याजस्तो देखिन्छ।
संघ पहुँच कुञ्जीहरू पास गर्नु होइन
SAML सेटअपले IAM पहुँच कुञ्जी वा ग्रहण गरिएको भूमिकाको टोकन टनेलमा हाल्दैन। पहिचान प्रदायकले व्यक्तिलाई प्रमाणित गर्छ, दाबी फर्काउँछ, र एन्डपोइन्टले तपाईंले कन्फिगर गरेको विश्वासअन्तर्गत स्वीकार गर्छ। परिणामस्वरूप प्राप्त सत्र VPN सत्र हो, AWS API सत्र होइन।
यही भिन्नताले को के निदान गर्न सक्छ निर्धारण गर्छ। IdP समस्याहरू कुनै टनेल हुनु अघि नै ब्राउजर वा क्लाइन्ट त्रुटिका रूपमा देखिन्छन्, जबकि टनेल समस्याहरू सफल दाबीपछि देखिन्छन्। कुनै पनि कन्सोल खोल्नु अघि तपाईं यी दुईमध्ये कुन हेर्दै हुनुहुन्छ सोध्नुहोस्।
लगइनपछि पनि मार्ग र अनुमतिले निर्धारण गर्छन्
प्रमाणीकरणले सत्रलाई ठेगाना दिन्छ; यसले सत्रलाई गन्तव्य दिँदैन। एन्डपोइन्टका मार्गहरूले क्लाइन्टलाई कुन सबनेटमा पठाउने भनी बताउँछन्, अनुमति नियमहरूले कुन प्रयोगकर्ताहरू ती सबनेटमध्ये कुनमा पुग्न सक्छन् निर्धारण गर्छन्, र सुरक्षा समूहहरू तथा लक्ष्यका आफ्नै अनुमतिहरूले बाँकी निर्धारण गर्छन्।
त्यसैले सफलतापूर्वक प्रमाणित प्रयोगकर्ता पनि डेटाबेसमा पुग्न असफल हुन सक्छ। सबनेटको मार्ग तालिका संबद्धता, प्रयोगकर्ताको समूहको अनुमति नियम र लक्ष्यमा रहेको सुरक्षा समूह यही क्रममा जाँच्नुहोस्, किनभने प्रत्येकले फरक प्रकारको समयसमाप्ति उत्पन्न गर्छ।
एक निजी डेटाबेसका लागि, पोर्ट फर्वार्डिङसँग तुलना गर्नुहोस्
यदि वास्तविक काम एक निजी डेटाबेसमा एक स्वीकृत जडान हो भने, पूर्ण नेटवर्क टनेल आवश्यकता होइन, विकल्प हो। AWS Systems Manager Session Manager ले IAM मार्फत व्यवस्थापित नोडमा पोर्ट फर्वार्डिङ सत्र खोल्न सक्छ, र त्यो नोड निजी नेटवर्कमा डेटाबेसमा पुग्छ। प्रयोगकर्ताले कहिल्यै VPC ठेगाना पाउँदैन। व्यवस्थापित नोड डेटाबेस पोर्टमा पुग्न सक्ने एकमात्र होस्ट बन्छ, र सुरक्षा समीक्षाले सामान्यतया यही मागेको थियो। त्यसपछि प्रयोगकर्ताहरूलाई VPN प्रोफाइलको सट्टा स्थानीय क्लाइन्ट र सत्र आदेश चाहिन्छ।
व्यापार व्याप्ति र पूर्वसर्तहरूको हो। पोर्ट फर्वार्डिङका लागि व्यवस्थापित नोडमा SSM एजेन्ट, त्यो नोडबाट डेटाबेसमा नेटवर्क पहुँच, प्रयोगकर्ताको मेसिनमा Session Manager प्लगइन र त्यो विशिष्ट सत्र सुरु गर्ने अनुमति चाहिन्छ। यो हरेक सबनेटमा प्रवेशको मार्ग होइन, र टनेलजस्तै स्वेच्छाचारी प्रोटोकलहरू बोक्दैन।
जुनसुकै अवस्थामा डेटाबेसको आफ्नै पहिचान यथावत् राख्नुहोस्। मार्ग IAM द्वारा अनुमोदित भयो भन्दैमा TLS प्रमाणीकरण र डेटाबेस प्रमाणीकरण हराउँदैन, र स्वीकृत सत्रले प्रयोगकर्ताले कुन तालिका पढ्न सक्छ भन्नेबारे केही भन्दैन।
व्याप्ति र जीवनचक्रका आधारमा छान्नुहोस्: धेरै प्रयोगकर्तालाई धेरै गन्तव्य चाहिँदा र तपाईंले प्रमाणपत्र वा डाइरेक्टरी जीवनचक्र चलाउन सक्नुहुन्छ भने टनेल; थोरै मानिसलाई एक सेवा चाहिँदा र नेटवर्क ठेगाना बाँड्न नचाहँदा फर्वार्डिङ सत्र। जुनसुकै अवस्थामा, प्रमाणीकरण विधि, अनुमति नियम र डेटाबेस लगइन तीन अलग तथ्यका रूपमा लेख्नुहोस्, किनभने ती छुट्टाछुट्टै असफल हुन्छन्।