ضبط MSS وMTU لنفق WireGuard على MikroTik

النفق يعمل، وping سليم، والصفحات الصغيرة تفتح. ثم يتعلق موقع معين، أو يبدأ تحميل ولا يكمل، أو يتوقف رفع ملف في منتصفه. إن رأيت هذه الأعراض على WireGuard فابدأ بفحص MTU وMSS قبل أن تتهم السيرفر أو الخط.

السبب أن ping العادي يرسل حزمة صغيرة، فتمر بسهولة. أما المشكلة فتظهر مع الحزم الكبيرة التي تحمل البيانات الفعلية. وهذا الدليل يشرح الفكرة ثم يعطيك أوامر RouterOS v7 الصحيحة.

الفرق بين MTU وMSS بكلام بسيط

MTU هو أكبر حجم لحزمة IP كاملة على الرابط. أما MSS فهو أكبر حجم لبيانات TCP داخل الحزمة، أي بعد خصم ترويسة IP وترويسة TCP.

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

WireGuard يضيف 60 بايتاً فوق IPv4 و80 بايتاً فوق IPv6. ولهذا فالقيمة الافتراضية 1420 مناسبة لخط عادي بحجم 1500، لأنها تترك مجالاً حتى للنقل فوق IPv6.

الحساب بسيط: MSS لـIPv4 يساوي MTU ناقص 40. ولو كان فوق خطك نفق آخر، أو كان مسار الإنترنت يخفض الحجم، فالقيمة الصحيحة ستكون أقل. ولذلك نقيس ولا نفترض.

كيف تتأكد أن هذه هي المشكلة؟

أرسل حزماً بحجم محدد مع منع التجزئة. في RouterOS يشمل حقل size ترويسات الحزمة، لذا يقابل الرقم MTU مباشرة.

/ping 10.66.66.1 size=1420 do-not-fragment count=5
/ping 10.66.66.1 size=1400 do-not-fragment count=5
/ping 10.66.66.1 size=1300 do-not-fragment count=5

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

ولاحظ أن فحص الاتجاهين مفيد. فالمسار من السيرفر إلى المكتب قد يختلف عن عكسه، خاصة على خطوط المشتركين. لذلك نفّذ الفحص نفسه من السيرفر بالأمر ping -M do -s 1392 10.66.66.2، فلينكس يضيف 28 بايتاً إلى الرقم الذي تكتبه، فتكون الحزمة 1420.

ضبط MTU على الواجهة

إذا أثبت القياس أن المسار أقل من 1420، فخفّض MTU على طرفي النفق معاً. لا تعدّل طرفاً وتنسى الآخر.

/interface wireguard set wg0 mtu=1380

الرقم 1380 مثال لقيمة أقل، وليس توصية عامة. اختر ما خرجت به من القياس. وعلى سيرفر لينكس عدّل MTU في قسم [Interface] بملف wg-quick، ثم أعد تشغيل الواجهة في وقت مناسب.

ضبط MSS على MikroTik

خفض MTU لا يكفي دائماً. فالأصل أن يكتشف الجهازان حجم المسار عبر رسائل ICMP، لكن هذه الرسائل تُحجب أحياناً في الطريق. فيرسل الجهاز حزماً كبيرة لا تصل، ولا يعرف السبب.

الحل أن يعدّل الراوتر قيمة MSS في حزم SYN عند بدء الاتصال. فيتفق الطرفان منذ البداية على حجم مناسب.

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

هاتان القاعدتان تغطيان الاتجاهين، ولا تمسان إلا ترافيك TCP عبر النفق. ولا تأثير لهما في UDP. ولأن القاعدتين تعملان على حزم SYN، فهما لا تتعارضان مع FastTrack الذي يبدأ عمله بعد قيام الاتصال.

وإن أردت رقماً ثابتاً، فهذه صيغة تعتمد على القياس:

/ip firewall mangle
add chain=forward protocol=tcp tcp-flags=syn out-interface=wg0 \
    tcp-mss=1381-65535 action=change-mss new-mss=1380 \
    passthrough=yes comment="wg-mss-fixed"

الشرط tcp-mss=1381-65535 يعدّل القيم الأكبر فقط. فلا يرفع قيمة صغيرة أصلاً، وهذا مهم حتى لا تفسد إعداداً سليماً. استعمل طريقة واحدة، ولا تجمع بين الرقم الثابت وclamp-to-pmtu على الاتجاه نفسه.

لا تحجب ICMP بلا تفكير

كثير من مشكلات MTU يصنعها جدار ناري متشدد. رسائل ICMP من نوع «الحزمة كبيرة» هي الطريقة الطبيعية لاكتشاف حجم المسار. فاسمح بالرد المرتبط بالاتصالات القائمة، وهو ما تفعله قاعدة established,related في الجدار السليم.

لماذا تظهر المشكلة مع مواقع دون غيرها؟

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

وتتكرر الصورة نفسها مع الخدمات الداخلية. فقد يفتح الموظف صفحة دخول النظام، ثم يتعلق عند تحميل تقرير كبير. لاحظ متى يحدث التعلق، فهذا أسرع دليل لك: بعد الاتصال مباشرة، أم عند نقل بيانات كبيرة؟

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

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

قائمة تحقق بعد التعديل

1. افتح المواقع التي كانت تتعلق، ولا تكتفِ بصفحة البحث.
2. نزّل ملفاً كبيراً، وارفع ملفاً كبيراً، وراقب الاستمرار.
3. راقب العدادات بالأمر /ip firewall mangle print stats، فزيادتها تعني أن القواعد تعمل.
4. جرّب من جهازين مختلفين، أحدهما على الكابل والآخر على الشبكة اللاسلكية.

ضبط هذه القيم يزيل التعلق، لكنه لا يزيد السعة. فإن بقي النفق بطيئاً تحت الحمل، فانظر إلى قوة الطرفين. والقرب ليس كل شيء: سيرفر قريب بمعالج مشغول لن يعطيك نفقاً مستقراً. وعلى أحد سيرفراتنا بلغ التنزيل عبر النفق 57MB/s على منفذ حده النظري 60MB/s، أي أن العتاد لم يكن هو السقف. وهذا قياس سيرفر، ولا نعطي رقماً لـMikroTik لأننا لم نقسه.

الخلاصة

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

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