प्रोफाइलले तपाईंको नाम देखाउँछ, प्रमाणपत्रको देखिने लेबलले अरू केही भन्छ, र गेटवेको लगले तेस्रो पहिचानकर्ता रेकर्ड गर्छ। तीमध्ये कुनै पनि झुटो बोल्दैन, र यही नै समस्या हो: तीन फरक फिल्डलाई एउटै प्रश्नको जवाफ दिइरहेको जस्तो पढिन्छ। जडानले प्रमाण, IKEv2 पहिचानकर्ता र खाता प्रस्तुत गर्छ, र तीमध्ये कुनले के अधिकृत गर्छ भन्ने गेटवेले निर्णय गर्छ।

एउटै जडानमा तीन पहिचान

देखिने प्रोफाइल नाम मानिसका लागि लेबल हो। यसले जडान छान्छ र अरू केही होइन। प्रमाणपत्र प्रमाण हो, र यसले केही प्रमाणित गर्न सक्छ कि सक्दैन भन्ने क्लाइन्टसँग मिल्ने निजी कुञ्जी छ कि छैनमा निर्भर गर्छ। खाता फिल्ड प्रिन्सिपलबारे दाबी हो, र सर्भरले यसलाई अर्को स्थानीय पहिचानमा म्याप गर्न स्वतन्त्र छ।

प्रमाणीकरण असफल हुँदा, त्रुटि तीनमध्ये कसलाई सन्दर्भित गर्छ सोध्नुहोस्। अस्वीकृत प्रमाण, अज्ञात पहिचानकर्ता र निष्क्रिय खाताले फरक-फरक सन्देश उत्पन्न गर्छन्, र तिनीहरूलाई एउटै «प्रमाणपत्र समस्या» मान्नाले तपाईंलाई गलत कन्सोलमा पठाउँछ।

मूल फिल्डहरू तिनको कामअनुसार पढ्नुहोस्

व्यवस्थित मूल IKEv2 कन्फिगरेसनमा, Apple को पेलोड सन्दर्भले मानहरू अलग गर्छ, र प्रमाणीकरण विधिले कुन संयोजन आवश्यक छ निर्धारण गर्छ:

FieldIdentifiesCommon misreading
AuthNameUsername for the configured arrangementAssuming it is the certificate subject
LocalIdentifierIKEv2 client identifierAssuming it must equal the username
PayloadCertificateUUIDReferenced credential payloadAssuming any installed certificate will do

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

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

गेटवे प्रमाणित गर्ने प्रमाणपत्र विश्वासको एङ्कर हो। तपाईंले अपेक्षा गरेको सर्भरमा पुग्नुभयो भन्ने यसले प्रमाणित गर्छ। क्लाइन्ट पहिचान फरक वस्तु हो: जोडिने पक्षले आफूलाई जस्तो दाबी गर्छ त्यही हो भन्ने प्रमाणित गर्ने निजी कुञ्जीमा पहुँच यसमा समावेश हुन्छ। देखिने खाताको नाम बदल्नाले एउटालाई अर्को बनाउन सक्दैन।

यहीँ सद्भावी सुधार गलत हुन्छ। गेटवेको CA प्रमाणपत्र क्लाइन्ट स्टोरमा आयात गर्दा क्लाइन्ट प्रमाणीकरणका लागि केही हुँदैन, र त्यो प्रविष्टिमा प्रयोगकर्ताको नाम राख्दा त्यो प्रयोगकर्ता पहिचान बन्दैन। दुई वस्तु प्रोफाइलका फरक भागमा बस्छन् र फरक प्रश्नको जवाफ दिन्छन्।

प्रिन्सिपलबाट गेटवेको म्यापिङसम्म पुग्नुहोस्

प्रमाण कुन उद्देश्यका लागि जारी भयो पुष्टि गर्नुहोस्: यो प्रयोगकर्ता, यो यन्त्र वा साझा भूमिकाका लागि। Mac लगइन खाता स्वतः त्यो प्रिन्सिपल होइन, र अर्को मेसिनबाट प्रतिलिपि गरिएको प्रमाणपत्रले त्यो जारी गरिएको मेसिनको पहिचान कायम राख्छ।

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

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

यो बेमेल भएको तह मर्मत गर्नुहोस्

प्रोफाइलले गलत प्रमाण देखाएमा त्यसको सन्दर्भ वा चयन सुधार्नुहोस्। प्रमाण अर्को प्रिन्सिपलको भएमा लेबल सम्पादन गर्नुको साटो जारीकर्ताको पुनः-दर्तामा जानुहोस्। गेटवेले वैध प्रमाणलाई गलत खातासँग बाँध्छ भने त्यसको नीति-मालिकले म्यापिङ सुधार्नुपर्छ। यी तीन फरक परिवर्तन हुन्, तीन फरक स्वीकृतकर्तासहित।

नवीकरणले पनि उही ध्यान पाउनुपर्छ। प्रमाणपत्र फेर्नु, त्यसको देखिने लेबलको नाम बदल्नु र व्यक्तिलाई खाता प्रणालीहरूबीच सार्नुले म्यापिङमा अनिवार्य रूपमा एउटै तरिकाले असर गर्दैन। तीनमध्ये कुन बदल्नुभयो लेख्नुहोस्, किनकि अर्को असफलता क्लाइन्टबाट उस्तै र गेटवे लगमा फरक देखिनेछ।

सहयोगलाई आवश्यक पर्ने न्यूनतम सार्वजनिक पहिचानकर्ता मात्र साझा गर्नुहोस्। निजी कुञ्जी वा पूर्ण पहिचान बन्डल कहिल्यै त्यो आदानप्रदानको भाग होइन, निदान जति सहज भए पनि।

सम्बन्धित लेखहरू