strongSwan send_cert: IKE प्रमाणपत्र कधी पाठवले जाते
send_cert ठरवते की peer आपले प्रमाणपत्र पाठवते की नाही, तर send_certreq दुसऱ्या बाजूकडून ते मागते। प्राप्तकर्त्याचा विश्वास बदलण्यापूर्वी लॉग तपासा।
गेटवे प्रमाणपत्राशी संबंधित प्रमाणीकरण अपयश नोंदवतात, आणि पहिली प्रतिक्रिया म्हणजे प्राप्तकर्त्याला अजून एक 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 पुन्हा वापरण्याऐवजी नवीन सत्र स्थापित करा। पुष्टी करा की प्रमाणपत्र पेलोड आता दिसतो आणि प्राप्तकर्ता तो इच्छित अँकरसमोर स्वीकारतो। काहीही बदलत नसल्यास, चूक विश्वासाच्या बाजूला होती आणि पाठवणाऱ्याची सेटिंग कारण नव्हती।
निरीक्षण केलेली देवाणघेवाण, अँकर आणि त्यातून मिळालेली पडताळणी बदल नोंदीत लिहा। या संज्ञांमध्ये वर्णन न करता येणारी प्रमाणपत्र दुरुस्ती हा योगायोग आहे।