Android IKEv2 विश्वास त्रुटि: मूल होइन, मध्यवर्ती CA पठाउनुहोस्
प्राप्त श्रृंखला चाँडै टुट्ने भएकाले फोनले गेटवेलाई अस्वीकार गर्छ। मध्यवर्ती पठाउने, पहिचान सुधार्ने वा कुञ्जी प्रकार बदल्ने निर्णय गर्नुहोस्।
फोनले जडान गर्न अस्वीकार गर्छ र No trusted RSA public key found for vpn.example.net प्रिन्ट गर्छ, जबकि त्यही गेटवे प्रमाणपत्र त्यही नेटवर्कको ल्यापटपबाट काम गर्छ। प्रमाणपत्र पुनः जारी गर्नु लोभलाग्दो कदम हो। त्यो गर्नु अघि, तपाईंसँग तीनमध्ये कुन विफलता छ पत्ता लगाउनुहोस्, किनकि तीमध्ये एक मात्र प्रमाणपत्रको सामग्रीसँग सम्बन्धित छ। सन्देशले अपूर्ण श्रृंखला, पहिचानको बेमेल र असमर्थित कुञ्जी वा हस्ताक्षर समेट्छ, र प्रत्येकको फरक समाधान छ।
एउटै सन्देश पछाडिका तीन विफलता
Android गेटवे प्रमाणपत्रबाट VPN प्रोफाइलमा छानिएको CA सम्म श्रृंखला बनाउँछ, त्यसपछि सर्भरको नाम प्रोफाइलसँग तुलना गर्छ। सूचनाले चरण होइन, नतिजा जनाउँछ। विश्वास विफलता भन्नाले आदानप्रदानमा दिइएका प्रमाणपत्रबाट श्रृंखला पूरा गर्न सकिएन भन्ने हो; पहिचान विफलता भन्नाले श्रृंखला प्रमाणित भयो तर नाम मिलेन भन्ने हो; एल्गोरिदम विफलता भन्नाले उपकरण वा प्रोफाइलले कुञ्जी प्रकार वा हस्ताक्षर स्वीकार गर्दैन भन्ने हो।
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
समाधानहरू क्रमैसँग प्रयास गर्नुको सट्टा प्रमाणसहित निर्णय गर्नुहोस्। डेमनविरुद्ध लग स्तर 2 मा एक प्रयासले तपाईं कुन पङ्क्तिमा छ भनेर बताउँछ, र कहिल्यै गलत नभएको प्रमाणपत्र पुनः जारी गर्नुभन्दा कम खर्च हुन्छ।
पहिले निर्णय गर्नुहोस्: पूरै श्रृंखला आयो?
strongSwan त्यो जडानका लागि कन्फिगर गरिएको प्रमाणपत्र पठाउँछ, र मध्यवर्तीहरू अलग प्रमाणहरू हुन्। डेमनले तिनलाई पेलोडमा राख्नु अघि तिनीहरू CA प्रमाणपत्रका रूपमा लोड गर्नुपर्छ, त्यसैले सर्भर प्रमाणपत्र मध्यवर्तीले हस्ताक्षर गरेको, मूल विश्वास एङ्कर भएको, र मध्यवर्ती CA को बिल्ड डाइरेक्टरीमा मात्र रहेको संरचनाले ठ्याक्कै यही विफलता उत्पन्न गर्छ: तारमा पात मात्र, फोनमा श्रृंखला चाँडै टुट्छ।
swanctl तैनातीमा swanctl --list-certs वा पुरानो starter सँग ipsec listcerts प्रयोग गरी डेमनसँग के छ जाँच्नुहोस्। मध्यवर्ती त्यसमाथि मूल भएको CA प्रमाणपत्रका रूपमा देखिनुपर्छ। यदि छैन भने कुनै क्लाइन्ट विकल्पले सहयोग गर्दैन; यदि छ भने अर्को प्रश्नमा जानुहोस्।
त्यसपछि यो पठाइन्छ कि भनेर जाँच्नुहोस्। swanctl.conf सन्दर्भ ले send_cert कागजात गर्छ, जसको पूर्वनिर्धारित ifasked साथीले मागेपछि मात्र प्रमाणपत्र पठाउँछ; always जहिल्यै पठाउँछ। पुरानो समतुल्य ipsec.conf मा leftsendcert=always हो। त्यो सेटिङले पठाउने काम नियन्त्रण गर्छ, उपलब्धता होइन, त्यसैले डेमनले कहिल्यै लोड नगरेको मध्यवर्तीको क्षतिपूर्ति गर्न सक्दैन।
श्रृंखला छोटो भए, डेमनले खोज्ने ठाउँमा मध्यवर्ती लोड गर्नुहोस्
मध्यवर्तीलाई पातको छेउमा होइन, CA डाइरेक्टरीमा राख्नुहोस्: ipsec.conf सेटअपका लागि /etc/ipsec.d/cacerts, swanctl का लागि /etc/swanctl/x509ca, वा तपाईंको प्याकेजले प्रतिस्थापन गर्ने बाटो। कन्फिगरेसन पुनः लोड गर्नुहोस् र प्रमाणपत्रहरू फेरि सूचीबद्ध गर्नुहोस्। केही संस्करणले पात फाइलभित्र श्रृंखला समेटिएको बन्डल पनि पठाउँछन्, तर CA डाइरेक्टरी संस्करण र प्याकेजहरूमा सार्न मिल्ने व्यवस्था हो।
क्लाइन्ट पक्षबाट पनि प्रमाणित गर्नुहोस्। फोनले आदानप्रदानले ल्याएको मात्र देख्छ, त्यसैले लग स्तर 2 को डेमन लगले पठाइएका प्रमाणपत्रहरूमा मध्यवर्ती देखाउनुपर्छ। लगले देखाए पनि फोन असफल भइरहेको छ भने, तपाईं तालिकाको अर्को पङ्क्तिमा हुनुहुन्छ, र CA फाइलहरू समायोजन गरिरहनुले नतिजा बदल्दैन।
श्रृंखला पूर्ण भए, प्रमाणपत्र सम्पादन गर्न रोक्नुहोस्
पहिचान विफलता भन्नाले VPN प्रोफाइलको नाम र प्रमाणपत्रको नामबीचको बेमेल हो। Android ले तपाईंले कन्फिगर गरेको सर्भर पहिचानलाई यसले प्रमाणित गरेको प्रमाणपत्रसँग तुलना गर्छ, त्यसैले प्रमाणपत्रले होस्टनाम भनिरहँदा ठेगानातर्फ देखाउने प्रोफाइल, वा प्रमाणपत्रले समेट्ने होस्टनाम नभएको नाम राख्ने प्रोफाइल, सफल श्रृंखला प्रमाणीकरणपछि असफल हुन्छ। गलत पक्ष सुधार्नुहोस्, र कुनै एक परिवर्तन हुँदा प्रोफाइल र प्रमाणपत्र मिलाएर राख्नुहोस्।
एल्गोरिदम विफलता वैध श्रृंखला र मिल्ने नामसँग देखिन्छ। Android संस्करणहरू कुन कुञ्जी प्रकार र हस्ताक्षर योजना स्वीकार गर्छन् भन्नेमा फरक हुन्छन्, र प्रोफाइल प्रकार आफैंले विकल्पहरू सीमित गर्छ। गेटवेले पुरानो वा असामान्य संयोजन प्रयोग गरेको भए, प्रमाणपत्र बिग्रिएको मान्नु अघि उपकरणले समर्थन गर्नेसँग तुलना गर्नुहोस्। डेमन लगले विश्वासको अवस्थाभन्दा ह्यान्डशेक अगाडि बढेको देखाउनेछ, जुन श्रृंखला अब समस्या नभएको सङ्केत हो।
मध्यवर्तीलाई फोनमा प्रयोगकर्ता मूलका रूपमा स्थापना नगर्नुहोस्
हराइरहेको मध्यवर्तीलाई फोनमा प्रयोगकर्ता प्रमाणपत्रका रूपमा स्थापना गर्दा चेतावनी हराउँछ र प्रयोगकर्ता-स्थापित मूल स्वीकार गर्ने हरेक एपका लागि फोनको विश्वास मोडेल बदलिन्छ। यसले अर्को क्लाइन्टमा पर्ने डेलिभरी बग पनि लुकाउँछ, र गेटवेले भविष्यका हरेक उपकरणलाई अपूर्ण श्रृंखला पठाइरहन्छ। टिकाउ समाधान सर्भरमा, एक पटक, सबै क्लाइन्टका लागि हो।
परिवर्तन अभिलेखमा तीन निर्णय अलग राख्नुहोस्: कुन प्रमाणपत्र पठाइयो, कुन पहिचान तुलना गरियो, र कुन एल्गोरिदम वार्ता गरियो। सधैं आफ्नो पूरा श्रृंखला पठाउने गेटवे, प्रमाणपत्रको सही नाम राख्ने प्रोफाइल, र फ्लीटले समर्थन गर्ने कुञ्जी प्रकार — यी तीन साना तथ्य हुन्, र यो सम्पूर्ण विफलता यत्ति नै हो।