ping عبر VPN: لماذا تُخطئ قواعد رد الصدى المسار العائد

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

الحزمة تغيّر النوع لا المنفذ

طلب الصدى هو ICMP من النوع 8 والرمز 0، ويحمل مُعرِّفاً ورقم تسلسل. أما الرد فهو من النوع 0 والرمز 0، بالمُعرِّف ورقم التسلسل نفسهما، مع تبديل طرفي IP. يحدد RFC 792 تلك الحقول، والمُعرِّف هو ما يتيح للمرسل مطابقة الردود بطلباته.

وغياب بعض الحقول لا يقل أهمية: لا توجد ترويسة TCP أو UDP، وبالتالي لا يوجد منفذ للسماح به. القاعدة التي تسمّي منفذاً لرد الصدى تصف حزمة لن توجد أبداً. هذا هو الخطأ الأكثر شيوعاً في تذاكر ping الخاصة بـ VPN. تبدو القاعدة محددة، ولا تنطبق على شيء، وتترك الخلل في مكانه بالضبط.

ثلاثة سياقات تحدد الحزمة

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

لهذه السياقات الثلاثة سلاسل قواعد وعدادات مختلفة، واعتبارها سياقاً واحداً هو سبب أن «الجدار الناري يسمح بـ ICMP» قد يظل ينتج ping فاشلاً. أما النفق الخارجي فهو سياق رابع: السماح لمستمع VPN لا يسمح تلقائياً بالطلب الداخلي بعد فك التغليف، والسماح الداخلي لا يقول شيئاً عن كون النفق الخارجي قائماً.

المرشّحات ذات الحالة وبلا حالة تتعامل مع الرد بشكل مختلف

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

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

حدّد نطاق ما تسمح به. السماح بكل رد صدى من أي مكان ليس مثل إكمال اقتران ذي حالة، ورقم النوع لا يوثّق هوية المرسل.

الترجمة تغيّر المُعرِّف أيضاً

إذا كانت ترجمة المصدر مقصودة، فإن الصف عند الطرف البعيد لا يطابق ما أرسله العميل. يمكن لـ NAT أن يترجم مُعرِّف استعلام ICMP مع العناوين، لذا فإن الإصرار على ظهور الرقم نفسه على الجانبين ينتج عدم تطابق زائف.

اربط بدلاً من ذلك بالخريطة التي يبلّغ عنها المترجم. المترجم الذي يعيد كتابة المُعرِّف لن يحافظ على الرقم الذي سجّله عميلك، لذا اعتبر الخريطة هي الهوية وليس الرقم. ثم تتبّع طلباً واحداً قابلاً للتعرّف عليه عبر المسار: أكّد أنه يصل إلى الوجهة بالمصدر المتوقع، وأكّد أن الوجهة أصدرت رداً، تتبّع مسار ذلك الرد عائداً، وأكّد أن العميل استلمه بدلاً من مجرد مراقبة ارتفاع عدّاد على البوابة.

لا تدمج أخطاء ICMP في سياسة الصدى

رسالة «الحاجة إلى التجزئة» التي يستخدمها اكتشاف MTU للمسار ليست رد صدى، وحمولتها تقتبس الحزمة التي أطلقتها. السماح بالصدى فقط مع التخلّص الصامت من تلك الأخطاء يحوّل مشكلة حجم إلى اتصال معلّق، وهو عكس المفيد.

ينطبق التحذير نفسه على عائلات العناوين. يستخدم ICMPv6 أنواع رسائل مختلفة ويحمل وظائف أساسية لا يملكها IPv4، لذا فإن نسخ هذه الأرقام في قاعدة IPv6 خطأ ببساطة.

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