Client VPN प्रमाणपत्र पुनः आयात गर्न नयाँ इन्डपोइन्ट किन आवश्यक छ

Client VPN जडान टुट्छ, ACM मा प्रमाणपत्र परिवर्तन गरिन्छ, र केही पनि बदलिँदैन। प्रमाणपत्र वस्तु इन्डपोइन्टले प्रयोग गर्दै आएको कुरा कहिल्यै थिएन। इन्डपोइन्टले सिर्जना गर्दा प्रमाणपत्रसँगको सम्बन्ध सुरक्षित राख्छ, सँगै जुन क्लाइन्ट CA विरुद्ध यो प्रमाणित गर्नेछ, प्रमाणीकरणको प्रकार, सबनेट र अधिकार नियमहरू, र यी सम्बन्धहरूमध्ये कुनैमा पनि प्रतिस्थापन प्रमाणपत्र स्वीकार गर्ने परिवर्तन कल छैन। ARN पछाडिका बाइटहरू बदल्नु प्रमाणपत्रको परिवर्तन हो, यसलाई समात्ने इन्डपोइन्टको होइन।

इन्डपोइन्टले प्रमाणपत्र होइन, सन्दर्भहरू सुरक्षित राख्छ

यो संयन्त्र ठ्याक्कै भन्न लायक छ, किनकि यसले सम्पूर्ण असफलता व्याख्या गर्छ। create-client-vpn-endpoint ले सर्भर प्रमाणपत्रको ARN र क्लाइन्ट रुट प्रमाणपत्र चेनको ARN लिन्छ, र परिणामस्वरूप बन्ने इन्डपोइन्टले ती सन्दर्भहरूलाई प्रमाणीकरण विकल्पहरूसँगै स्थिर गुणका रूपमा राख्छ। API ले विद्यमान इन्डपोइन्टमा सर्भर प्रमाणपत्र बदल्ने कुनै अपरेसन दिँदैन।

अनुमान नगरी तपाईं बाँधिने सम्बन्ध पुष्टि गर्न सक्नुहुन्छ। aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 ले प्रमाणपत्रको ARN, क्लाइन्ट रुट चेनको ARN, प्रमाणीकरणको प्रकार, क्लाइन्ट CIDR र सम्बन्धित सबनेटहरू प्रिन्ट गर्छ, जो तपाईंले पुनः उत्पादन गर्नुपर्ने गुणहरूको पूर्ण सेट हो। यसलाई पुनः आयात अघि र पछि चलाउनुहोस्, आउटपुट सर्दैन। पुनः आयातले कहिल्यै मद्दत गर्ने थिएन भन्ने प्रमाण यही हो।

पुनः आयात इन्डपोइन्टसम्म किन पुग्न सक्दैन

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

यसैले लक्षण नेटवर्क खराबीजस्तो सुनिन्छ। अधिकारको मूल्याङ्कन हुनुअघि नै TLS ह्यान्डशेक असफल हुन्छ वा रिसेट हुन्छ, त्यसैले सुरक्षा समूह, मार्ग र अधिकार नियम सबै निर्दोष देखिन्छन्, र ती निर्दोष नै छन्।

चेन क्लाइन्ट प्रमाणपत्रको भाग हो

असफलताको दोस्रो आधा क्लाइन्ट प्रमाणपत्रमा छ, र यसलाई बेवास्ता गर्न सजिलो छ। क्लाइन्ट प्रमाणपत्र त्यसलाई जारी गर्ने चेनसँगै आयात गर्नैपर्छ, आयात फारमले त्यो फिल्ड ऐच्छिक देखाए पनि। चेन बिना इन्डपोइन्टले क्लाइन्ट प्रमाणपत्रबाट जुन क्लाइन्ट रुट CA सँग यो कन्फिगर गरिएको थियो त्यहाँसम्म मार्ग बनाउन सक्दैन, र जडान प्याकेट खसाल्ने फायरवालजस्तो सुनिने नरम रिसेटमा अन्त्य हुन्छ। openssl verify -CAfile root-ca.pem client.crt ले त्यो प्रश्नको उत्तर स्थानीय रूपमा एक सेकेन्डमा दिन्छ, र तपाईंले चलाउनुपर्ने पहिलो कमाण्ड त्यही हुनुपर्छ।

चेनसँगै पुनः आयात त्यो आधाका लागि साँचो सुधार हो, र तैपनि एक्लै पर्याप्त छैन। ACM वस्तु परिवर्तन भइसकेपछि पुरानो सम्बन्ध राख्ने इन्डपोइन्ट परीक्षण जारी राख्नका लागि गलत कुरा हो। दुवै पाइलाहरू एउटै मर्मतका हुन्, त्यसैले दुई-भागको सुधार विरोधाभास होइन।

इन्डपोइन्ट पुनः सिर्जना गर्नु माइग्रेसन हो

प्रतिस्थापन इन्डपोइन्ट सिर्जना गर्नु माइग्रेसन हो, पुनः प्रयास होइन, र यसलाई पुनः प्रयासका रूपमा लिनु नै टोलीहरू आधा कन्फिगर भएका दुई इन्डपोइन्टसम्म पुग्ने बाटो हो। नयाँ इन्डपोइन्टले नयाँ ID पाउँछ र, तपाईंले योजना नबनाएको भए, प्रत्येक प्रयोगकर्ताका लागि नयाँ DNS नाम पाउँछ। क्लाइन्ट प्रोफाइललाई ठेगानातिर होइन, नामतिर देखाउँदै राख्नुहोस्, जसले गर्दा परिवर्तन पुनर्वितरण होइन, रेकर्ड परिवर्तन बनोस्।

यसलाई सुरक्षित राख्ने क्रम छोटो छ: उही CIDR, सबनेट र अधिकार नियमसँग नयाँ इन्डपोइन्ट बनाउनुहोस्, aws ec2 export-client-vpn-client-configuration सँग ताजा प्रोफाइल निर्यात गर्नुहोस्, र एक प्रयोगकर्तासँग प्रमाणित गर्नुहोस्। त्यसपछि मात्र पुरानो इन्डपोइन्ट हट्छ।

पुरानो इन्डपोइन्ट सेवाबाट हटाउने आफ्नै क्रम छ। हटाउनुअघि तपाईंले हटाउने सोचेका क्लाइन्ट प्रमाणपत्रहरू रद्द गर्नुहोस्, किनकि पुरानो CA मा अझै विश्वास गर्ने नयाँ इन्डपोइन्टले तपाईंले गएको ठानेका प्रमाणपत्रहरू स्वीकार गरिरहन्छ। त्यसपछि पुरानो इन्डपोइन्ट हटाउनुहोस् र त्यसका अधिकार नियमहरू हटाउनुहोस्, जसले गर्दा पुरानो प्रोफाइलले तपाईंले बन्द ठानेको लक्ष्य नेटवर्कसँग पुनः जडान गर्न नसकोस्। पुरानो इन्डपोइन्टको ID र सम्बन्ध पहिचानकर्ताहरू परिवर्तन रेकर्डमा लेख्नुहोस्, किनकि सम्झनासँग तुलना गरिएको माइग्रेसन नै काम गर्ने इन्डपोइन्ट दुई पटक पुनः बनाउने बाटो हो।

निदानको क्रम मिलाउनुहोस्

कुनै पनि कन्फिगरेसन बदल्नुअघि तीन असफलता छुट्याउनुहोस्। क्लाइन्टले TLS पूरा गर्न सक्दैन, क्लाइन्टले TLS पूरा गर्छ तर अधिकृत छैन, वा क्लाइन्ट जडान हुन्छ तर गन्तव्यमा पुग्न सक्दैन। प्रमाणपत्रको सम्बन्ध पहिलोसँग सम्बन्धित छ, क्लाइन्ट ठेगाना नढाक्ने अधिकार नियम दोस्रोसँग, र मार्ग वा सुरक्षा समूह तेस्रोसँग, जहाँ इन्डपोइन्ट पुनः सिर्जना गर्नु लगभग सधैं गलत कदम हो।

महिनौं चलेर पछि प्रमाणपत्र वा नीतिको परिवर्तन बिना रोकिएको इन्डपोइन्ट छुट्टै केस हो। उही सेटिङमा पुनः निर्माण गर्दा सेवा फर्कन सक्छ, तर त्यो कन्फिगरेसन पुनःउत्पादनयोग्य राख्ने कारण हो, हरेक घटनामा पुनः बनाउने कारण होइन।

अर्को पुनर्निर्माण तात्कालिक उपाय होइन, diff बनोस् भनेर चार कुरा संस्करण नियन्त्रणमा राख्नुहोस्: इन्डपोइन्ट प्यारामिटर, प्रमाणपत्र र चेनका ARN, अधिकार नियम र क्लाइन्ट CIDR। Client VPN प्रमाणीकरण कागजात ले कुन प्रमाणपत्रले कुन भूमिका खेल्छ सूचीबद्ध गर्छ, र प्रमाणपत्र नै समस्या हो भनी मान्नुअघि त्यो जाँच्न लायक छ। पुनः आयातले केही नबदल्ने र इन्डपोइन्ट अझै रिसेट हुने भए, शंकास्पद सम्बन्ध नै हो र उत्तर रेकर्ड गरिएका प्यारामिटरबाट बनेको नयाँ इन्डपोइन्ट हो। इन्डपोइन्टले नयाँ वस्तु लिन्छ भने, सम्बन्ध पहिले नै सही थियो र दोष क्लाइन्ट चेन वा अधिकार तहमा छ।