Mac VPN प्रमाणपत्र: गेटवे कोणते खाते पाहतो?
प्रोफाइल लेबल, क्रेडेन्शियल आणि खाते फील्ड वेगवेगळ्या प्रश्नांची उत्तरे देतात। काहीही नाव बदलण्यापूर्वी प्रिन्सिपलपासून गेटवेच्या मॅपिंगपर्यंत जा।
प्रोफाइल तुमचे नाव दाखवते, प्रमाणपत्राचे दृश्य लेबल काहीतरी वेगळे सांगते, आणि गेटवेचा लॉग तिसरा ओळखकर्ता नोंदवतो। त्यापैकी कोणीही खोटे बोलत नाही, आणि हीच समस्या आहे: तीन वेगवेगळी फील्ड एकाच प्रश्नाची उत्तरे देत असल्यासारखी वाचली जात आहेत। कनेक्शन क्रेडेन्शियल, IKEv2 ओळखकर्ता आणि खाते सादर करते, आणि त्यापैकी कोणते कशाला अधिकृत करते हे गेटवे ठरवते।
एका कनेक्शनमध्ये तीन ओळखी।
दृश्य प्रोफाइल नाव हे लोकांसाठी लेबल आहे। ते कनेक्शन निवडते आणि त्यापलीकडे काही नाही। प्रमाणपत्र हे क्रेडेन्शियल आहे, आणि ते काही सिद्ध करू शकते का हे क्लायंटकडे जुळणारी खाजगी की आहे का यावर अवलंबून आहे। खाते फील्ड हे प्रिन्सिपलबद्दलचे विधान आहे, आणि सर्व्हरला ते वेगळ्या स्थानिक ओळखीवर मॅप करण्याचे स्वातंत्र्य आहे।
प्रमाणीकरण अयशस्वी झाल्यावर, त्रुटी तीनपैकी कोणत्याशी संबंधित आहे ते विचारा। नाकारलेले क्रेडेन्शियल, अज्ञात ओळखकर्ता आणि निष्क्रिय खाते वेगवेगळे संदेश तयार करतात, आणि त्यांना एकच «प्रमाणपत्र समस्या» मानल्यास तुम्ही चुकीच्या कन्सोलवर पोहोचता।
मूळ फील्ड त्यांच्या कामानुसार वाचा।
व्यवस्थापित मूळ IKEv2 कॉन्फिगरेशनमध्ये, Apple चा पेलोड संदर्भ मूल्ये वेगळी करतो, आणि प्रमाणीकरण पद्धत कोणते संयोजन आवश्यक आहे ते ठरवते:।
| Field | Identifies | Common misreading |
|---|---|---|
| AuthName | Username for the configured arrangement | Assuming it is the certificate subject |
| LocalIdentifier | IKEv2 client identifier | Assuming it must equal the username |
| PayloadCertificateUUID | Referenced credential payload | Assuming any installed certificate will do |
प्रमाणपत्र आणि EAP लॉगिन एकाच कनेक्शनमध्ये वेगवेगळ्या भूमिका घेऊ शकतात। त्यापैकी एक तसे करतो म्हणून प्रत्येक फील्डला तोच मजकूर ठेवण्यास भाग पाडू नका, आणि एक बदलल्याने बाकीचे रद्द होतील असे गृहीत धरू नका। तृतीय-पक्ष VPN ॲप पूर्णपणे वेगळे मॉडेल दाखवू शकते; मूळ फील्ड नावे तिथे नेण्याऐवजी तिची नोंदवलेली ओळख-निवड वापरा।
सर्व्हर प्रमाणपत्र ही क्लायंट ओळख नाही।
गेटवेची पडताळणी करणारे प्रमाणपत्र हे विश्वासाचे नांगर आहे। तुम्ही अपेक्षित सर्व्हरवर पोहोचलात हे ते सिद्ध करते। क्लायंट ओळख ही वेगळी वस्तू आहे: जोडणारा पक्ष जो असल्याचा दावा करतो तोच आहे हे सिद्ध करणाऱ्या खाजगी कीपर्यंत प्रवेश त्यात समाविष्ट आहे। दृश्य खात्याचे नाव बदलल्याने एकाचे दुसरे होऊ शकत नाही।
इथेच सद्भावी दुरुस्ती चुकते। गेटवेचे CA प्रमाणपत्र क्लायंट स्टोअरमध्ये आयात केल्याने क्लायंट प्रमाणीकरणासाठी काहीही होत नाही, आणि त्या नोंदीवर वापरकर्त्याचे नाव लावल्याने ती वापरकर्ता ओळख होत नाही। दोन्ही वस्तू प्रोफाइलच्या वेगवेगळ्या भागांत राहतात आणि वेगवेगळ्या प्रश्नांची उत्तरे देतात।
प्रिन्सिपलपासून गेटवेच्या मॅपिंगपर्यंत जा।
क्रेडेन्शियल कशासाठी दिले गेले हे तपासा: या वापरकर्त्यासाठी, या उपकरणासाठी किंवा सामायिक भूमिकेसाठी। Mac लॉगिन खाते आपोआप ते प्रिन्सिपल नसते, आणि दुसऱ्या मशीनवरून कॉपी केलेले प्रमाणपत्र ज्या मशीनसाठी ते दिले गेले त्या मशीनची ओळख टिकवते।
मग लेबल नाही, प्रत्यक्ष क्रेडेन्शियलची तुलना करा। जारीकर्ता, अनुक्रमांक आणि बोटांची छाप तुम्हाला आणि प्रशासकाला एकाच वस्तूबद्दल बोलत आहात याची खात्री करू देतात। दाखवलेली नावे संपादनीय असतात आणि अनेकदा डुप्लिकेट होतात, त्यामुळे घटनेच्या वेळी ती सर्वात वाईट ओळखकर्ता ठरतात।
शेवटची पायरी गेटवेवर आहे। त्याच्या मालकाला एक कनेक्शन सादर केलेल्या ओळखकर्त्यांशी आणि ते वापरणाऱ्या खाते-मॅपिंग नियमाशी सहसंबंधित करण्यास सांगा। क्लायंट-बाजूचे लेबल सर्व्हरने काय ठरवले हे स्थापित करू शकत नाही, आणि प्रमाणपत्र निष्क्रिय खात्यावर मॅप करणारा नियम क्लायंटची सर्व फील्डे बरोबर दिसत असतानाही अयशस्वी होईल।
ही विसंगती असलेला स्तर दुरुस्त करा।
प्रोफाइल चुकीच्या क्रेडेन्शियलकडे निर्देश करत असल्यास त्याचा संदर्भ किंवा निवड दुरुस्त करा। क्रेडेन्शियल दुसऱ्या प्रिन्सिपलचे असल्यास लेबल संपादित करण्याऐवजी जारीकर्त्याच्या पुनर्नोंदणीतून जा। गेटवे वैध क्रेडेन्शियल चुकीच्या खात्याशी जोडत असल्यास त्याच्या धोरण-मालकाने मॅपिंग दुरुस्त करणे आवश्यक आहे। हे तीन वेगळे बदल आहेत, तीन वेगळ्या मंजूरकर्त्यांसह।
नूतनीकरणही तितक्याच काळजीचे पात्र आहे। प्रमाणपत्र बदलणे, त्याचे दृश्य लेबल बदलणे आणि एखाद्या व्यक्तीला खाते प्रणालींमध्ये हलवणे याचा मॅपिंगवर त्याच पद्धतीने परिणाम होईलच असे नाही। तीनपैकी तुम्ही काय बदलले ते नोंदवा, कारण पुढील अपयश क्लायंटकडून सारखेच आणि गेटवे लॉगमध्ये वेगळे दिसेल।
समर्थनाला आवश्यक असलेले किमान सार्वजनिक ओळखकर्तेच सामायिक करा। खाजगी की किंवा संपूर्ण ओळख बंडल कधीही त्या देवाणघेवाणीचा भाग नसते, निदान कितीही सोयीचे झाले तरी।