تشغيل L2TP بدون IPsec على Linux: xl2tpd وpppd وNAT

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

إن مضيت قدمًا، فاكتب هذا التحذير في مذكرة التصميم واتركه هناك. وما يلي هو المسار التشغيلي الذي أستخدمه على مضيفات Debian وعائلة RHEL: أي ملف يملك ماذا، وMTU التي تمنع التوقف الكلاسيكي، وقواعد إعادة التوجيه التي تجعل النفق جديرًا بالعناء.

ثلاثة ملفات تتقاسم العمل

ينهي xl2tpd اتصال التحكم ويسلم كل جلسة إلى خادم PPP، لذا تتوزع الإعدادات على برنامجين لا يقرأ أي منهما ملفات الآخر. يقع المستمع في /etc/xl2tpd/xl2tpd.conf، داخل قسم [lns default] الذي يسمي مجمع العناوين بـ ip range، وطرف الخادم بـ local ip، والتسليم إلى PPP بـ pppoptfile. شغّل require authentication = yes، واترك length bit و flow bit مفعّلين، واختر مجمعًا لا يستخدمه أي شيء آخر على المضيف.

تقع سياسة PPP في الملف الذي يسميه ذلك الخيار، وعادةً /etc/ppp/options.xl2tpd: auth، ورفض pap وchap وmschap، ثم require-mschap-v2، وMTU وMRU بقيمة 1460، وعنوان DNS يستطيع العميل الوصول إليه بعد ارتفاع الوصلة. أما بيانات الاعتماد فهي ملف ثالث مرة أخرى، /etc/ppp/chap-secrets، حيث يجب أن يطابق الحقل الثاني اسم قسم LNS وقد يثبّت الحقل الرابع عنوانًا محددًا من المجمع.

لماذا يتصل النفق ثم يتوقف

لا يتسع إطار إيثرنت بحجم 1500 بايت داخل مسار ينفق بالفعل بايتات على ترويسته الخاصة. تكلف ترويسة IPv4 الخارجية 20، ويكلف UDP 8، وتكلف ترويسة L2TP نحو 12، ما يترك 1460 لـ PPP وحمولته. والإعلان عن ذلك الرقم الأصغر في PPP هو ما يمنع تجزئة الحزم الكبيرة أو إسقاطها بصمت في مكان ما في المنتصف.

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

منفذ واحد يحمل محادثتين

يجلس UDP 1701 تحت نصفي البروتوكول، وهذه الحقيقة الواحدة تكسر من قواعد جدار الحماية أكثر من أي جزء آخر من الإعداد. يأتي أولًا طلب بدء اتصال التحكم وردّه؛ ثم لا يؤسس طلب الجلسة وتأكيدها اللذان يليان أكثر من زوج المعرّفات. يتولى PPP بعد ذلك، مع التحكم بالوصلة، ثم المصادقة، ثم بروتوكول التحكم بـ IP لتسوية العناوين. ولكل مرحلة مفرداتها في السجل، ولا تعلن أي منها عن نفسها كفشل L2TP.

قراءة التقاط بهذا الترتيب بالضبط تخبرك أي مرحلة فشلت، وفشل مصادقة PPP لن يُصلح بتحرير xl2tpd. يفسر المنفذ المشترك فشلًا شائعًا آخر: القاعدة التي تسمح فقط بأول حزم التدفق تتيح للجلسة أن تُنشأ ثم تحجب النقل. اسمح بـ 1701 للمحادثة كلها، في الاتجاهين.

جعل النفق مفيدًا: إعادة التوجيه وNAT

الجلسة بحد ذاتها لا تصل إلا إلى الخادم. يحتاج وصول العميل إلى الإنترنت إلى إعادة توجيه، وقاعدة NAT للمجمع على الوصلة الصاعدة، وخادم DNS يستطيع العميل الاستعلام منه فعليًا بعد ارتفاع الوصلة. ويجب أن يبقى المجمع بعيدًا عن نطاق LAN، وإلا سُلّمت الردود الموجهة إلى العملاء محليًا بدل دفعها مرة أخرى إلى النفق.

على الخادم، فعّل إعادة التوجيه بـ sysctl -w net.ipv4.ip_forward=1، وترجم المجمع بـ iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE، ثم اقبل حركة النفق الصادرة بقاعدة FORWARD لـ -i ppp0 -o eth0 وحركة العودة بقاعدة المرآة مع -m state --state RELATED,ESTABLISHED. وأبقِ هذه القواعد بعد إعادة التشغيل، لأن خادمًا يعود بدونها يبدو تمامًا كإعداد L2TP معطل.

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

ما لا تفعله الحزمة المجردة، وكيف تتحقق

لا جزء من هذه الحزمة يشفر إطارات PPP، ولا شيء فيها يوثق الطرف البعيد كالخادم الذي اخترته فعلًا. يحمي MS-CHAPv2 تبادل بيانات الاعتماد من مستمع يراقب فقط، لكن المهاجم الموجود في المسار يستطيع مع ذلك التدخل في الجلسة. ويقدم عميل Windows الأصلي L2TP فقط بالاشتراك مع IPsec، لذا احسب حساب Linux وبرامج الموجهات وعملاء الطرف الثالث كأقرانك. تعامل مع الإعداد المجرد كدرجة تشخيصية، لا كمكان للتوقف.

تحقق بترتيب ثابت: شغّل xl2tpd -D في المقدمة، وراقب السجل بحثًا عن مرحلة PPP، واقرأ العنوان المعين من ip addr على الطرفين، ثم التقط UDP 1701 لتأكيد تدفق البيانات بعد قيام الجلسة. إذا تطابقت الأربعة جميعًا وظلّت الحركة تفشل، فالخطأ في التوجيه أو NAT أو MTU وليس في L2TP نفسه.