هل كسرت ترقية Ubuntu اتصال L2TP/IPsec؟ قارن مقترحات IKEv1

عمل الاتصال يوم الخميس، وجرت الترقية يوم الجمعة، ويوم الاثنين يظل العميل يدور عند “connecting” ثم يستسلم. الحاسوب نفسه، والخادم نفسه، والحساب نفسه، والمفتاح المشترك السابق نفسه. لم يُعدَّل شيء في الملف الشخصي، ولهذا فإن المشتبه بهما الواضحين، كلمة المرور وجدار الحماية، يضيّعان وقتك.

الذي تغيّر هو قائمة التحويلات التي يرغب جهازك في تقديمها. كلا حزمتي IPsec المستخدمتين على Ubuntu، أي strongSwan وLibreswan، تحذفان الخوارزميات التي لم تعودا تعتبرانها آمنة، ولدى إضافة NetworkManager التي تتقدّمهما قائمتها الخاصة التي تتحرّك وفق جدول مختلف. قد ينتهي خادم مثبّت على 3DES وSHA1 ومجموعة Diffie-Hellman بطول 1024 بت إلى عدم سماع أي شيء يقبله.

ما الذي غيّرته الترقية فعليًا

تتغذّى قائمة IKEv1 من طبقتين. يشحن البرنامج الخفي مجموعة مقترحات افتراضية مضمّنة في البناء، وإضافة L2TP إما أن تحيل إليها وإما أن تقدّم قائمتها الخاصة. قبل NetworkManager-l2tp 1.2.16 كانت الإضافة تحيل، فكان ما تقدّمه هو ما يعتبره البرنامج الخفي المثبّت معقولًا. من 1.2.16 فصاعدًا ترسل الإضافة قائمة موثّقة محاكاة لعملاء Windows وApple، وهذه القائمة أوسع من الافتراضي القديم لكنها لم تعد تحتوي كل تركيبة قديمة في مقدّمة الصف.

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

هناك فخ أصغر في المنطقة نفسها. يكتب البرنامجان الخفيان مجموعات Diffie-Hellman المنحنية بشكل مختلف، أحدهما يكتب ecp384 والآخر ecp_384. إذا لصقت التهجئة الخاطئة في مربع الحوار المتقدّم، يرفض البرنامج الخفي الإعداد باعتباره غير قابل للتحليل، ويظهر ذلك في السجل كمشكلة تفاوض لا كخطأ إملائي في الإعداد.

اقرأ الفشل قبل أن تغيّر أي شيء

ابدأ بالخلفية التي تشغّلها، لأن الجواب يحدّد الصيغة وموقع السجل معًا.

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

ثم اقرأ التبادل نفسه. على strongSwan يكتب البرنامج الخفي إلى سجلّ النظام (journal) على إصدار حديث وإلى /var/log/syslog على إصدار أقدم، والجزء المهم هو المقترح الذي يرسله لا السطر الأخير. أنت تبحث عن عبارة تفيد بعدم وجود مقترح مطابق، وهذه مشكلة خوارزمية؛ أو عن فشل مصادقة، وهو يشير إلى المفتاح أو الحساب؛ أو عن مهلة صريحة، وهي تشير إلى إمكانية الوصول.

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

المرحلة 1 والمرحلة 2 رهانان منفصلان

يتفاوض IKEv1 مرتين. يبني النمط الرئيسي اقتران أمان IKE من خوارزمية تشفير وخوارزمية سلامة ومجموعة Diffie-Hellman وطريقة مصادقة. ثم يبني النمط السريع اقتران ESP الذي سيحمل L2TP. الخادم حرّ في قبول الأول ورفض الثاني، لذا يفشل ملف شبه صحيح في وقت لاحق مما تتوقع ويبدو كخطأ مختلف.

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

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

غيّر حقلًا واحدًا ثم أعد الاختبار

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

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