फ़ोन कनेक्ट होने से मना कर देता है और No trusted RSA public key found for vpn.example.net छापता है, जबकि वही गेटवे प्रमाणपत्र उसी नेटवर्क पर लैपटॉप से काम करता है। लुभावना कदम प्रमाणपत्र फिर से जारी करना है। उससे पहले तय करें कि तीन में से कौन-सी विफलता है, क्योंकि उनमें से केवल एक प्रमाणपत्र की सामग्री से जुड़ी है।

एक संदेश के पीछे तीन विफलताएँ

Android गेटवे प्रमाणपत्र से VPN प्रोफ़ाइल में चुने गए CA तक श्रृंखला बनाता है, फिर सर्वर का नाम प्रोफ़ाइल से तुलना करता है। सूचना परिणाम बताती है, चरण नहीं। ट्रस्ट विफलता का अर्थ है कि आदान-प्रदान में दिए प्रमाणपत्रों से श्रृंखला पूरी नहीं हो सकी; पहचान विफलता का अर्थ है कि श्रृंखला मान्य है पर नाम मेल नहीं खाता; एल्गोरिद्म विफलता का अर्थ है कि उपकरण या प्रोफ़ाइल कुंजी प्रकार या हस्ताक्षर स्वीकार नहीं करते।

What you seeWhat it points toFirst move
Chain stops after the leaf in the daemon logintermediate not loaded or not sentload the intermediate as CA material
Chain validates, name differs from the profileidentity mismatchfix the profile name or the certificate SAN
Chain validates, handshake still failskey or signature not acceptedcompare key type against the device

क्रम में मरम्मत आज़माने के बजाय प्रमाण से निर्णय लें। डेमन पर लॉग स्तर 2 पर एक प्रयास बताता है कि आप किस पंक्ति में हैं, और यह कभी गलत न रहे प्रमाणपत्र को फिर जारी करने से कम खर्चीला है।

पहले तय करें: क्या पूरी श्रृंखला आई?

strongSwan उस कनेक्शन के लिए तैयार प्रमाणपत्र भेजता है, और इंटरमीडिएट प्रमाणपत्र अलग क्रेडेंशियल हैं। डेमन उन्हें पेलोड में रख सके इससे पहले उन्हें CA प्रमाणपत्र के रूप में लोड करना होता है, इसलिए ऐसी व्यवस्था जिसमें सर्वर प्रमाणपत्र इंटरमीडिएट से हस्ताक्षरित है, रूट ट्रस्ट एंकर है और इंटरमीडिएट केवल CA की बिल्ड निर्देशिका में रहता है, ठीक यही विफलता देती है: तार पर केवल पत्ता और फ़ोन पर श्रृंखला जल्दी समाप्त।

swanctl परिनियोजन पर swanctl --list-certs से, या पुराने स्टार्टर के साथ 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 संस्करण इस बात में भिन्न हैं कि कौन-से कुंजी प्रकार और हस्ताक्षर योजनाएँ स्वीकार करते हैं, और प्रोफ़ाइल प्रकार स्वयं विकल्पों को सीमित करता है। यदि गेटवे पुराना या असामान्य संयोजन उपयोग करता है, तो प्रमाणपत्र को खराब मानने से पहले उपकरण के समर्थन से तुलना करें। लॉग दिखाएगा कि हैंडशेक ट्रस्ट मामले से आगे बढ़ता है, जो संकेत है कि श्रृंखला अब समस्या नहीं है।

फ़ोन पर इंटरमीडिएट को उपयोगकर्ता रूट के रूप में स्थापित न करें

गुम इंटरमीडिएट को फ़ोन पर उपयोगकर्ता प्रमाणपत्र के रूप में स्थापित करने से चेतावनी गायब हो जाती है और उपयोगकर्ता-स्थापित रूट स्वीकार करने वाले हर ऐप के लिए फ़ोन का ट्रस्ट मॉडल बदल जाता है। यह अगले क्लाइंट को प्रभावित करने वाली डिलीवरी खराबी भी छिपाता है और गेटवे को हर भावी उपकरण को अपूर्ण श्रृंखला भेजते रहने देता है। टिकाऊ मरम्मत सर्वर पर है, एक बार, सभी क्लाइंट के लिए।

परिवर्तन रिकॉर्ड में तीनों निर्णय अलग रखें: कौन-से प्रमाणपत्र भेजे गए, कौन-सी पहचान तुलना की गई और कौन-सा एल्गोरिद्म तय हुआ। हमेशा पूरी श्रृंखला भेजने वाला गेटवे, प्रमाणपत्र को सही नाम देने वाली प्रोफ़ाइल और फ़्लीट द्वारा समर्थित कुंजी प्रकार — तीन छोटे तथ्य, और पूरी विफलता यही है।

संबंधित लेख