NO_PROPOSAL_CHOSEN على L2TP؟ افحص البوابة أولاً

عميل L2TP/IPsec الذي يفشل قبل ظهور مطالبة اسم المستخدم لم يتفق قط على المرحلة 1. افحص مجموعة المقترحات لدى البوابة بدلاً من لصق سلاسل التشفير.

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

ما الذي تنفيه الرسالة

يحدث الرفض في الوضع الرئيسي، قبل أي تبادل L2TP أو PPP، لذلك لم يُستشر النفق ولا قاعدة بيانات المستخدمين. تتفاوض المرحلة 1 على التشفير والسلامة ومجموعة Diffie-Hellman. وتتفاوض المرحلة 2 على مقترح ESP للبيانات. لا يمكن إصلاح فشل في المرحلة 1 بتغيير إعداد PFS في المرحلة 2، كما أن ارتباط IKE مكتملاً لا يثبت أن مقترح ESP مناسب.

سجّل الخادم الخلفي قبل تحرير الصياغة: ipsec --version. يقبل libreswan و strongSwan صيغاً مختلفة للمقترح من أجل الخوارزميات نفسها.

ثم اقرأ الرفض في سياقه عبر journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

افحص البوابة للتعرف على مجموعة التحويلات لديها

يسأل الماسح البوابة مباشرة عن التحويلات التي ستتفاوض عليها. أوقف خدمة IPsec المحلية أولاً حتى لا ينافس الفحص عميلك، ثم اقرأ أسطر SA. تعامل مع القائمة كدليل عن الطرف الآخر، لا كقائمة تُفعّل بالكامل دفعة واحدة.

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

كثيراً ما تقدم الأجهزة الأقدم 3DES و SHA1 و MODP1024، لأنها كانت الإعدادات الافتراضية عند شحن المنتج ولم يراجعها أحد. احتفظ بمخرجات الفحص الخام، فهي السجل الوحيد لما عرضه الطرف الآخر في ذلك اليوم. وإذا كان هذا أقوى تداخل متاح، فإن التصعيد الصحيح يكون إلى مالك البوابة، لا إلى إعداد عميل يعيد تمكين تشفير ضعيف للجميع.

طابق التداخل دون تعطيل السلامة

أدخل فقط التحويلات التي تظهر في الفحص وسياستك معاً. يعكس المثال أدناه بوابة تعرض 3DES و SHA1 و MODP1024 في المرحلة 1. لاحظ تحفظ الخادم الخلفي: لا يترجم libreswan 4.x مجموعة modp1024، لذا ينطبق هذا على strongSwan أو بناء libreswan يدعم DH2. تحقق من الإصدار قبل أن تستنتج أن العميل معطوب.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

علامة التعجب في النهاية تثبّت مقترحاً واحداً. استخدمها لعزل اختبار ما، ثم أزلها كي تتمكن البوابة من التفاوض على شيء أقوى لاحقاً.

افحص الخدمة والمنفذ قبل إعادة المحاولة

يشغّل NetworkManager-l2tp نسخته الخاصة من xl2tpd. إذا كانت خدمة النظام تملك UDP 1701 بالفعل، يتراجع العميل إلى منفذ مصدر مؤقت، وهو ما يسمح به RFC 3193 وتتجاهله بعض الخوادم بصمت. افحص مالك المقبس قبل المحاولة التالية.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

الأسرار المولّدة القديمة سبب خفي آخر. فالملفات الموجودة تحت /etc/ipsec.d/ والمسماة باتصال قديم قد تعيش أطول من الملف الشخصي الذي أنشأها، لذا احذف ما لا يشير إليه شيء وأعد المحاولة.

أخيراً، تحقق من مصدر النصيحة. فملف ipsec.conf مكتوب لـ IKEv1 XAuth يصف نوع VPN مختلفاً، ومقترحه ليس السطر الوحيد الخطأ في ملف L2TP شخصي. سجّل مجموعة التحويلات التي أدخلتها بجانب الملف الشخصي، حتى لا يكرر الشخص التالي الفحص.

مقالات ذات صلة