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 प्रमाणीकरण दस्तावेज़ बताता है कि कौन-सा प्रमाणपत्र कौन-सी भूमिका निभाता है, और यह मानने से पहले कि प्रमाणपत्र ही समस्या है, इसे जाँचना उचित है। अगर फिर से आयात कुछ नहीं बदलता और एंडपॉइंट अब भी रीसेट होता है, तो संबंध ही संदिग्ध है और जवाब रिकॉर्ड किए गए पैरामीटर से बना नया एंडपॉइंट है। अगर एंडपॉइंट वास्तव में नया ऑब्जेक्ट उठा लेता है, तो संबंध पहले से सही था और गड़बड़ी क्लाइंट श्रृंखला या प्राधिकरण परत में है।