PPTP يتصل ثم يتجمّد خلف Linux NAT: مساعد GRE

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

إعادة التوجيه لم تكن المشكلة قط

قاعدة إعادة توجيه المنفذ تصف حركة TCP أو UDP. لا تستطيع وصف حمولة تتحول إلى بروتوكول IP آخر في منتصف الجلسة، وPPTP يفعل ذلك بالضبط.

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

TCP للتحكم وGRE للبيانات

يُتفاوض على المكالمة عبر TCP 1723. وبعد أن تصبح قائمة، تنتقل الحمولة إلى GRE، بروتوكول IP رقم 47، الذي لا يحمل أي أرقام منافذ على الإطلاق. قاعدة تعتمد على المنافذ لا تجد ما تطابقه.

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

GRE المجرّد بدون PPTP لا يحتاج إلى إعادة كتابة كهذه، ولهذا يمكن لنفق GRE عادي أن يعمل عبر موجّه يفشل مع عميل PPTP على المسار نفسه.

أربع وحدات وsysctl أطفأتها

وحدتان تتوليان التأطير، nf_conntrack_proto_gre و nf_nat_proto_gre. ووحدتان أخريان تتوليان معرّف المكالمة، nf_conntrack_pptp و nf_nat_pptp. تحميل الأخيرة منهما يجذب الباقي عبر التبعيات، لذا يجب أن تُظهر قائمة الوحدات الأربع جميعًا.

تستخدم التعليمات الأقدم بادئة ip_ من حقبة 2.6. قد تبدو تلك الأوامر كأنها تعمل بينما لا تُحمّل شيئًا، لذا افحص القائمة المحمّلة بدلًا من حالة الخروج.

لم يعد تحميلها كافيًا. منذ Linux 4.7 يكون الافتراضي لمتغير sysctl net.netfilter.nf_conntrack_helper هو 0، وهو ما يعطّل الإسناد التلقائي للمساعدات للتدفقات الجديدة. قد يمتلك الموجّه كل وحدة ومع ذلك لا يترجم شيئًا. افحص القيمة الفعّالة قبل أن تفحص قائمة الوحدات مرة أخرى.

إما أن تعيد تشغيل الإسناد التلقائي عالميًا، أو تربط المساعد بالتدفقات التي تحتاجه وتترك كل شيء آخر وشأنه:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

الخيار الثاني هو المفضّل. فهو يحصر السلوك في حركة PPTP بدلًا من إعادة تمكين الإسناد التلقائي على مستوى الموجّه.

فتح بروتوكول بلا منافذ

قاعدة جدار حماية تسمح بـ 1723 لا تقول شيئًا عن البروتوكول 47. على firewalld، اسمح بالبروتوكول في المنطقة المواجهة للعميل. وعلى iptables العادي، اقبل البروتوكول gre في سلسلة الإدخال.

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

بعد الاتصال، حدّ الحجم

يضيف GRE ترويسة، ويضيف PPP داخلها المزيد، لذا يُبلّغ رابط عامل عن MTU أقل بكثير من 1500. تُحمّل الردود الصغيرة وتتعطل الكبيرة، وهذا يبدو كمشكلة ثانية غير ذات صلة تظهر في اللحظة التي تُحل فيها الأولى.

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

إصلاح المسار يعيد المستخدم إلى العمل، ولا يجعل PPTP خيارًا جيدًا. إن MS-CHAPv2 وRC4 مهجوران منذ وقت طويل، لذا تعامل مع تحميل الوحدة كإصلاح مؤقت وخطّط للانتقال إلى بروتوكول مدعوم.