IKEv2 NO_PROPOSAL_CHOSEN: कोणत्या टप्प्याने सूट नाकारली?

लॉगमध्ये NO_PROPOSAL_CHOSEN दिसल्यावर लोक पूर्व-सामायिक कीकडे धाव घेतात, आणि की बदलल्यानंतरही त्रुटी राहते। ही कधीही क्रेडेन्शियल्सची समस्या नव्हती: पीअरने त्या देवाणघेवाणीसाठी दिलेला प्रत्येक प्रस्ताव नाकारला, जे ओळखीबद्दल नसून अल्गोरिदमबद्दलचे विधान आहे। पहिला उपयुक्त प्रश्न कोणता अल्गोरिदम संपादित करायचा हा नाही, तर कोणती देवाणघेवाण नाकारली गेली हा आहे। काहीही तुलना करण्यापूर्वी त्याचे उत्तर द्या। नंतर प्रस्तावित संपूर्ण सूटची पीअरने अनुमती दिलेल्या संपूर्ण सूटशी तुलना करा।

प्रथम: कोणती देवाणघेवाण नाकारली गेली

IKEv2 दोन प्रकारच्या असोसिएशनवर वाटाघाटी करते। IKE SA स्वतः वाटाघाटीचे संरक्षण करते, आणि CHILD SA रहदारीचे संरक्षण करते। प्रत्येकाचा स्वतःचा प्रस्ताव-संच असतो, आणि प्रत्येक एकाच सूचनेसह अयशस्वी होऊ शकतो। सुरुवातीच्या IKE वाटाघाटीदरम्यानचा नकार आणि CHILD वाटाघाटीदरम्यानचा नकार यांना वेगवेगळे दुरुस्ती आवश्यक असतात, आणि लॉग सामान्यतः सूचनेच्या एक-दोन ओळी वर देवाणघेवाणीचे नाव सांगतो। त्या दोन ओळी एकत्र वाचा, अन्यथा चुकीची प्रस्ताव-यादी संपादित कराल।

केवळ सूचना देवाणघेवाण ओळखत नाही। तिच्या वरील ओळ वाटाघाटी होत असलेल्या SAचे नाव सांगते, आणि ते नाव तपासावयाच्या प्रस्ताव-यादीकडे निर्देश करते।

संपूर्ण संचांची तुलना करा, वैयक्तिक कीवर्डची नाही

प्रस्ताव हे एक संयोजन आहे: एन्क्रिप्शन अल्गोरिदम, अखंडता किंवा AEAD, की-एक्सचेंज गट, आणि कोणतेही स्यूडो-रँडम फंक्शन। केवळ एन्क्रिप्शनचे नाव तुलना करणे ही नेहमीची चूक आहे, कारण दोन पीअर AES-256 वर सहमत होऊनही SHA-1 विरुद्ध SHA-256 वर मतभेद ठेवू शकतात। अयशस्वी टप्प्यावर प्रस्तावित आणि अनुमत संच शेजारी लिहा, नंतर रिकामा छेद शोधा।

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

दोन्ही अंमलबजावणी तुम्ही कॉन्फिगर केलेले समर्थन करतात का तेही तपासा। दुसऱ्या प्लॅटफॉर्मवरून कॉपी केलेले नाव वाक्यरचनेच्या दृष्टीने परिचित वाटू शकते तर प्लगइन किंवा अंमलबजावणी पूर्णपणे अनुपस्थित असते।

IKE संच आणि ESP संच वेगळ्या वस्तू आहेत

IKE प्रस्ताव संपादित केल्याने नाकारलेला CHILD प्रस्ताव दुरुस्त होणार नाही, आणि उलटेही खरे आहे। strongSwan मध्ये हे स्वतंत्र सेटिंग्ज आहेत, अंदाजे IKE SA साठी proposals = aes256-sha256-modp2048 आणि CHILD SA साठी वेगळी ESP यादी। अयशस्वी देवाणघेवाणीशी जुळणारी यादी बदला, नंतर दुरुस्ती काम करून गेली असे गृहीत धरून न लॉग पुन्हा वाचा।

CHILD SA साठी संबंधित सेटिंग ESP प्रस्ताव-यादी आहे, IKE यादी नाही। त्यात IKE ओळ कॉपी केल्याने अशी कॉन्फिगरेशन तयार होते जी पार्स होते पण चुकीच्या वस्तूवर वाटाघाटी करते।

काम करणारा बोगदा की-नूतनीकरणावर अयशस्वी होतो

बोगदा एक तास चालला आणि नंतर अयशस्वी झाला, तर सुरुवातीची वाटाघाटी समस्या नाही। की-नूतनीकरण वेगळ्या परिस्थिती तपासू शकते: पहिल्या देवाणघेवाणीनंतर वेगळा की-एक्सचेंज गट, पीअर्समधील आयुष्याची विसंगती, किंवा बदललेले प्रतिसादक धोरण। दोन्ही बाजूंकडून नूतनीकरण टाइमस्टॅम्प आणि असोसिएशन ओळखखुणा ठेवा। त्या नमुन्यास नूतनीकरणाच्या वेळी प्रस्तावाची तुलना आवश्यक आहे, लांब टाइमआउट नाही। टाइमआउट बदलल्याने लक्षण लपते आणि विसंगती जागेवरच राहते।

ipsec statusall प्रत्येक असोसिएशन आणि प्रत्यक्षात वाटाघाटी झालेले अल्गोरिदम दाखवते। ते आउटपुट कोणती यादी वापरली गेली याची खात्री करण्याचा सर्वात जलद मार्ग आहे, आणि ते कॉन्फिगरेशन त्रुटीला पुन्हा कधीही वाटाघाटी न झालेल्या जुन्या बोगद्यापासून वेगळे करते।

ipsec statusall | grep -E "IKE:|ESP:"

छेद निवडा, नंतर दोन्ही टप्पे निश्चित करा

प्रशासकाला दोन्ही पीअर समर्थित दस्तऐवजीकृत आधुनिक छेद निवडण्यास आणि तो लिहून ठेवण्यास सांगा। सर्व जुने अल्गोरिदम सक्षम करून किंवा ओळख पडताळणी बंद करून त्रुटी सोडवू नका, कारण नकारातून दोन्हीपैकी काहीही येत नाही। बदलानंतर नवीन कनेक्शन स्थापित करा आणि नंतर की-नूतनीकरण सक्तीने करा। केवळ पहिले कनेक्शन नूतनीकरण मार्ग काम करतो हे सिद्ध करत नाही।

स्वीकारलेले संयोजन फर्मवेअर आवृत्त्यांसह ठेवा। पुढील त्रुटी रहदारी निवडकांबद्दल असल्यास, ती वेगळी हाताळा, कारण क्रिप्टोग्राफीबद्दलचा करार बोगदा कोणत्या उपजाळ्या संरक्षित करतो याबद्दल काहीही सांगत नाही। strongSwan चे प्रस्ताव दस्तऐवजीकरण दोन्ही याद्यांची वाक्यरचना समाविष्ट करते।