Client VPN इन्डपोइन्टलाई सधैं TLS सर्भर प्रमाणपत्र चाहिन्छ। यही त्यो पहिचान हो जो व्यवस्थित इन्डपोइन्टले क्लाइन्ट जोडिँदा प्रस्तुत गर्छ। यो ती प्रमाणपत्रहरूभन्दा फरक वस्तु हो जो व्यक्तिगत क्लाइन्टहरूले पारस्परिक प्रमाणीकरणका बेला प्रस्तुत गर्छन्। यी दुईलाई मिसाउनु नै बाँकी सबै ठीक ACM सेटअप पहिलो जडानमै असफल हुनुको सबैभन्दा सामान्य कारण हो।

तल कन्सोलबाट बाहिरतिर, जडान वास्तवमा जुन क्रममा जान्छ त्यही क्रममा एक फेरो छ।

दुई भूमिका, एक इन्डपोइन्ट

इन्डपोइन्टसँग सर्भरको पहिचान छ र वैकल्पिक रूपमा क्लाइन्ट पहिचान जाँच्ने माध्यम पनि। यी अलग-अलग कन्फिगर गरिन्छन्। एकले क्लाइन्टले सेवामा भरोसा गर्न सक्छ कि सक्दैन भन्ने तय गर्छ; अर्कोले सेवाले क्लाइन्ट स्वीकार्छ कि गर्दैन तय गर्छ।

MaterialPurposeWhere it lives
Server certificate and private keyThe managed endpoint proves its TLS identityACM, in the endpoint's Region
Client certificate and matching keyAn individual client proves its identityOn the device
CA trust materialThe verifier checks the issuer chainSelected for the client role

तालिकालाई एउटा प्रमाणपत्रको सट्टा तीन स्वतन्त्र आवश्यकताका रूपमा पढ्नुहोस्। सर्भर प्रमाणपत्र र त्यसको निजी कुञ्जी सेवासँगै रहन्छन्। क्लाइन्ट प्रमाणपत्र र त्यससँग मिल्ने निजी कुञ्जी यन्त्रमा रहन्छ। CA सामग्री भनेको प्रमाणितकर्ताले शृंखला जाँच्न प्रयोग गर्ने कुरा हो। ल्यापटपमा सधैं बीचको पङ्क्ति मात्र पर्छ।

ACM सर्भर प्रमाणपत्रले के गर्छ

इन्डपोइन्ट बनाउँदा सर्भर प्रमाणपत्र ACM मा इन्डपोइन्ट भएकै क्षेत्रमा उपलब्ध हुनुपर्छ। कन्सोलले ARN माग्छ, र त्यो ARN त्यहीँ समाधान हुनुपर्छ। ACM ले डोमेन प्रमाणीकरणसँग दिएको प्रमाणपत्र वा कुञ्जी र शृंखलासँगै आयात गरेको राख्न सक्छ। दुवै यो भूमिकामा काम गर्छन्; फरक नवीकरण र निजी कुञ्जी कसको हातमा छ भन्नेमा छ।

प्रमाणपत्र कसले नवीकरण गर्न सक्छ भन्नेसँग मिल्ने मार्ग रोज्नुहोस्, संयोगवश मान्य देखिने फाइल बनाएको मार्ग होइन।

पारस्परिक प्रमाणीकरणले के थप्छ

प्रमाणपत्रमा आधारित क्लाइन्ट प्रमाणीकरण रोज्दा दोस्रो प्रश्न थप्छ: कुन क्लाइन्टहरू जोडिनै सक्छन्। प्रत्येक क्लाइन्टले आफ्नो प्रमाणपत्र प्रस्तुत गर्छ र मिल्ने निजी कुञ्जी राखेको प्रमाण दिन्छ। अलग-अलग पहिचानले नै पछि छानी रद्द गर्न सम्भव बनाउन्छ। एटा क्लाइन्ट कुञ्जी हरेक यन्त्रमा प्रतिलिपि गर्नु त्यो गुण चुपचाप त्याग गर्नु हो, सर्भर प्रमाणपत्र एकदम राम्रो टारीकाले प्राप्त भएपनि।

इन्डपोइन्टको प्रमाणीकरण विधि एक रोजाइ हो, सार्वभौमिक आवश्यकता होइन।

Active Directory र संघीय प्रमाणीकरणले त्यही प्रश्नको जवाफ अरू साधनले दिन्छन्। पारस्परिक प्रमाणपत्रको विधि ती तैनातीहरूका लागि आफैं लगइन रचना बन्दैन, र प्रयोगकर्तालाई कसरी भित्र ल्याइएपनि सर्भरको TLS प्रमाणीकरण कायम रहन्छ।

एउटै CA ARN कुञ्जी साझा गर्नु किन होइन

AWS ले लेखेको छ कि जब सर्भर र क्लाइन्ट प्रमाणपत्र एउटै CA ले जारी गर्छ, सर्भर प्रमाणपत्रको ARN क्लाइन्ट प्रमाणपत्र छान्न पनि प्रयोग गर्न सकिन्छ। त्यो वाक्य इन्डपोइन्टले प्रमाणीकरणका बेला कुन शृंखलामा भरोसा गर्छ भन्नेबारे हो। यसले क्लाइन्टहरूलाई सर्भरको निजी कुञ्जी प्रयोग गर्न भन्दैन। ल्यापटपलाई अझै आफ्नै क्लाइन्ट प्रमाणपत्र र आफ्नै मिल्ने कुञ्जी चाहिन्छ।

जब क्लाइन्टको CA अर्को जारीकर्ता हुन्छ, लेखिएको मार्ग त्यो CA लाई ACM मा आयात गरी क्लाइन्ट भूमिकाका लागि छान्नु हो।

असफलतालाई चरणसम्म फर्काउनुहोस्

केही पनि बदल्नुअघि कुन चरण असफल भइरहेको छ पहिचान गर्नुहोस्। क्लाइन्टले इन्डपोइन्ट अस्वीकार गरे शंकास्पद सर्भरको ARN वा त्यसको शृंखला हो। इन्डपोइन्टले क्लाइन्ट अस्वीकार गरे क्लाइन्ट प्रमाणपत्र, त्यसको जारीकर्ता र छानिएको प्रमाणीकरण विधि हेर्नुहोस्। सुरुङ उठ्यो र यातायात अझै असफल भयो भने तपाईं प्रमाणपत्रभन्दा अगाडि पुगिसक्नुभयो।

एक पटकमा एटै वस्तु बदल्नुहोस्, किनकि दुवै छेउ एकैचोटि बदल्दा तपाईंले सुरु गरेको त्यही अस्पष्टता फेरि उत्पन्न हुन्छ।

त्यो विशेष भूमिकाका लागि सेवाले समर्थन गर्ने कुञ्जी एल्गोरिदम र आवश्यक विस्तार पनि जाँच्नुहोस्। सार्वजनिक वेबसाइटलाई सन्तुष्ट पार्ने प्रमाणपत्र Client VPN का सबै पहिचान आवश्यकता पूरा भएको प्रमाण होइन।

कुन फाँटले कुन ARN राख्छ, कुन CA ले क्लाइन्ट प्रमाणपत्र जारी गर्यो र इन्डपोइन्टले वास्तवमा कुन प्रमाणीकरण विधि प्रयोग गर्छ लेख्नुहोस्। तीन लाइनको अभिलेखले अर्को नवीकरणलाई जाँचको सट्टा काम बनाउँछ।

सम्बन्धित लेखहरू