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 आवृत्त्या कोणते की प्रकार आणि स्वाक्षरी योजना स्वीकारतात यात भिन्न आहेत, आणि प्रोफाइल प्रकार स्वतः पर्याय मर्यादित करतो. गेटवे जुना किंवा असामान्य संयोजन वापरत असेल, तर प्रमाणपत्र खराब आहे असे गृहीत धरण्यापूर्वी उपकरण काय समर्थन देते त्याशी तुलना करा. डीमन लॉग विश्वासाच्या बाबतीतपेक्षा हँडशेक पुढे जात असल्याचे दाखवेल, हाच साखळी आता समस्या नाही याचा संकेत आहे.
मध्यस्थ फोनवर वापरकर्ता मूळ म्हणून स्थापित करू नका
गहाळ मध्यस्थ फोनवर वापरकर्ता प्रमाणपत्र म्हणून स्थापित केल्याने इशारा अदृश्य होतो आणि वापरकर्ता-स्थापित मुळे स्वीकारणाऱ्या प्रत्येक अॅपसाठी फोनचे विश्वास मॉडेल बदलते. पुढील क्लायंटला होणारी वितरण त्रुटीही ते लपवते, आणि गेटवे प्रत्येक भविष्यातील उपकरणाला अपूर्ण साखळी पाठवत राहतो. टिकाऊ दुरुस्ती सर्व्हरवर, एकदा, सर्व क्लायंटसाठी आहे.
बदल नोंदीत तीन निर्णय वेगळे ठेवा: कोणती प्रमाणपत्रे पाठवली, कोणती ओळख तपासली आणि कोणता अल्गोरिदम वाटाघाटीत ठरला. नेहमी आपली पूर्ण साखळी पाठवणारा गेटवे, प्रमाणपत्राला योग्य नाव देणारे प्रोफाइल आणि फ्लीटला समर्थन असलेला की प्रकार — ही तीन छोटी तथ्ये आहेत, आणि ही संपूर्ण अयशस्वीता एवढीच आहे.