strongSwan send_cert: IKE प्रमाणपत्र कब भेजा जाता है

गेटवे प्रमाणपत्र से जुड़ी प्रमाणीकरण विफलताएँ लॉग करते हैं, और पहली प्रतिक्रिया प्राप्तकर्ता में एक और CA जोड़ना होती है। यह मानता है कि प्रमाणपत्र पहुँच गया और अस्वीकार कर दिया गया। दूसरी संभावना यह है कि वह कभी भेजा ही नहीं गया, और यह भेजने वाले की कनेक्शन नीति तय करती है। भरोसा बदलने से पहले निर्धारित करें कि दोनों में से क्या हुआ।

send_cert वास्तव में क्या नियंत्रित करता है

प्रमाणपत्र द्वारा प्रमाणीकरण के लिए आवश्यक है कि peer का अंतिम-इकाई प्रमाणपत्र IKE आदान-प्रदान या पूर्व तैयारी के माध्यम से दूसरे पक्ष तक पहुँचे। swanctl में कनेक्शन सेटिंग send_cert तय करती है कि यह अंतिम बिंदु अपना प्रमाणपत्र पेलोड शामिल करता है या नहीं: कभी नहीं, हमेशा या ifasked। डिफ़ॉल्ट ifasked इसे peer के प्रमाणपत्र अनुरोध के उत्तर में भेजता है। प्रमाणपत्र माँगना अलग सेटिंग है, क्योंकि दूसरे पक्ष से उसका प्रमाणपत्र माँगना अपना प्रस्ताव करने के समान नहीं है।

पुराने ipsec.conf परिनियोजन leftsendcert और rightsendcert का उपयोग करते थे, और ये नाम स्थानीय तथा दूरस्थ भूमिकाओं से मेल खाते हैं, सीधे swanctl से नहीं।

कनेक्शन बदलने से पहले एक प्रयास पढ़ें

एक नियंत्रित प्रयास के आधार पर निदान करें, न कि इस आम धारणा पर कि प्रमाणपत्र शामिल हैं। नीति और सक्रिय संबद्धता दोनों की जाँच हो सकती है।

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

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

प्राप्तकर्ता का भरोसा अलग निर्णय है

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

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

जाँच दिखाती है कि किस जारीकर्ता ने प्रमाणपत्र पर हस्ताक्षर किए और वह कब समाप्त होता है, और प्राप्तकर्ता के एंकर को उससे मेल खाना चाहिए। परिनियोजन के स्वामित्व वाले जारीकर्ता CA पर भरोसा करें, श्रृंखला के हर मध्यवर्ती प्रमाणपत्र पर नहीं, क्योंकि हर मध्यवर्ती को रूट तक उठाना भरोसे को एक peer से कहीं आगे बढ़ा देता है। पहचान सत्यापन सक्रिय रखें, क्योंकि केवल सत्यापन बंद करके सफल होने वाला कनेक्शन सुधार नहीं है। जहाँ श्रृंखला अधूरी है, वहाँ तैयारी ठीक करें, भेजने वाले की नीति नहीं।

भेजने वाले को केवल प्रमाण के साथ बदलें

जब लॉग दिखाता है कि प्रमाणपत्र कभी भेजा ही नहीं गया और प्राप्तकर्ता ने वास्तव में उसे माँगा, तो send_cert को always पर सेट करना उस कनेक्शन के लिए उचित बदलाव है। इसे swanctl कॉन्फ़िगरेशन में लागू करें, कनेक्शन पुनः लोड करें और मौजूदा SA का पुनः उपयोग करने के बजाय नया सत्र स्थापित करें। पुष्टि करें कि प्रमाणपत्र पेलोड अब दिखाई देता है और प्राप्तकर्ता उसे इच्छित एंकर के सामने स्वीकार करता है। यदि कुछ नहीं बदलता, तो गलती भरोसे की ओर थी और भेजने वाले की सेटिंग कारण नहीं थी।

देखे गए आदान-प्रदान, एंकर और उससे प्राप्त सत्यापन को परिवर्तन रिकॉर्ड में लिखें। प्रमाणपत्र का ऐसा सुधार जिसे इन शब्दों में न बताया जा सके, संयोग है।