.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
النفق متصل، وping يعمل، والمواقع الخفيفة تفتح. ثم تحاول فتح صفحة ثقيلة أو رفع ملف أو الدخول إلى لوحة تحكم، فيتوقف كل شيء عند منتصف التحميل بلا رسالة خطأ. هذا العَرَض يبدو كأنه عطل في السرعة أو في المواقع نفسها، لكنه في أغلب الحالات مشكلة حجم حزمة لا مشكلة سرعة.
نشرح هنا معنى MTU وMSS بلغة بسيطة، وكيف تقيس الحجم الصحيح على نفقك، وكيف تصلح المشكلة بقاعدة واحدة بدل تجربة أرقام عشوائية.
ما الفرق بين MTU وMSS؟
MTU هو أكبر حزمة تمر على وصلة دون تقطيع. وعلى معظم الوصلات يبلغ 1500 بايت. أما MSS فهو مقدار البيانات الفعلية التي يضعها اتصال TCP داخل الحزمة بعد خصم الترويسات.
تخيّل طرداً يجب أن يمر من باب عرضه 1500. النفق يضع هذا الطرد داخل صندوق إضافي، أي ترويسات WireGuard وUDP وIP الخارجية. لذلك يجب أن يكون الطرد الداخلي أصغر، وإلا لن يمر الصندوق من الباب.
يحجز WireGuard عادةً 80 بايت لتغطية أسوأ حالة، فتصبح قيمة MTU الشائعة داخل النفق 1420. ومن هذا الرقم نحسب قيمتين: أكبر حمولة ping هي 1392 بايت بعد خصم 28 بايت، وMSS هو 1380 بعد خصم 40 بايت لترويسات IPv4 وTCP.
لماذا تعلّق المواقع بدل أن تفشل؟
الحزم الصغيرة تمر دائماً. طلب DNS وping العادي وبداية الاتصال كلها صغيرة، لذلك يبدو النفق سليماً. وحين يبدأ الخادم بإرسال البيانات بالحجم الكامل، تصل حزمة أكبر من المسموح إلى نقطة ضيقة في الطريق.
في الحالة السليمة ترد النقطة الضيقة برسالة ICMP تقول: «الحزمة كبيرة، صغّرها». لكن بعض الجدران النارية تحجب هذه الرسائل، فتُرمى الحزمة الكبيرة ولا يعرف المرسل السبب. يعيد الإرسال بالحجم نفسه، فتُرمى مرة أخرى، ويبقى المتصفح منتظراً. تسمى هذه الحالة «الثقب الأسود».
لهذا تظهر الأعراض بنمط مميز:
- المواقع الثقيلة تتوقف بينما الصفحات الخفيفة تعمل.
- مصافحة HTTPS تعلّق عند بعض المواقع فقط.
- جلسة SSH تدخل، ثم تتجمد عند أمر يطبع نصاً طويلاً.
- رفع الملفات يتوقف، بينما تنزيل الملفات الصغيرة ينجح.
كيف تقيس الحجم الصحيح؟
لا تخمّن. أرسل حزمة بحجم محدد مع منع التقطيع، ثم زد الحجم حتى تصل إلى آخر قيمة ناجحة. المثال التالي افتراضي، والعنوان 10.0.0.1 هو طرف النفق الآخر:
# من لينكس
ping -M do -s 1392 -c 3 10.0.0.1
ping -M do -s 1393 -c 3 10.0.0.1
# من ويندوز
ping -f -l 1392 10.0.0.1مع mtu=1420 يجب أن تنجح 1392 وتفشل 1393. إن فشلت 1392، فهناك نقطة في الطريق أضيق مما يظنه النفق، وعليك النزول تدريجياً حتى تجد آخر حجم ناجح. عندها احسب: أكبر حمولة ناجحة + 28 = MTU الفعلي للنفق.
يعطيك الجدول التالي نقاط بدء محسوبة بحجز 80 بايت. هذه حسابات وليست قياسات، فتأكد منها بالأمر السابق على شبكتك.
| الطريق الخارجي | MTU الطريق | MTU النفق | أكبر حمولة ping | MSS |
|---|---|---|---|---|
| وصلة عادية | 1500 | 1420 | 1392 | 1380 |
| خط PPPoE | 1492 | 1412 | 1384 | 1372 |
| نفق داخل نفق بقيمة 1420 | 1420 | 1340 | 1312 | 1300 |
الإصلاح: اضبط MSS بدل مطاردة كل جهاز
بعد القياس اضبط قيمة النفق على الطرفين، ثم تأكد من ثبات الاتصال بفتح صفحة ثقيلة ورفع ملف. لكن هذا لا يكفي دائماً، لأنك لا تستطيع تغيير MTU على كل هاتف وحاسوب خلف النفق. الحل العملي هو تعديل قيمة MSS أثناء بدء اتصال TCP عند النقطة التي تمر منها الحركة، فيتفق الطرفان على حجم مناسب دون أي إعداد عندهما.
على خادم لينكس، مع افتراض أن واجهة النفق هي wg0:
iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu
iptables -t mangle -A FORWARD -i wg0 -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtuوعلى راوتر MikroTik، مع افتراض أن الواجهة اسمها wg-hq:
/ip/firewall/mangle/add chain=forward protocol=tcp tcp-flags=syn \
out-interface=wg-hq action=change-mss new-mss=clamp-to-pmtuافهم قبل أن تنشر. لا تنقل إعدادات VPN إلى شبكة حية دون فهمها. غيّر قيمة واحدة كل مرة، وسجّل القيمة السابقة، وجرّب من جهاز واحد أولاً. ولا ترفع إعدادات مثل rmem أو backlog ما لم يُظهر عدّاد مثل UdpRcvbufErrors مشكلة فعلية.
إذا بقي البطء بعد إصلاح الحجم، فابحث في مكان آخر. المسافة تكلّف عشرات الملّي ثانية، والعتاد الضعيف قد يكلّف آلافاً. زمن الشبكة في العراق يقع غالباً بين 70 و150ms، بينما يتراوح توليد الصفحة بين 150ms وأكثر من ثانيتين حسب العتاد. لذلك اسأل عن المعالج والتخزين، لا عن المدينة وحدها.
لمن تناسب هذه الخدمة؟
إن كنت تحتاج خادم نفق بعنوان ثابت، فخدمة سيرفر WireGuard هي نقطة البداية المباشرة. وإن كنت تريد إدارة الخادم بنفسك مع خدمات أخرى، فاطّلع على باقات VPS في العراق. هذا يناسب:
- مزوّدي الإنترنت الذين يديرون أبراجاً وراوترات عن بُعد.
- الشركات التي تربط فروعاً وموظفين بأنظمتها الداخلية.
- المطوّرين الذين يصلون إلى قواعد البيانات واللوحات الداخلية عبر نفق خاص.
أخطاء شائعة
- خفض MTU إلى رقم صغير دون قياس: تختفي المشكلة، لكنك تضيّع مساحة من كل حزمة.
- حجب كل رسائل ICMP: هذا يصنع الثقب الأسود. اسمح على الأقل برسائل «الحزمة كبيرة».
- الاختبار بأمر ping عادي: الحزمة الافتراضية صغيرة، ونجاحها لا يثبت شيئاً عن الحجم الكامل.
- نسيان الاتجاه الثاني: ضبط اتجاه واحد قد يصلح التنزيل ويترك الرفع معطلاً.
- إهمال الأنفاق المتداخلة: كل طبقة إضافية تقتطع من الحجم، فأعد الحساب.
أسئلة شائعة
هل يقلل خفض MTU السرعة؟
يقل قليلاً نصيب البيانات من كل حزمة، لكن هذا أفضل بكثير من حزم تضيع وتُعاد. القيمة الصحيحة المقاسة هي الهدف، لا أكبر قيمة ولا أصغرها.
هل يكفي ضبط MSS وحده؟
يكفي لحركة TCP. أما UDP فلا يستخدم MSS، لذلك يجب أن تكون قيمة MTU نفسها صحيحة أيضاً، خاصة للتطبيقات التي ترسل حزماً كبيرة.
لماذا تعمل بعض المواقع وتعلّق أخرى؟
لأن حجم الحزم يختلف من موقع إلى آخر، وبعض الخوادم يستجيب لرسائل تصغير الحجم بسرعة أكبر. والصفحات الخفيفة قد لا تصل أصلاً إلى الحجم الأقصى.
الخلاصة
إذا كان ping يعمل والصفحات الثقيلة تعلّق، فابدأ بالحجم قبل أن تتهم السرعة: قِس بحزمة تمنع التقطيع، ثم صحّح MTU، ثم اضبط MSS في الاتجاهين. ولتشخيص أوسع لانقطاعات النفق راجع دليل حين ينقطع النفق. وإن كنت تخطط لبناء نفق جديد، فراجع صفحة الخدمة أو تواصل مع فريق المبيعات لاختيار ما يناسب حملك.
