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 का प्रस्ताव दस्तावेज़ीकरण दोनों सूचियों के सिंटैक्स को कवर करता है।