أخطاء MTU و PMTUD: لماذا تعمل بعض المواقع وتتعطل أخرى؟

إذا كانت صفحات صغيرة تعمل بينما تتجمد عمليات تحميل أكبر، فقد تكون المشكلة في اكتشاف حجم الحزم عبر المسار. يشرح هذا الدليل MTU و MSS و PMTUD و DPLPMTUD، وكيف تختبر الفرضية دون تغيير إعدادات الشبكة عشوائيًا.

اللغز: صفحة تعمل وأخرى تتجمد

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

الفرق بين MTU و MSS والحمولة

من المهم الفصل بين MTU على واجهة الشبكة، و MSS الذي يحدد حجم بيانات TCP داخل المقطع، وحجم الملف أو استجابة HTTP. يمكن نقل ملف حجمه جيجابايتات عبر آلاف الحزم الصغيرة؛ فلا يعني وجود حد MTU منخفض أن الملفات الكبيرة محظورة بذاتها. لكن اختلاف الحجم الفعال بين طرفين قد يؤثر في تقطيع البيانات ونقلها وإعادة الإرسال. تضيف ترويسات IP و TCP أو UDP والتغليف في VPN تكلفة إلى كل حزمة، ولذلك لا يكفي نقل قيمة MTU من إعداد جهاز آخر إلى شبكتك. حتى عندما يظهر رقم شائع في واجهة Ethernet، قد تكون وصلة PPPoE أو نفق أو مسار خارجي أقل قدرة. ابدأ بتحديد الواجهات والطبقات التي تمر عبرها حركة الخدمة المتعثرة.

كيف يعمل الاكتشاف التقليدي PMTUD؟

يسعى اكتشاف MTU للمسار إلى تحديد أكبر حجم يمكن إرساله عبر الطريق. في النمط التقليدي، قد يرد جهاز على الطريق برسالة ICMP من نوع Packet Too Big أو ما يقابلها حين يتجاوز حجم الحزمة الحد المسموح. يستطيع المرسل عندها خفض الحجم الذي يستخدمه. إذا مُنعت هذه الرسالة في جدار ناري أو لم تصل لأي سبب، قد يواصل المرسل إرسال حزم لا تعبر الطريق، فتبدو الجلسة معلقة رغم نجاح خطواتها الأولى. لا تعني هذه الآلية أن السماح بكل أنواع ICMP دون سياسة أمنية هو الحل؛ بل ينبغي السماح برسائل التحكم اللازمة مع التحقق منها حسب تصميم الشبكة. كما تختلف قواعد IPv4 و IPv6 المتعلقة بالتجزئة ورسائل الحجم.

ما الذي تضيفه DPLPMTUD؟

تشرح RFC 8899 آلية لاكتشاف حجم الحزم على مستوى طبقة تكوين الرزم للاتصالات المعتمدة على datagrams. تستخدم الآلية مجسات بأحجام مختلفة وتأكيد نجاح وصولها عند توفر وسيلة مناسبة، ويمكنها خفض الحجم بعد اكتشاف فقد مرتبط به. لا تعتمد هذه المقاربة اعتمادًا كاملًا على وصول رسالة ICMP لتقدير المسار، وهو ما يساعد في البيئات التي تُحجب فيها رسائل التحكم. لكن نجاحها يعتمد على تنفيذ البروتوكول والتطبيق وطبيعة تأكيد الاستلام، فلا تفترض أن كل تطبيق UDP أو QUIC ينفذ التفاصيل نفسها. اقرأ المواصفة بوصفها أساسًا هندسيًا لتفسير الظاهرة، وليس وصفة لتغيير قيمة ثابتة في الراوتر.

لماذا تظهر المشكلة مع VPN أكثر؟

غالبًا ما يضيف النفق ترويسات تشفير وتغليف فوق الحزمة الأصلية، فتقل المساحة المتاحة للبيانات ضمن حد MTU على الطريق الخارجي. إذا كان التطبيق أو النظام لا يكتشف الحجم المناسب، قد تنجح الاتصالات الصغيرة وتتعثر حمولات أكبر. لا يثبت ذلك أن مزود VPN سيئ أو أن التشفير نفسه سبب البطء؛ فقد يكون ضبط النفق أو المسار أو حجب رسائل التحكم أو مشكلة في DNS. قارن نفس الوجهة ونفس الجهاز مع النفق وبدونه، وسجل عناوين الاتصال ونوع البروتوكول المستخدم. إذا كانت المشكلة في النفق وحده، راجع وثائق العميل والخادم وإعدادات MTU و MSS قبل خفض أي قيمة. تغيير طرف واحد قد لا يكفي أو قد يخلق مشكلة جديدة.

اختبار عملي تدريجي

ابدأ بالتحقق من أن الموقع يعمل من شبكة ثانية، ثم جرّب نفس الخدمة من جهازك عبر الاتصال السلكي و Wi-Fi، مع النفق وبدونه عند وجوده. سجل إن كان التعثر يحدث في DNS أو TCP أو TLS أو أثناء نقل الجسم؛ فقد يوجهك ذلك إلى مشكلة مختلفة تمامًا. على أنظمة تملكها، يمكن استخدام أدوات فحص حجم الحزمة مع خيارات منع التجزئة حيث يدعم النظام ذلك، مع الانتباه إلى أن بعض الوجهات تمنع ping ولا ينبغي تفسير صمتها كإثبات. عند الحاجة، التقط رؤوس حزم محدودة في الطرفين بموافقة المسؤول لمراقبة الحجم ورسائل ICMP وعمليات إعادة الإرسال. تجنب اختبار ضغط كثيف أو نشر لقطات تتضمن محتوى مستخدمين.

ما الذي يعنيه MSS Clamping؟

تستخدم بعض الشبكات ضبط MSS المعلن في مصافحة TCP لتقليل حجم مقاطع البيانات المرسلة عبر مسار ذي تغليف إضافي. قد يكون هذا حلًا تشغيليًا مناسبًا في بعض بوابات VPN أو الراوترات، لكنه ليس علاجًا عامًا لكل حركة UDP أو QUIC، ولا ينبغي نسخه دون معرفة قيم الرؤوس والمسار. كما أن تغيير MSS في نقطة وسيطة لا يصلح دائمًا خلل اكتشاف MTU لدى التطبيقات الأخرى. قارن السلوك قبل الضبط وبعده على جلسات TCP فعلية، ثم اختبر بروتوكولات أخرى بصورة مستقلة. وثّق القيمة القديمة وأثرها في زمن النقل ومعدل الفشل. إن كانت المشكلة الأساسية في فلترة رسائل Packet Too Big، فقد يكون تصحيح سياسة الشبكة أنسب من الاعتماد على حل تعويضي دائم.

التشخيص لا يقتصر على رقم واحد

قد تظهر أعراض مشابهة بسبب انقطاع TLS أو أخطاء شهادة أو خادم يرفض الطلبات الكبيرة أو سياسة WAF أو بطء في قاعدة البيانات أو مشكلة CDN. لهذا لا تكتفِ بتخفيض MTU حتى تختفي المشكلة؛ فقد تتغير النتيجة بسبب إعادة إنشاء الاتصال أو تغيير المسار في اللحظة نفسها. استخدم جدولًا يسجل حالة الطلبات الصغيرة والكبيرة، ونجاح IPv4 و IPv6، والعمل مع VPN وبدونه، وحالة DNS و TLS، وأحجام الحزم إن أمكن. إذا ظهر نمط واضح لفقد الحزم عند تجاوز حجم معين عبر مسار محدد، تصبح فرضية PMTUD أقوى. أما إن فشلت الطلبات بالحجم نفسه على كل المسارات فابحث في إعدادات التطبيق.

دراسة حالة إرشادية دون أرقام مزيفة

تخيل شركة تستخدم نفقًا للوصول إلى تطبيق داخلي: تظهر صفحة تسجيل الدخول بسرعة لكن تنزيل تقرير طويل يتوقف. الخطوة الأولى هي التأكد من أن التقرير يُنشأ على الخادم، وأن الطلب لا يفشل بسبب الصلاحيات أو مهلة التطبيق. بعدها تُقارن جلسة من داخل الشبكة مباشرة بجلسة عبر النفق، ثم يُراجع حجم الحزم الفعلي ورسائل التحكم في الطرفين. إذا اختفت المشكلة بعد تصحيح سياسة Packet Too Big أو ضبط موثق للنفق، تُعاد تجربة ملفات مختلفة وأوقات ضغط متنوعة. هذه الحالة مثال على تسلسل تشخيص، لا نتيجة اختبار أُجري بالفعل ولا توصية بقيمة MTU محددة. الاحتفاظ بفرضيات بديلة يحمي الفريق من إصلاح خاطئ.

اختبار الانحدار بعد أي تعديل

ينبغي اختبار صفحات صغيرة وكبيرة، وتحميل ملفات ورفعها، واتصالات طويلة العمر، وعمل IPv4 و IPv6، وتطبيقات تستخدم TCP و UDP إن كانت ضمن نطاق الخدمة. راقب معدل الفشل والوسيط والمئين 95 للتأخير، لا مجرد نجاح تحميل واحد. إن حسّن التغيير اتصالًا معينًا لكنه أبطأ جميع الاتصالات الأخرى، فقد تكون كلفته أعلى من فائدته. سجّل القيم القديمة وخطة التراجع، واختبر من أكثر من شبكة ومزود عند الإمكان. تجنب تنفيذ تغيير شامل على راوتر إنتاج أثناء وقت الذروة دون خطة استعادة، خاصة عندما يستخدمه فريق أو موقع حي. للمزيد راجع مقال إيجي تاج عن <a href='/ar/articles/packet-loss-dns-tls-network-diagnostics'>تشخيص فقد الحزم وتأخر TLS</a>.

خلاصة ومراجع

الفرق الحاسم هو بين ملاحظة أن صفحة كبيرة لا تعمل وبين إثبات أن الحزم تتجاوز Path MTU ولا تصل إشارات التصحيح. ابدأ بفصل طبقات الطلب، وقارن المسارات، ثم استخدم قياسات حجم حزم مصرحًا بها وسجلات الطرفين قبل أي ضبط. اقرأ مواصفة IETF RFC 8899 عن Datagram Packetization Layer Path MTU Discovery: https://www.rfc-editor.org/info/rfc8899/؛ وتوضح الفروق بين اكتشاف المسار التقليدي والآليات التي تستخدم المجسات. لا تقدم هذه المواصفة قيمة جاهزة لكل VPN أو جهاز. القرار الصحيح يتطلب معرفة نوع النفق والتغليف والراوتر والبروتوكول والحد الفعلي للوصلات.