AWS Client VPN: सर्व्हर प्रमाणपत्र विरुद्ध क्लायंट प्रमाणपत्राची भूमिका
एंडपॉइंटचे सर्व्हर प्रमाणपत्र सेवेची खात्री देते. परस्पर प्रमाणीकरण सर्व्हरची किल्ली सामायिक न करता प्रत्येक क्लायंटची ओळख आणि CA वरील विश्वास जोडते.
Client VPN एंडपॉइंटला नेहमी TLS सर्व्हर प्रमाणपत्र लागते. हीच ती ओळख आहे जी व्यवस्थापित एंडपॉइंट क्लायंट जोडताना सादर करते. ही वैयक्तिक क्लायंट परस्पर प्रमाणीकरणाच्या वेळी सादर करतात त्या प्रमाणपत्रांपेक्षा वेगळी वस्तू आहे. या दोन्हींची गल्लत करणे हेच बाकी सर्व बरोबर ACM संरचना पहिल्याच जोडणीवर अयशस्वी होण्याचे सर्वात सामान्य कारण आहे.
खाली कन्सोलपासून बाहेरच्या दिशेने, जोडणी प्रत्यक्षात ज्या क्रमाने जाते त्याच क्रमाने एक फेरी आहे.
दोन भूमिका, एक एंडपॉइंट
एंडपॉइंटकडे सर्व्हरची ओळख आहे आणि ऐच्छिकपणे क्लायंट ओळखी तपासण्याचा मार्गही. हे वेगवेगळे संरचित केले जातात. एक ठरवते क्लायंट सेवेवर विश्वास ठेवू शकतो का; दुसरे ठरवते की सेवा क्लायंट स्वीकारते का.
| Material | Purpose | Where it lives |
|---|---|---|
| Server certificate and private key | The managed endpoint proves its TLS identity | ACM, in the endpoint's Region |
| Client certificate and matching key | An individual client proves its identity | On the device |
| CA trust material | The verifier checks the issuer chain | Selected 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 ने क्लायंट प्रमाणपत्र जारी केले आणि एंडपॉइंट प्रत्यक्षात कोणती प्रमाणीकरण पद्धत वापरते ते लिहा. तीन ओळींची नोंद पुढील नूतनीकरणाला तपासणीऐवजी काम बनवते.