L2TP NO_PROPOSAL_CHOSEN: أي طور فشل في الواقع؟
الإشعار يقول إن اقتراحًا رُفض، لا أي اقتراح. اقرأ سجل النظام الخلفي لمعرفة الطور، ثم قارن الأجناس مع من يدير البوابة.
يصل NO_PROPOSAL_CHOSEN قبل فحص أي اسم مستخدم PPP، وهذه حقيقة مفيدة وهي أيضًا سبب تضليل الرسالة. فهو يبلّغ بأن أحد الطرفين رفض اقتراحًا؛ لكنه لا يبلّغ أي معامل اختلف، ولا يقول شيئًا عن كون الرفض وقع أثناء بناء اقتران IKE أو لاحقًا أثناء التفاوض على حماية حركة المرور. هناك إصلاحان مختلفان خلف هذين الاحتمالين، وواحد فقط منهما يتعلق بمربع اختيار PFS الذي يلجأ إليه الناس أولًا.
رسالة واحدة، ومجموعتا اقتراحات
ترتيب IKEv1 L2TP/IPsec يتضمن مفاوضتين متتاليتين. يبني الطور 1 اقتران أمان IKE من خوارزمية تشفير وخوارزمية سلامة ومجموعة Diffie-Hellman. ثم يتفاوض الطور 2 على كيفية حماية حركة المرور، ومتطلب PFS ينتمي إلى المحادثة الثانية تلك.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
لأن الأطوار متسلسلة، يخبرك موضع الفشل أي قائمة تقارن. هذه هي القيمة التشخيصية كلها في الرسالة، ويستحق استخراجها قبل لمس أي إعداد.
لماذا لا يمكن لمربع اختيار PFS إصلاح الطور 1
تعطيل PFS يغيّر خاصية في الطور 2. إذا لم يتفق الطرفان أبدًا على الطور 1، فلن تحدث محادثة ESP إطلاقًا، ولذلك لا أثر لمربع الاختيار على الرفض على الإطلاق، ولهذا ينتج نفس الخطأ بطابع زمني مختلف.
الخطأ المعاكس شائع بالقدر ذاته. اقتران IKE الناجح لا يثبت أن اقتراح ESP مقبول، ولا يثبت بأي حال أن مجموعة الطور 2 متطابقة. تعامل مع النفق الإداري القائم كدليل على الطور 1 فقط. يقرأ الناس السطر الأخضر على أنه «النفق يعمل»، ثم يقضون ساعة في الطور الخطأ لأن شيئًا لم يخبرهم بأن المفاوضة الثانية لم تبدأ.
اقرأ السجل قبل اختيار الخوارزميات
اجمع الرسائل التي سبقت الرفض مباشرة من النظام الخلفي الذي يتعامل فعليًا مع الاتصال، واربطها بالمحاولة نفسها. بدون هذا الربط فأنت تقرأ تاريخ اتصال آخر وتستنتج منه.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswanمن تلك الأسطر، أجب عن سؤالين: هل تأسس اقتران للطور 1، وأي تبادل فشل. هذان الجوابان يضيّقان البحث إلى قائمة سمات واحدة. إشعار مجرد بلا سياق محيط لا يستطيع فعل ذلك، مهما كان مغريًا أن تجرّب اقتراحًا من موضوع في منتدى. نسخ سلسلة عاملة من جهاز بنظام خلفي مختلف يستبدل عادة رفضًا برفض آخر، متأخر قليلًا.
صياغة النظام الخلفي لا تنتقل
سجّل إصدار NetworkManager-l2tp وإصدار النظام الخلفي لـ IPsec قبل مقارنة أي شيء. لا تتشارك Libreswan وstrongSwan صياغة الاقتراح ولا مجموعات الخوارزميات نفسها، فالسلسلة التي تعمل في أحدهما تكون خطأً في الصياغة في الآخر. وقد يرفض النظام الخلفي المثبت IKEv1 بحسب السياسة، وعندها لن يُقبل أي اقتراح أبدًا.
يوثّق ملف README في المنبع تلك الاختلافات بين الأنظمة الخلفية ويُبقي حقلي الطور 1 والطور 2 منفصلين. اقرأه كتوثيق للبنية، لا كدعوة لتمكين كل شيفرة تاريخية ومجموعة ضعيفة، لأن الاتصال الذي لا ينجح إلا بذلك ليس الاتصال المطلوب بناؤه.
اتفق على الحزمة، ثم تحقق من المراحل
اسأل مشغّل البوابة عن حزم IKE وESP المدعومة والمعتمدة، ثم قارن ذلك الجواب بالاقتراحات الفعلية للعميل بدلًا من ملف إعداده. إذا كان الخلاف حول PFS في الطور 2 تحديدًا، فاتفق على مجموعة مدعومة أو على سياسة معتمدة صراحةً بعدم استخدام PFS. لا تستنتج السياسة من اسم الخطأ.
حين يتطلب التداخل الوحيد تعمية لم تعد المنظمة تقبلها، يعود القرار إلى البوابة أو إلى ترحيل البروتوكول. توسيع سلسلة العميل حتى يتفاوض شيء ما هو طريقة لتسليم ثغرة معروفة مع علامة صحيحة بجانبها.
بعد تصحيح التعارض الحقيقي، أكّد قيام IPsec قبل التحقيق في L2TP وPPP، وتعامل مع أي رفض مصادقة لاحق على أنه يخص المرحلة التالية. ثم اختبر التجديد في عملية الاختبار المعتمدة، لأن تأسيس الاقتران الأول لا يقول شيئًا عن بقية عمره.