MTU لكل مسار على Linux: ثلاثة عناصر تحكم في الحجم، ومسار واحد
تعمل وحدة MTU للواجهة ووحدة MTU للمسار وضبط MSS على طبقات مختلفة. اربط ميزانية بالمسار الذي يفوز في البحث، واجعل التغيير قابلاً للتراجع.
ثلاثة إعدادات على عميل Linux تبدو كلها كأنها «اجعل الحزم أصغر»، وهي تعمل على طبقات مختلفة. تحدد وحدة MTU للواجهة كل حزمة يرسلها الجهاز. وتحدد وحدة MTU للمسار الحزم التي تستخدم ذلك المسار، وهو غالباً ما تريده فعلاً لوجهة VPN واحدة. ويغيّر ضبط TCP MSS ما يتفاوض عليه الطرفان، ولا يفعل شيئاً لبروتوكول UDP.
ثلاثة عناصر تحكم تبدو كالمقبض نفسه
ضعها جنباً إلى جنب قبل الاختيار، لأن اختيار الصف الخاطئ يفسّر معظم النصائح التي لا تعمل:
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
خفض وحدة MTU للإيثرنت على مستوى الجهاز بأكمله هو النسخة الفجة من هذا الإصلاح. إنه يعمل، ويعاقب أيضاً كل تطبيق آخر على المضيف، بما في ذلك التطبيقات التي كانت مساراتها سليمة. وتعبر قيمة لكل مسار عن النية نفسها من دون التكلفة الجانبية.
لا تصح المقارنة إلا لحركة المرور التي يولّدها المضيف. أما تمرير حزمة لعميل آخر فيتضمن مسار ذلك العميل وميزانية النفق الخارجية، ولا تمتد أي مقاييس للمسار على هذا المضيف عبر تلك الحدود.
اربط الميزانية بالمسار الذي يفوز في البحث
يبدو سجل مسار IPv4 التوضيحي هكذا:
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380اقرأ السجل كوصف للنية، لا كقيمة تُلصق. يجب أن تطابق البادئة والجهاز والمصدر المفضّل الإعداد الفعلي، و يجب أن يأتي الرقم من أدلة حول المسار المُغلَّف لا من منشور مدونة. تحدّ وحدة MTU للمسار حزمة IP الداخلية، وهي ليست مثل حمولة TCP بحجم 1380 بايت أو حزمة خارجية مشفرة بحجم 1380 بايت.
انظر إلى أين يُحلّ البحث فعلياً قبل إضافة أي شيء. يمكن لمضيف لديه قواعد سياسة أن يوجّه وجهة معينة عبر جدول غير main، ومقياس موجود فقط في main يكون غير مرئي لذلك الطلب. قارن ip -4 route show table all بالجواب من ip route get، بما في ذلك سياق العلامة أو مساحة الأسماء عندما تستخدمها القواعد. وإذا اختلف الاثنان، فالجدول الذي أجاب هو الذي يحتاج إلى المقياس، لا الأكثر ترتيباً في المظهر.
mtu ليس mtu lock
افتراضياً يمكن للنواة تحديث وحدة MTU للمسار من تغذية ICMP الراجعة، وهذا هو الغرض من اكتشاف وحدة MTU للمسار. وإضافة lock توقف ذلك. إنه قرار مختلف، لا طريقة أقوى لحفظ الرقم نفسه، وهو يغيّر في IPv4 المعالجة الموثقة لبتّ «لا تجزئ».
يكون التثبيت معقولاً عندما تكون قد قست المسار وتريد أن تبقى القيمة مهما وصل. وهو افتراضي سيئ عندما ترسل الشبكة تغذية راجعة مشروعة عن الحجم، لأن النواة لم تعد قادرة على التعديل وينتقل العطل إلى عرض آخر.
إذا كانت ICMP مُرشّحة في مكان على المسار، فلا إعداد مسار يصلح ذلك. الإصلاح مكانه المرشّح، ووحدة MTU أصغر هي حل مؤقت يخفي العطل الحقيقي حتى يتغير المسار في المرة التالية.
تضيف برمجيات النفق مقابض تحجيم خاصة بها
OpenVPN mssfix يضبط حجم مقاطع TCP لحالة نفق UDP الموثقة. وهو يعمل على محادثة TCP، لذا ليس صيغة أخرى لوحدة MTU للمسار في نظام التشغيل، ولا يمكنه مساعدة خدمة UDP تتجاهل التفاوض.
لا تكدّس وحدة MTU للمسار وتغيير وحدة MTU للواجهة وضبط MSS في نافذة تغيير واحدة. إذا اختفت المشكلة فلن تعرف أيها كان مهماً، وستقيّد العناصر التي تبقيها حركة المرور لسنوات من دون سبب يتذكره أحد.
اجعله قابلاً للتراجع، ثم أثبته
المالك الحقيقي للمسار يقرر هل يبقى التغيير بعد إعادة الاتصال. عميل VPN يثبّت المسار ديناميكياً سيعيد بناءه عادةً من دون مقياسك، وعندها يبدو أمر ip route add اليدوي كإصلاح فشل بعد يوم. ضع القيمة في إعداد المدير، وإذا كنت تحتاج تجربة مؤقتة فسجّل المسار الأصلي أولاً.
اختبر باتصال جديد ينفّذ العملية التي تعطّلت، ثم أكّد أن المسار الخاص المقصود لا يزال يفوز وأن الوجهات غير ذات الصلة لم تتغير. أعد توصيل النفق واقرأ المسار مرة أخرى، لأن قيمة تختفي عند إعادة الاتصال ليست إصلاحاً.
إذا لم تدعم الأدلة التغيير، فأزل التجاوز عبر مديره وأعد سمات المسار الأصلية بدلاً من حذف المسار. ثم دوّن ما قسته وعلى أي مسار، ليتمكن الشخص التالي من التمييز بين تحسين حقيقي وتجربة تُركت تعمل.