ضبط MTU وMSS في WireGuard: عندما يعمل ping وتتوقف الصفحات

النفق متصل، والـping ينجح، والدخول عبر SSH يعمل. ثم تفتح موقعاً فيتوقف التحميل عند منتصف الصفحة، أو يتجمد نقل ملف بعد بدايته. لا رسالة خطأ واضحة، والمصافحة سليمة.

هذا العرَض يشير في أغلب الحالات إلى مشكلة واحدة: حجم الحزمة. الحزم الصغيرة تمر، والكبيرة تضيع. وهذا الدليل يشرح السبب، وكيف تجد القيمة الصحيحة بالقياس لا بالتخمين.

ما هو MTU، وما هو MSS؟

MTU هو أكبر حجم لحزمة IP تمر عبر واجهة دون تجزئة. والقيمة الشائعة على إيثرنت هي 1500 بايت.

MSS خاص بـTCP، وهو أكبر حجم للبيانات داخل المقطع الواحد، دون ترويسات IP وTCP. لذلك يكون أصغر من MTU دائماً.

تخيّل شاحنة تمر تحت جسر. الـMTU ارتفاع الجسر، والـMSS حجم البضاعة بعد احتساب الصندوق. فالبضاعة يجب أن تصغر كلما زادت طبقات التغليف.

لماذا تصغر الحزمة داخل النفق؟

يأخذ WireGuard الحزمة كاملة، ويشفّرها، ثم يضعها داخل حزمة UDP جديدة. وهذا الغلاف يأخذ من الحجم المتاح:

• 60 بايت إذا كان الاتصال الخارجي عبر IPv4.
• 80 بايت إذا كان الاتصال الخارجي عبر IPv6.

لهذا يضبط wg-quick القيمة عادة على 1420. فهي 1500 ناقص 80، وتناسب الحالتين معاً. وهي قيمة آمنة لرابط 1500 كامل.

لكن المشكلة تبدأ حين لا يكون الرابط الخارجي 1500. فاتصالات PPPoE مثلاً تعطي 1492 أو أقل، وقد توجد في الطريق أنفاق أخرى تأكل منه أيضاً.

القاعدة بسيطة: MTU النفق يساوي MTU الرابط ناقص 60 أو 80. وMSS يساوي MTU النفق ناقص 40 لـIPv4، أو ناقص 60 لـIPv6 الداخلي.

مثال حسابي من واقع فرع

لنفترض فرعاً يتصل عبر PPPoE، فالرابط الخارجي 1492. ويتصل النفق عبر IPv4، فالغلاف 60 بايت. يبقى للنفق 1432. ولو أردت قيمة واحدة تصلح أيضاً لاتصال IPv6، فاطرح 80 لتحصل على 1412.

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

لماذا لا يخبرك أحد بالمشكلة؟

نظرياً، حين تكون الحزمة أكبر من المسموح، يرسل جهاز في الطريق رسالة ICMP تقول «حزمتك كبيرة»، فيصغّرها المرسل. وهذا ما يسمى اكتشاف MTU المسار.

لكن بعض الجدران النارية تحجب ICMP كله. فتُرمى الحزمة بصمت، ولا يعرف المرسل شيئاً، ويعيد إرسالها بالحجم نفسه. وهذا ما يفسّر الأعراض الغريبة: المصافحة صغيرة فتنجح، وصفحات الإنترنت الكبيرة تتوقف.

ولهذا فإن حجب ICMP كله ليس أماناً إضافياً. فهو يكسر آلية يحتاجها الاتصال.

كيف تقيس القيمة الصحيحة؟

استعمل ping مع منع التجزئة، وزد الحجم أو أنقصه حتى تجد الحد. وتذكّر أن الرقم الذي تعطيه لـping هو البيانات فقط، ويضاف إليه 28 بايت هي ترويسات IP وICMP.

ابدأ بقياس الرابط الخارجي دون نفق، من العميل إلى السيرفر:

# لينكس: 1472 + 28 = 1500
ping -M do -s 1472 -c 3 203.0.113.10

# ويندوز
ping -f -l 1472 203.0.113.10

إذا فشل الأمر، فأنقص الحجم تدريجياً حتى ينجح. أكبر رقم ناجح مضافاً إليه 28 هو MTU المسار. ولاحظ أن بعض الشبكات لا ترد على ping، فغياب الرد لا يثبت وحده مشكلة الحجم، لذا جرّب حجماً صغيراً أولاً.

ثم اختبر داخل النفق:

# 1392 + 28 = 1420
ping -M do -s 1392 -c 3 10.66.66.1

إذا نجح هذا، فـMTU النفق 1420 يعمل فعلاً. وإن فشل، فخفّض القيمة:

# تجربة مؤقتة تزول عند إعادة تشغيل النفق
ip link set dev wg0 mtu 1380

# تثبيت دائم في /etc/wireguard/wg0.conf
[Interface]
MTU = 1380

اضبط القيمة على الطرفين. فإذا عمل السيرفر بقيمة والعميل بأخرى، فقد تجد اتجاهاً سليماً وآخر معطوباً.

تثبيت MSS: الحل الذي ينقذ الموقف

حين يمرر سيرفر أو راوتر حركة أجهزة أخرى، فهذه الأجهزة لا تعرف شيئاً عن النفق، وتظن أن MTU لديها 1500. وهنا يفيد تثبيت MSS: يعدّل الموجّه رقم MSS أثناء بدء اتصال TCP، فيتفق الطرفان منذ البداية على مقاطع تناسب النفق.

على سيرفر لينكس:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

ويمكن إضافته إلى PostUp في ملف الإعداد، مع القاعدة المقابلة في PostDown بالخيار -D.

وعلى MikroTik بنظام RouterOS v7:

/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn \
    out-interface=wg0 action=change-mss new-mss=clamp-to-pmtu \
    passthrough=yes

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

الشبكات المتنقلة والعملاء المتجولون

الفرع له طريق ثابت نسبياً، أما الموظف المتنقل فلا. فقد يعمل حاسوبه من شبكة المكتب صباحاً، ومن هاتفه ظهراً، ومن شبكة فندق مساءً. ولكل شبكة حد مختلف.

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

كيف تتأكد بعد التعديل؟

لا تكتفِ بنجاح ping. افتح صفحة ثقيلة، ونزّل ملفاً كبيراً، ثم ارفع ملفاً عبر النفق. فالمشكلة قد تظهر في اتجاه واحد. وإن نجحت الاختبارات الثلاثة في عدة أوقات، فاكتب القيمة في توثيق الشبكة مع سبب اختيارها.

أخطاء شائعة

• خفض MTU كثيراً احتياطاً. القيمة الصغيرة جداً تعني ترويسات أكثر لنفس البيانات، فتهدر جزءاً من الرابط دون حاجة.
• نسخ قيمة من الإنترنت. ما يصلح لشبكة غيرك قد لا يصلح لشبكتك. قس طريقك أنت.
• نسيان IPv6. إذا كان الاتصال الخارجي عبر IPv6، فالغلاف أكبر بعشرين بايت.
• الاختبار بـping صغير. نجاح ping العادي لا يثبت أن الحزم الكبيرة تمر.

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

الخلاصة

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

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