macOS मा, IKEv2 क्लाइन्ट सेटिङमा ECDSA छनोटले साँघुरो प्रश्नको उत्तर दिन्छ: कुन प्रमाणपत्रले Mac को पहिचान प्रमाणित गर्छ। यसले गेटवे प्रमाणपत्र, क्लाइन्ट प्रमाणपत्र जारी गर्ने हस्ताक्षर, वा सुरुङको इन्क्रिप्शन प्रस्ताव वर्णन गर्दैन। यी चार भूमिकालाई एउटै अनुकूलता प्रश्न मान्नु भनेको सही स्थानीय सेटिङमाथि सर्भर-पक्षको असमञ्जस्यको दोष आउने बाटो हो। निर्णय सानो छ, तर यो लिन प्रयोग हुने प्रमाणहरू सटीक हुनुपर्छ।

यो फिल्डले एउटा प्रमाणपत्रको नाम दिन्छ: स्थानीय पहिचान

Apple को Network Extension API ले क्लाइन्ट प्रमाणपत्रका लागि प्रमाणपत्र प्रकार दिन्छ, जसमा NEVPNIKEv2CertificateType.ECDSA256 पनि छ, जसलाई ECDSA p-256 प्रमाणपत्र प्रकारका रूपमा अभिलेख गरिएको छ। यो गुण identityReference वा identityData मार्फत दिइएको प्रमाणपत्रमा लागू हुन्छ।

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

व्यवस्थापित प्रोफाइलहरूले IKEv2 पेलोडको CertificateType मार्फत त्यही निर्णय लिन्छन्, साथमा PayloadCertificateUUID जस्तो प्रमाणपत्र सन्दर्भ। ती फिल्डहरूमा लक्ष्य OS संस्करणका लागि पूर्वसर्त र स्किमा छन्; प्रोफाइलमा प्रतिलिपि गरिएको नाङ्गो प्रकार-मान स्थापना गर्न मिल्दैन, र सेटिङ विन्डोले हरेक API विकल्प देखाउन सक्दैन। तैनाथी अघि त्यो संस्करणका लागि पेलोडका पूर्वसर्त जाँच्नुहोस्।

प्रमाणपत्रको लेबलले होइन, भूमिकाले निर्णय गर्नुहोस्

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

What you inspectedWhat it controlsDoes it choose the Mac certificate type?
Client leaf public keyThe identity the Mac presentsYes, this is the field's subject
Issuer signature algorithmHow the client certificate was signedNo
Gateway certificateWhat the Mac validates as the peerNo, check it separately
IKE and ESP proposalsAlgorithms for the tunnelNo, separate proposal settings

यदि प्रमाणपत्र दर्शकले CA बाट ECDSA हस्ताक्षर देखाउँछ भने त्यो जारीकर्ताको हस्ताक्षर कुञ्जी वर्णन गर्छ। क्लाइन्टको आफ्नै कुञ्जी अझै RSA हुन सक्छ, र प्रकार-फिल्डले हस्ताक्षर रेखा होइन, क्लाइन्ट कुञ्जीलाई पछ्याउनुपर्छ। यही एउटा भ्रमले "ECDSA कन्फिगर छ तर जडान असफल हुन्छ" भन्ने धेरै प्रतिवेदन व्याख्या गर्छ। केही परिवर्तन गर्नु अघि पातमा रहेको कुञ्जी-प्रकारलाई प्रोफाइलमा छानिएको प्रकारसँग तुलना गर्नुहोस्।

पात पहिचान भएपछि निर्णय सरल हुन्छ: p-256 क्लाइन्ट कुञ्जीका लागि ECDSA256, फरक कुञ्जीका लागि अर्को समर्थित प्रकार। यदि क्लाइन्ट प्रमाणपत्र र त्यसको कुञ्जी मिल्दैन भने VPN प्रोफाइल बदल्नु अघि त्यो जोडी सुधार्नुहोस्।

गेटवे प्रमाणपत्र छुट्टै निर्णय हो

गेटवेले आफ्नै प्रमाणपत्र प्रस्तुत गर्छ र Mac ले यसलाई विश्वास एङ्कर र अपेक्षित नामविरुद्ध प्रमाणित गर्छ। त्यो प्रमाणपत्रले ECDSA, RSA वा अर्को कुञ्जी-प्रकार प्रयोग गर्छ कि भन्ने सर्भरको गुण हो, क्लाइन्ट पहिचान सेटिङको होइन।

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

यदि गेटवे प्रमाणपत्र नै समस्या हो भने, लक्षण सामान्यतया पहिचान छनोटमा होइन, सहकर्मी प्रमाणीकरणका क्रममा देखिन्छ. क्लाइन्ट प्रकार बदल्नु अघि असफलताको चरण पढ्नुहोस्, किनकि विश्वास असफलता र क्लाइन्ट-कुञ्जी असमञ्जस्यको उपाय एउटै हुँदैन।

जारीकर्ताको हस्ताक्षर र कुञ्जी-सहमति समूह क्लाइन्टको प्रकार होइन

X.509 ले विषयको सार्वजनिक कुञ्जी र जारीकर्ताको हस्ताक्षर फरक फिल्डमा राख्छ। विषय सार्वजनिक कुञ्जी जानकारीले प्रमाणपत्रमा रहेको कुञ्जी वर्णन गर्छ; हस्ताक्षर एल्गोरिदमले CA को कुञ्जी र हस्ताक्षर कार्य वर्णन गर्छ। प्रमाणपत्र-प्रकार सेटिङसँग पहिलो मात्र मिल्छ।

IKE र Child SA प्रस्ताव अर्को अक्ष हो। ECDSA प्रमाणपत्र प्रकार ESP इन्क्रिप्शनको छनोट होइन, र कुञ्जी-सहमति समूह बदल्दा प्रमाणपत्र प्रकार छानिँदैन। प्रोफाइलमा मान्य प्रस्ताव र गलत पहिचान-प्रकार हुन सक्छ, वा सही पहिचान-प्रकार र सहकर्मीले अस्वीकार गर्ने प्रस्ताव हुन सक्छ।

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

तपाईंले कन्फिगर गरेका फिल्डहरूले निर्णय जाँच्नुहोस्

प्रोफाइलले वास्तवमा सन्दर्भ गर्ने पहिचान जाँच्नुहोस्, त्यसपछि त्यो सन्दर्भको प्रमाणपत्रमा अपेक्षित सार्वजनिक कुञ्जी र प्रयोगयोग्य निजी कुञ्जी छ भनी पुष्टि गर्नुहोस्। UI मा देखाइएको प्रकार, सन्दर्भित प्रमाणपत्र र उपकरणको कुञ्जी मिल्नुपर्छ।

त्यसपछि गेटवे इनपुट पुष्टि गर्नुहोस्: अपेक्षित सर्भर नाम, विश्वास एङ्कर र IKE प्रमाणीकरण विधि। अन्तमा जडान गर्नुहोस् र ह्यान्डशेक कहाँ रोकिन्छ पढ्नुहोस्। पहिचानको आदानप्रदान अघिको असफलता यो सेटिङबाट पर सङ्केत गर्छ; सहकर्मी प्रमाणीकरणको असफलता गेटवेतर्फ सङ्केत गर्छ।

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

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