لماذا يؤدي حظر ICMP بالكامل إلى كسر مسار VPN عامل
رسائل التغذية الراجعة عن الحجم ليست ردود ping. عندما لا تصل أبداً، تنجح الحزم الصغيرة وتختفي الكبيرة، ويبدو النفق كأنه يتذبذب.
النفق الذي ينجح في المصادقة ويحمل ping ثم يتوقف عند أول نقل كبير هو العلامة الكلاسيكية لرسالة ICMP مفقودة لا لعطل في VPN. لا يعلم المرسل أبداً أن الحزمة كانت أكبر من اللازم، فيعيد المحاولة بالحجم نفسه، وينتظر التطبيق. إصلاح ذلك قرار في سياسة جدار الحماية، لا إعادة تثبيت للعميل. الترتيب مهم: قِس أين يقع حد الحجم، ثم ضيّق القاعدة التي ابتلعت التقرير.
ما يحمله ICMP فعلياً على هذا المسار
اكتشاف MTU للمسار في IPv4 يعتمد على أن يبلّغ الموجّه بأن حزمة عليها بت don't-fragment لم يكن بالإمكان تمريرها. ذلك التبليغ هو رسالة ICMP Fragmentation Needed، وبدونها لا يملك المرسل سبباً لتقليص حجم مقطعته. أما IPv6 فأكثر صرامة: الموجّهات لا تجزّئ أثناء العبور، لذا رسالة ICMPv6 Packet Too Big هي الإشارة الوحيدة التي تجعل المرسل يصغّر.
كلتا الرسالتين تغذية راجعة في مستوى التحكم، وليست أي منهما صدى تشخيصياً. السياسة التي تحظر ping والسياسة التي تحظر كل ICMP تبدوان متشابهتين في قائمة القواعد وتتصرفان بشكل مختلف جداً على الشبكة. الثانية قد تحوّل نفقاً بحجم صحيح إلى مسار أحادي الاتجاه لأي شيء أكبر من أصغر وصلة في السلسلة.
بعض وسائل النقل تنفذ اكتشافها الخاص بحزم استكشاف، كما تصف RFC 4821، وهي أقل اعتماداً على هذه التغذية الراجعة. هذا حجة لفحص وسيلة النقل التي تشغلها، لا لافتراض أن كل نفق محصّن.
| الرسالة | الغرض على المسار | إذا حُظرت |
|---|---|---|
| ICMPv4 النوع 3 الرمز 4 | كانت الحزمة أكبر من الوصلة التالية | يواصل المرسل إعادة المحاولة ثم يتوقف |
| ICMPv6 النوع 2 | Packet Too Big، المكافئ في IPv6 | التوقف نفسه، دون بديل للتجزئة |
| ICMP النوع 11 | تجاوز الوقت، يستخدمه traceroute | التشخيص يفقد القفزات، والحركة ما تزال تمر |
| طلب صدى ICMP ورده | اختبار الوصول | يفشل ping، وقد يكون المسار سليماً |
العطل يعتمد على الحجم
اسأل هل يرتبط العطل بحجم الحزمة. صفحة تسجيل الدخول واستعلام DNS ونداء API قصير تنجح، بينما يتوقف رفع ملف أو رد كبير أو تنزيل صورة. هذا النمط يشير إلى حد للحجم في مكان ما بين الطرفين، لا إلى المصادقة أو التوجيه. نجاح ping صغير لا يقول شيئاً تقريباً عن موضع ذلك الحد.
داخل النفق طبقتان يجب مراعاتهما: حزمة الحمولة والحزمة الخارجية المغلفة. يمكن للمرسل الداخلي أن يعمل بشكل صحيح بينما يكون المسار الخارجي أصغر مما يفترضه النفق، ولهذا يهم إعداد MTU الخاص بالنفق والرابط الفيزيائي تحته.
قِس قبل تعديل القواعد
استكشف ببت don't-fragment وبحجم حمولة تختاره، من العميل المعطوب نحو عنوان محمي:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7حمولة من 1472 بايتاً زائد 28 بايتاً من الترويسات تشكل حزمة من 1500 بايت. إذا فشل الاستكشاف الكبير بخطأ تجزئة ونجح الأصغر، فقد وجدت الحد؛ عدّل لتغطية أعباء النفق الإضافية وكرّر حتى يستقر الحجم العامل.
ثم أكّد أن الفجوة هي التقرير نفسه. إذا فشل الاستكشاف بصمت، بلا خطأ وبلا رد، فالرسالة على الأرجح تُسقَط لا تُسلَّم، والقاعدة هي المشتبه به.
ضيّق القاعدة، ثم أعد اختبار المهمة
يجب أن يسمح التصحيح برسائل التحكم المحددة، لا بالبروتوكول كله. على مضيف يعمل بـ iptables يكون الشكل سماحاً بنوع محدد؛ كيّف الصياغة مع ما يدير جدار الحماية على منصتك:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTأبقِ ردود الصدى محظورة إن كانت هذه هي السياسة المحلية، لأنها ليست ما يحتاجه المسار. ثم أعد اختبار النقل الذي فشل أصلاً، من اتصال جديد، وتأكد من أن عدادات القواعد تُظهر وصول الرسائل.
إذا استمر النقل الكبير في التوقف بعد السماح بالرسائل، فالحد المتبقي في مكان آخر: MTU نفق مضبوط على قيمة عالية جداً، أو وكيل يعيد كتابة الحزم، أو صندوق وسيط يُسقط بدل أن يبلّغ. كانت قاعدة ICMP ضرورية لا كافية.