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 प्रमाणीकरण दस्तऐवज कोणते प्रमाणपत्र कोणती भूमिका बजावते ते सूचीबद्ध करते, आणि प्रमाणपत्र हीच समस्या आहे असे गृहीत धरण्यापूर्वी ते तपासणे योग्य आहे। पुन्हा आयात काहीही बदलत नसेल आणि एंडपॉइंट अजूनही रीसेट होत असेल, तर संबंधच संशयित आहे आणि उत्तर नोंदवलेल्या मापदंडांवरून बांधलेले नवीन एंडपॉइंट आहे। एंडपॉइंट नवीन ऑब्जेक्ट घेत असेल, तर संबंध आधीच बरोबर होता आणि दोष क्लायंट साखळीत किंवा अधिकृतता स्तरात आहे।