خادم PPTP خلف راوتر منزلي: أصلح 1723 وGRE أولًا

يفشل PPTP خلف راوتر منزلي بطريقتين غير مترابطتين، والخلط بينهما يضيع أمسية كاملة. أحد الأعطال فجوة في إعادة التوجيه: يمرر الراوتر TCP 1723 ويُسقط بروتوكول IP رقم 47، فيتوقف العميل عند الخطأ 619. والآخر مشكلة حجم: يرتفع النفق ويُصادق ثم يتجمد عندما تضطر حزمة بحجم كامل إلى العبور. وتحديد أي العطلين لديك هو الخطوة الحقيقية الأولى؛ أما الباقي فيقارن ما يستطيع راوترك التعبير عنه، لا أي علامة تجارية أفضل.

ناقلان، وواحد فقط له منفذ

ينقسم PPTP إلى ناقلين: اتصال تحكم على TCP 1723، وإطارات PPP ملفوفة في GRE المعزّز، وهو بروتوكول IP رقم 47. ولا يملك GRE رقم منفذ، لذا لا تستطيع قاعدة مكتوبة كتمرير منفذ 1723 أن تغطيه مهما صاغت واجهة الويب اسم الحقل. ويعرض الراوتر المنزلي عادة مربع اختيار باسم تمرير PPTP بدلًا من قاعدة بروتوكول، وذلك المربع يؤدي وظيفتين: يسمح بمرور البروتوكول 47 عبر الجدار الناري، ويعلّم NAT كيفية تتبع تدفق GRE. وعلى راوتر لينكس تكون تلك الوظيفتان وحدتين منفصلتين وقاعدتين منفصلتين، ولهذا ينتج تمرير نصف مُعدّل قناة تحكم تعمل. اكتشف أي نصف موجود قبل أن تغير أي شيء.

يجب أن يسمح جدار الحماية الخاص بالخادم أيضًا بالبروتوكول 47 من عنوان الراوتر. وجدار حماية مضيف يقبل 1723/tcp فقط يعيد إنتاج الخطأ 619 من داخل الشبكة المحلية، ما يجعل التمرير المعطوب وقاعدة المضيف المعطوبة يبدوان متطابقين.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

إذا كانت الوحدات مفقودة، فحمّلها بـ sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre واجعل التحميل دائمًا، لأن إعادة تشغيل تنسى المساعد تعيد النفق العامل إلى الخطأ 619. ولا تحتاج قاعدة التمرير إلى قبول البروتوكول 47 نحو عنوان الخادم فحسب، لا الشبكة المحلية بأكملها. ويعزل تعريف RFC 2637 مساري التحكم والبيانات، ولهذا لا توجد شاشة تمرير منفذ واحدة تصف PPTP وصفًا كاملًا.

مربع تمرير المرور أم قاعدة بروتوكول صريحة

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

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

عميلان خلف نفس NAT هما الحالة التي تفصل التمرير البسيط عن التمرير الذكي. فتمرير البروتوكول 47 دون إعادة كتابة معرفات الاستدعاء يتصرف عادة أفضل من مساعد يحاول إصلاحها.

قِس النفق قبل أن تلوم الراوتر

يقلّص PPTP الحمل الصافي، والتقلص حساب لا لغز. فكل حزمة نفق تحمل ترويسة IP خارجية وترويسة GRE معززة وترويسة PPP، ومع التشفير ترويسة MPPE. وعندما لا يستطيع المسار حمل الإطار الناتج، تمر الحزم الصغيرة، ويكتمل تسجيل الدخول، ثم تتوقف الجلسة أول مرة يرسل فيها نقل ملف أو مصافحة TLS حزمة بحجم كامل.

احسب الرقم بدلًا من تخمينه. يكلّف GRE المعزز 8 بايتات، وPPP يكلّف 4، وMPPE يكلّف 4، وترويسة IP الخارجية تكلّف 20، فيأكل النفق 36 بايتًا قبل أي حمل صافٍ. على WAN من نوع PPPoE يبلغ حده 1492، تكون أكبر قيمة MTU لـPPP تصحّ هي 1492 ناقص 36، أي 1456. اضبط mtu و mru على تلك القيمة في خيارات PPP وأعد الاختبار ببينج غير مجزّأ.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

يقيس البينج المسار لا النفق: 1464 بايتًا من الحمل الصافي زائد 28 بايتًا من ترويستي IP وICMP تملأ إطارًا من 1492 بايتًا بالضبط. فإن فشل ذلك البينج، فخفّض الرقم حتى ينجح ثم اطرح 36 من النتيجة. وضبط MTU النفق فوق حد المسار ينتج التجمّد دون أي سطر سجل يذكر الحجم إطلاقًا.

PPTP أو L2TP/IPsec أو OpenVPN على الراوتر نفسه

يمكن للراوتر نفسه أن يحمل أيًا من الأنفاق الثلاثة الشائعة، والفرق فيما عليه التعبير عنه. يحتاج PPTP إلى قاعدتين في طبقتين مختلفتين. ويحتاج L2TP فوق IPsec إلى UDP 500 و4500 لتبادل المفاتيح، وإلى البروتوكول 50 للحمل الصافي إلا إذا حمله NAT-T. ويحتاج OpenVPN إلى منفذ UDP واحد ولا مساعد إطلاقًا.

عمود L2TP ليس أرحم تلقائيًا من GRE. فـESP هو البروتوكول 50 ولا منفذ له أيضًا، لذا قد يعاني راوتر يتعثر مع البروتوكول 47 مع البروتوكول 50 للسبب نفسه. وُجد NAT-T ليلف ESP داخل UDP 4500، وعندما يدعمه الطرفان تصبح قاعدة البروتوكول 50 غير لازمة. وهذه خاصية في الطرفين لا في مربع PPTP في الراوتر. تأكد من التغليف الذي تفاوض عليه العميل فعلًا قبل كتابة قواعد للاثنين.

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

ما تُصلحه وما تستبدله

إصلاح التمرير وMTU يمنحك نفقًا يعمل، لا نفقًا ينبغي أن تحتفظ به. فمصادقة MSCHAPv2 في PPTP قابلة للهجوم منذ سنوات، والنفق العامل ينقل بيانات اعتماد يمكن استعادتها دون اتصال. فإن كان الجهاز البعيد يستطيع تشغيل L2TP/IPsec أو OpenVPN، فاعتبر الإصلاح إجراءً مؤقتًا بتاريخ محدد.

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

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