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 को प्रस्ताव कागजात दुवै सूचीको वाक्यरचना समेट्छ।