سجل تنقيح L2TP فارغ؟ الخطأ على الأرجح في سجل النظام

تبدأ أداة L2TP المساعدة مع التنقيح، وتراقب الطرفية، فتتوقف دون أي شيء مفيد على الشاشة. هذا ليس علم تنقيح معطلاً. اتصال NetworkManager عبر L2TP يتكوّن من أربع عمليات متعاونة، وعدد محدود منها فقط يكتب إلى الطرفية التي تراقبها. بقية الأدلة موجودة في سجل النظام، على مسافة مرشّح واحد.

أربع عمليات، وجهتان للسجل

يبدأ الاتصال بـ IPsec، وهو إما libreswan أو strongSwan حسب التثبيت. ثم يشغّل خادم L2TP، وهو تقليدياً xl2tpd وفي بعض البُنى kl2tpd، النفق. وأخيراً يتولى pppd المصادقة والعنونة داخله.

تنسّق خدمة الأداة المساعدة تلك الأجزاء وتطبع تقدّمها الخاص. وعادة ما تُبلغ خدمة IPsec و pppd عبر سجل النظام، ولهذا تُظهر الطرفية اتصالاً فاشلاً بينما يقع السبب في ملف لم تفتحه.

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

اجمع محاولة واحدة، ثم اقرأ الترتيب

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

تختار هذه الأوامر العمليات المشاركة في الإقلاع الحالي، ويستحق مسار الملحق التأكد منه على توزيعتك:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

الحقول المتكررة في استدعاء واحد تختار اتحاد تلك العمليات، ما يحافظ على التسلسل بترتيب زمني. على نظام قائم على Debian يكون الاستعلام المكافئ dpkg -L؛ والفكرة هي إيجاد المكان الذي تعيش فيه الأداة المساعدة فعلاً قبل محاولة تشغيلها يدوياً.

ثلاثة شروط تحدّد الخطوة التالية

اقرأ أول مرحلة فاشلة، ثم اختر وفقاً لذلك. إذا أبلغ IPsec عن فشل في المقترح أو في مصادقة النظير، فإن النفق لم يتكوّن أبداً، وتغيير كلمة مرور PPP لن يساعد.

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

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

يستحق أيضاً التأكد من أي خادم IPsec خلفي مثبّت قبل لمس أي إعداد تنقيح. خيار تسجيل مكتوب لـ strongSwan لا يفعل شيئاً عندما يعمل libreswan، وسيظل الاتصال يفشل في المكان نفسه بينما تعدّل ملفاً لا يقرأه أحد.

وضع التنقيح يترك ملفات خلفه

يشغّل سير عمل التنقيح الأصلي الخدمة يدوياً بعلم تنقيح، وقد يترك هذا الوضع ملفات إعداد وقت تشغيل مولّدة في مكانها عند انتهاء الاتصال.

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

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

أعد الأداة المساعدة العادية بعد ذلك

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

ثم تحقّق من النتيجة في الطبقة التي فشلت، لا عند أيقونة سطح المكتب:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

الجلسة التي تصادق وتحصل على عنوان وتوجّه إلى الوجهة المقصودة هي النتيجة التي كنت تنقّح من أجلها. الطرفية الصامتة أثناء محاولة فاشلة تخبرك فقط بالمكان الذي لم تُكتب فيه المخرجات.