PPTP داخل Docker يوثّق الاتصال لكنه لا ينقل أي بيانات

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

خمسة فحوص، بالترتيب الذي يوفّر أكبر قدر من الوقت.

الفحص 1: افصل قناة التحكم عن البيانات

يثبّت PPTP عبر TCP 1723 ثم يحمل بيانات PPP داخل GRE، بروتوكول IP رقم 47. GRE ليس TCP ولا UDP، لذا كل قاعدة تمرّر منفذ التحكم لا تقول عنه شيئًا. قد تُسقط NAT أو جدار ناري يمرّر 1723 البروتوكول 47 دون شكوى، وتبقى الجلسة نصف مبنية بطريقة تبدو كنجاح.

إذا نجح تسجيل الدخول ولم تعد أي حزمة، افترض GRE أولًا وأثبت ذلك ثانيًا.

الفحص 2: تأكد من مساعد النواة على المضيف

لا يستطيع تتبع الاتصالات ربط اتصال تحكم TCP بتدفق GRE دون مساعد. الوحدة هي nf_conntrack_pptp، وهي تعيش في نواة المضيف، وتحميلها داخل صورة الحاوية لا يحقق شيئًا لأن الوحدات على مستوى المضيف كله. lsmod | grep nf_conntrack_pptp على مضيف Docker هو الفحص. إذا كانت مفقودة، يحمّلها modprobe nf_conntrack_pptp للنواة العاملة ولا يخبرك شيئًا عن الإقلاع التالي، لذا أضفها إلى إعداد المضيف أيضًا.

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

الفحص 3: اقرأ سياسة النواة التي تعطّله

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

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

الفحص 4: انظر إلى مسار الحاوية بشكل منفصل

المساعد المحمّل لا ينشئ مسارًا. تحتاج الحاوية مسارًا إلى خادم PPTP، ويجب أن يسمح تمرير المضيف بـ GRE في الاتجاهين: iptables -L FORWARD -v -n يُظهر ما إذا كان البروتوكول 47 مقبولًا وما إذا كانت العدادات تتحرك. قواعد masquerade في Docker تترجم TCP وUDP، لا البروتوكول 47، لذا قد تحتاج حاوية جسرية إلى قبول تمرير صريح، وعلى بعض المضيفين، إلى قاعدة ترجمة خاصة بها. تأكد أيضًا من أن الحاوية لديها دعم جهاز PPP الذي تتوقعه صورتها.

اقرأ العدادات بدل نص القاعدة. القاعدة التي توجد ولا تطابق شيئًا هي زينة.

الفحص 5: أثبت أن GRE متتبَّع، ثم قرّر بشأن PPTP

مع تشغيل العميل، اقرأ جدول التتبع. وجود إدخال تحكم PPTP قائم مع إدخال GRE مرتبط يعني أن المساعد يربط التدفقات وأن العطل المتبقي في مكان آخر. إدخال تحكم بلا إدخال GRE يعني أن البيانات تُسقط أو لا تُتتبع، وهذا يعيدك إلى الفحصين 2 و3.

PPTP نفسه قديم وMS-CHAPv2 ضعيف. إذا كان الخادم يوفر أيضًا L2TP/IPsec أو IKEv2 أو WireGuard، فإن الانتقال إلى أحدها يزيل هذه الفئة كاملة من المشاكل.

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