عدم عمل النفق المنقسم في PPTP: أصلح مسار GRE أولاً

شاهد اتصال PPTP وهو يقوم، وسيسهل عليك تصديق أن الجزء الصعب قد انتهى: يوثق العميل نفسه، ويظهر محول ppp0 أو WAN Miniport، وتتحول نافذة الحالة إلى الأخضر. ثم تنتهي مهلة أول طلب إلى مضيف داخلي، ويُلام الملف الشخصي. في الواقع هناك طبقتان مستقلتان يجب تجاوزهما: النقل الخارجي الذي يحمل TCP 1723 وGRE، والسياسة الداخلية التي تقرر أي الوجهات تستخدم واجهة PPP. الحالة الخضراء تثبت فقط أن الطبقة الأولى تفاوضت؛ ولا تقول شيئاً عن الثانية.

تتبّع العميل من الملف الشخصي إلى مأخذ التحكم

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

أكّد اتصال التحكم على الشبكة قبل أن تلمس أي مسار. على العميل أو منفذ مرآة، التقط TCP 1723 لمحاولة اتصال واحدة:

sudo tcpdump -ni any 'tcp port 1723' -c 20

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

GRE بروتوكول ثانٍ، وليس منفذاً

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

راقب البروتوكول 47 في نفس الالتقاط، ثم قارن ما يخرج بما يعود:

sudo tcpdump -ni any 'proto gre' -c 20

الحزم التي تخرج بلا ردود، بينما يبقى TCP 1723 سليماً، هي التوقيع الكلاسيكي لـ GRE المحجوب. تمرير PPTP على موجه منزلي ميزة في ذلك البرنامج الثابت تحديداً، لذا لا تثبت شبكة فندق تعمل شيئاً عن الشبكة التالية. إذا لم يقدم الموجه أي تمرير ولم تستطع تغييره، فاختيار البروتوكول هو المشكلة، لا جدول التوجيه.

أثبت أن النفق ينقل حزمة واحدة

بمجرد أن يتدفق GRE، تُسند مفاوضات PPP عنواناً لواجهة العميل. اقرأ الإسناد بدلاً من افتراضه:

ip -4 addr show ppp0

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

افعل ذلك قبل إضافة أي مسار منقسم. تغيير المسار أثناء انقطاع النقل ينتج متغيراً ثانياً ويخفي الأول.

اكتب سياسة التقسيم، بما في ذلك DNS

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

افحص القرار الذي يتخذه النواة لعنوان واحد في كل فئة:

ip route get 10.20.5.10
ip route get 203.0.113.25

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

فحص قابل للتكرار في خمس خطوات

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

نسخة مختصرة لعميل Linux تبدو هكذا:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

على Windows ينطبق الترتيب نفسه مع route print وحالة المحول المعروضة في العميل. PPTP بروتوكول قديم، وإذا كان الخادم يقدم SSTP أو IKEv2، فعادةً ما يكون الانتقال استخداماً أفضل للوقت من ضبط مسار يعتمد على مرور البروتوكول 47 في كل قفزة. افحص شهادة البديل وعقد المصادقة بدلاً من نسخ ملف شخصي قديم إلى إصدار جديد.