L2TP في Ubuntu 24.04 معطّل: xl2tpd أم خدمة go-l2tp الخلفية؟
تغيّرت الخدمة الخلفية وراء إضافة L2TP في NetworkManager في 24.04. اقرأ أي مرحلة فشلت، ثم اختر إصلاحًا واحدًا بدلًا من الحذف والتثبيت في وقت واحد.
غيّر Ubuntu 24.04 بهدوء الخدمة الخلفية وراء إضافة L2TP في NetworkManager. استخدم المسار الأقدم xl2tpd؛ أما الحزمة الأحدث فتجلب تنفيذًا بلغة Go ينتج خدمة خلفية باسم kl2tpd. تشغّل الإضافة أيًا منهما كان مثبتًا، لذا يمكن للترقية أن تستبدل الخدمة الخلفية دون المساس بملفك الشخصي أو بيانات اعتمادك. هذا هو العطل كله: رسالة تحكّم لا تتعرّف عليها الخدمة الجديدة.
تنسّق الإضافة بين IPsec وL2TP وPPP، ثم تسلّم الواجهة الناتجة إلى NetworkManager. وهي لا تنفّذ L2TP بنفسها.
الإضافة منسّق، لا خدمة خلفية
network-manager-l2tp تشغّل مساعد IPsec وخدمة L2TP الخلفية وPPP، وتوصل الواجهة بإدارة اتصالات سطح المكتب. لسنوات كانت الخدمة الخلفية xl2tpd، وكل دليل يذكر إعدادها ورث هذا الافتراض. قبلت حزم Debian لاحقًا أيًا من التنفيذين، و24.04 تثبّت تنفيذ Go الذي يوفّر kl2tpd. لا يسجّل أي حقل في الملف الشخصي أي خدمة خلفية كانت تعمل سابقًا، لذا يبقى الاستبدال غير مرئي حتى تُرفض رسالة.
قد لا تشغّل آلة فيها كلتا الحزمتين التنفيذ الذي تتوقعه. الاختيار قرار الإضافة لا قرار الدليل الذي اتبعته.
اقرأ المرحلة قبل اختيار الإصلاح
journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd _COMM=charon _COMM=pluto
اربط محاولة واحدة عبر المساعدات بدلًا من الثقة بإشعار سطح المكتب. يُظهر ذلك الاستعلام أين توقّفت السلسلة، ويُظهر dpkg -l أي تنفيذ مثبّت. الفشل الذي يظهر بعد إنشاء نظير IPsec، ويذكر رسالة تحكّم أو سمة غير معروفة، يشير إلى الخدمة الخلفية. الفشل قبل وجود النفق يعني أن الخدمة الخلفية لم تُبلَغ أبدًا.
عدم تطابق المفتاح المشترك المسبق ينتهي عند مرحلة IPsec ويسمّي النظير. تظهر مشكلة بيانات اعتماد PPP بعد قيام النفق وعادةً تحمل رفض CHAP أو MS-CHAP مقروءًا. كلاهما ظاهر في الاستعلام نفسه، وهما مشكلتان مختلفتان.
مساران لا يختلطان
sudo apt install xl2tpd sudo apt purge go-l2tp
يضع ذلك الزوج xl2tpd ثم يزيل خدمة Go الخلفية، تاركًا الإضافة تختار التنفيذ الذي تتكلم لهجته البوابة. الترتيب مهم: تعتمد الإضافة على أحد التنفيذين، لذا فإن إزالة حزمة Go أولًا تُسقط الإضافة معها. يحتفظ المسار الثاني بخدمة Go الخلفية وينتقل إلى بناء أحدث يفهم الرسالة، وهذا يعني عادةً مستودع PPA لمشرف بدلًا من نسخة الأرشيف. في أسطول مُدار، تثبيت PPA أسهل تبريرًا من تعليم المستخدمين إزالة الحزم.
لا تجمع المسارين في تغيير واحد. حينها يتركك فشل لاحق عاجزًا عن قول أي نصف ساعد، وقد تعيد ترقية مستقبلية الحزمة التي أزلتها للتو.
ضع ملف الخدمة الخلفية الثنائي وإصداره والرسالة الدقيقة في التذكرة. لا أحد يستطيع إعادة إنتاج تقرير يقول فقط إن L2TP تعطّل بعد الإصدار، بينما سمة مسمّاة مع إصدار حزمة تعطيهم نقطة بداية.
ثلاثة أشياء ليس هو إياها
ليس مشكلة في الملف الشخصي، لأن الملف نفسه عمل على 22.04 مع البوابة نفسها. وليس مسارًا مفقودًا أو تغييرًا في الجدار الناري، لأن تلك تفشل في مكان آخر بأدلة مختلفة. وإعادة تثبيت الإضافة لا تصلحه أيضًا، لأن الخدمة نفسها تُختار مرة أخرى. الوصف المفيد يسمّي الخدمة الخلفية والرسالة التي رفضتها.
الإصلاح من جهة البوابة نتيجة مشروعة أخرى. الثابتة البرمجية التي تتوقف عن إرسال السمة تصمد أمام كل ترقية للعميل، أما تثبيت حزمة فيصمد أمام إصدار التوزيعة التالي فقط إذا تذكّر أحد سبب تثبيتها.
قارن المسارين بتكلفة الصيانة لا بالسرعة. كلاهما قد ينجح؛ واحد فقط يزيل اختلاف اللهجة.