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 هذان إعدادان منفصلان، تقريبًا proposals = aes256-sha256-modp2048 لـ IKE SA وقائمة ESP منفصلة لـ CHILD SA. غيّر القائمة التي تطابق التبادل الفاشل، ثم أعد قراءة السجل بدلًا من افتراض أن الإصلاح نجح.

بالنسبة إلى CHILD SA، الإعداد ذو الصلة هو قائمة اقتراحات ESP، لا قائمة IKE. نسخ سطر IKE إليها ينتج إعدادًا يحلّل ويتفاوض على الكائن الخطأ.

نفق عامل يفشل عند إعادة توليد المفتاح

إذا عمل النفق ساعة ثم فشل، فالتفاوض الأولي ليس المشكلة. يمكن أن تفرض إعادة توليد المفتاح ظروفًا مختلفة: مجموعة تبادل مفاتيح مختلفة بعد التبادل الأول، أو عدم تطابق في العمر بين الطرفين، أو سياسة مستجيب تغيّرت. احتفظ بطابع وقت التجديد ومعرّفات الارتباط من الجانبين. يحتاج هذا النمط إلى مقارنة اقتراحات عند التجديد، لا إلى مهلة أطول. تغيير المهلة يخفي العَرَض ويترك عدم التطابق في مكانه.

ipsec statusall يعرض كل ارتباط والخوارزميات التي جرى التفاوض عليها فعليًا. هذا المخرجات هي أسرع طريقة لتأكيد القائمة المستخدمة، وهي تفصل خطأ الإعداد عن نفق قديم لم يُعد التفاوض عليه.

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

اختر تقاطعًا، ثم أكّد المرحلتين

اطلب من المسؤول اختيار تقاطع حديث موثّق يدعمه الطرفان، واكتبه. لا تحلّ الخطأ بتمكين كل خوارزمية قديمة أو بتعطيل التحقق من الهوية، لأن أيًّا منهما لا ينتج عن الرفض. بعد التغيير، أنشئ اتصالًا جديدًا ثم أجبر إعادة توليد المفتاح. الاتصال الأول وحده لا يثبت أن مسار التجديد يعمل.

احتفظ بالمزيج المقبول مع إصدارات البرنامج الثابت. وإذا كان الخطأ التالي يتعلق بمحددات حركة المرور، فتعامل معه بشكل منفصل، لأن الاتفاق على التشفير لا يقول شيئًا عن الشبكات الفرعية التي يحميها النفق. توثيق strongSwan للاقتراحات يغطي صياغة القائمتين.