MTU لـ IPv6 واكتشاف MTU للمسار: تجنب مشاكل التجزئة
تعرف على كيفية عمل اكتشاف MTU للمسار في IPv6، ولماذا لا يمكن لأجهزة التوجيه تجزئة الحزم، وكيفية استكشاف مشاكل الاتصال المتعلقة بـ MTU وإصلاحها.
تجزئة الحزم هي إحدى المشاكل التي لا تلاحظها حتى تُعطل كل شيء.
TL;DR - ملخص سريع
النقاط الرئيسية:
- موجهات IPv6 لا يمكنها التجزئة: يجب على المضيفات المصدرية التعامل مع كل التجزئة عبر Path MTU Discovery
- لا تحظر أبداً ICMPv6 النوع 2: رسائل Packet Too Big ضرورية لكي يعمل PMTUD
- الحد الأدنى لـ MTU هو 1280 بايت: يجب أن تدعم جميع وصلات IPv6 هذا، استخدمه كقيمة احتياطية
- الأنفاق تقلل MTU: احسب حمل التغليف (6in4: 20 بايت، VPN: 40-80 بايت)
- استخدم تثبيت MSS: أجبر TCP على استخدام مقاطع أصغر عندما يفشل PMTUD
انتقل إلى: الثقوب السوداء لـ PMTUD | تشخيص مشاكل MTU | تكوين جدار الحماية
لماذا يُهم MTU أكثر في IPv6#
أزال IPv6 تجزئة الموجه بالكامل. في IPv4، إذا تلقى الموجه حزمة كبيرة جدًا للوصلة التالية، يمكنه تجزئتها. لا يمكن لموجهات IPv6 فعل ذلك — فهي تُسقط الحزمة وترسل رسالة ICMPv6 «حزمة كبيرة جدًا» إلى المصدر.
المضيف المصدر مسؤول عن كل التجزئة. يُحسّن قرار التصميم هذا أداء الموجه ويُبسط البروتوكول، ولكنه ينقل العبء إلى نقاط النهاية ويجعل اكتشاف MTU للمسار (PMTUD) حاسمًا.
إذا فشل PMTUD، تتعلق اتصالاتك بشكل غامض. تكتمل مصافحات TCP، لكن نقل البيانات يتوقف. تنتهي مهلة طلبات HTTP. تتجمد جلسات SSH بعد المصادقة. هذه أعراض كلاسيكية للثقوب السوداء لـ MTU.
الحد الأدنى لـ MTU في IPv6#
يجب أن تدعم جميع وصلات IPv6 ما لا يقل عن 1280 بايت. هذا هو الحد الأدنى لـ MTU، وهو غير قابل للتفاوض. إذا لم تتمكن وصلتك من التعامل مع حزم بحجم 1280 بايت، فهي غير متوافقة مع IPv6.
تستخدم معظم الشبكات 1500 بايت (MTU قياسي لـ Ethernet)، مما يوفر مساحة لرأس IPv6 بحجم 40 بايت بالإضافة إلى 1460 بايت من الحمولة. هذا يعادل MSS النموذجي لـ TCP في IPv4 وهو 1460.
تُقلل الأنفاق وبروتوكولات التغليف من MTU المتاح. إذا كنت تُشغل IPv6-في-IPv4 (6in4) أو 6to4 أو ISATAP، فستفقد بايتات للرأس الخارجي. تستهلك VPN وIPsec وGRE وVXLAN جميعها مساحة MTU.
قيم MTU الشائعة التي ستواجهها:
- 1500: Ethernet قياسي
- 1480: PPPoE (يفقد 8 بايتات لحمل PPP)
- 1460: نفق 6in4 (يفقد 20 بايت لرأس IPv4)
- 1420: 6in4 عبر PPPoE
- 1280: الحد الأدنى لـ MTU في IPv6، القيمة الاحتياطية
- 9000: إطارات جامبو (شبكات مراكز البيانات)
كيف يعمل اكتشاف MTU للمسار#
يُحدد PMTUD أكبر حجم حزمة يمكن أن يعبر المسار بين المصدر والوجهة دون تجزئة.
العملية مباشرة:
- يرسل المضيف حزمًا بـ MTU الحالي
- إذا كان لدى موجه على طول المسار MTU أصغر، فإنه يُسقط الحزمة
- يُرسل الموجه رسالة ICMPv6 من النوع 2 «حزمة كبيرة جدًا» إلى المصدر
- تتضمن الرسالة MTU للوصلة التالية
- يُقلل المضيف MTU للمسار ويُعيد الإرسال
- تتكرر العملية حتى تعبر الحزم المسار بأكمله
تحتوي رسالة «حزمة كبيرة جدًا» (ICMPv6 النوع 2، الرمز 0) على قيمة MTU في حمولة الرسالة. هذا يُخبر المصدر بالضبط ما مدى كبر الحزم التي يمكن أن تكون، وليس فقط أنها كبيرة جدًا.
إليك كيف تبدو رسالة ICMPv6:
ICMPv6 Packet Too Big:
Type: 2
Code: 0
MTU: 1280
[Original packet headers up to minimum MTU]يحتفظ المضيف بذاكرة تخزين مؤقت لـ MTU للمسار مع إدخالات تنتهي عادةً بعد 10 دقائق (توصية RFC 8201). إذا تغيرت مسارات الشبكة، يمكن أن تسبب إدخالات ذاكرة التخزين المؤقت القديمة مشاكل حتى تنتهي.
الثقوب السوداء لـ PMTUD#
ينكسر النظام عندما يتم حظر رسائل ICMPv6 من النوع 2. هذا يُنشئ «ثقوبًا سوداء لـ PMTUD» حيث تختفي الحزم بصمت.
الأسباب الشائعة:
جدران الحماية المفرطة في الحماس: يحظر المسؤولون أحيانًا جميع حركة مرور ICMP، معاملينها كخطر أمني. هذا خطأ. ICMPv6 جزء لا يتجزأ من تشغيل IPv6، وليس بروتوكول تشخيص اختياري مثل ping.
مشاكل الفحص ذي الحالة: لا تربط بعض جدران الحماية رسائل خطأ ICMPv6 بشكل صحيح بالاتصالات الموجودة، وتُسقطها كحركة مرور غير مرغوب فيها.
تحديد المعدل: قد تُحدد أجهزة الأمان معدل ICMPv6، وتُسقط رسائل PMTUD المشروعة خلال الفترات المزدحمة.
بوابات NAT64: يمكن أن تفقد الترجمة بين IPv6 و IPv4 معلومات PMTUD إذا لم تترجم البوابة رسائل ICMP بشكل صحيح.
أعراض الثقوب السوداء لـ PMTUD:
- يتم إنشاء اتصال TCP (SYN، SYN-ACK، ACK مكتمل)
- تعمل الحزم الصغيرة (استعلامات DNS، شعار تسجيل دخول SSH)
- تفشل الحزم الكبيرة (نقل الملفات، HTTP POST مع نص، جلسة SSH التفاعلية بعد المصادقة)
- لا توجد رسائل خطأ، فقط انتهاء المهلة
- تظهر المشكلة بشكل متقطع (يعتمد على حجم الحزمة)
تشخيص مشاكل MTU#
ابدأ بـ ping. أرسل حزمًا بأحجام محددة لاختبار MTU للمسار:
# اختبار مع 1280 بايت (الحد الأدنى لـ MTU)
ping6 -M do -s 1232 2001:db8::1
# اختبار مع 1500 بايت (Ethernet قياسي)
ping6 -M do -s 1452 2001:db8::1
# اختبار مع حمولة 1280 بايت
ping6 -c 5 -s 1280 2001:db8::1العلَم -M do يمنع التجزئة (عدم التجزئة). يُحدد الوسيط -s حجم الحمولة — أضف 8 بايتات لرأس ICMPv6 و 40 لرأس IPv6 للحصول على حجم الحزمة الإجمالي.
إذا فشلت 1452 بايت ولكن نجحت 1232، فإن MTU للمسار بين 1280 و 1500. ابحث بشكل ثنائي للعثور على القيمة الدقيقة:
# جرب 1400
ping6 -M do -s 1352 2001:db8::1
# جرب 1450
ping6 -M do -s 1402 2001:db8::1استخدم traceroute لتحديد مكان تغيير MTU:
traceroute6 -n 2001:db8::1ثم اختبر MTU لكل وصلة على حدة. الوصلة التي تبدأ فيها الحزم الكبيرة في الفشل هي نقطة مشكلتك.
بالنسبة لاتصالات TCP، راقب السلوك الفعلي:
# التقاط الحزم
tcpdump -i eth0 -n 'ip6 and (icmp6 or tcp)'ابحث عن:
- إعادة إرسال TCP بعد المصافحة الأولية
- رسائل ICMPv6 من النوع 2 (يجب أن تظهر إذا كان PMTUD يعمل)
- غياب ICMPv6 من النوع 2 (يشير إلى الحظر أو الثقب الأسود)
يمكن للأدوات الحديثة أتمتة هذا. يجمع MTR بين traceroute واختبار حجم الحزمة:
# اختبار مع حزم بحجم 1400 بايت
mtr -6 -s 1400 2001:db8::1تثبيت MSS لـ TCP#
MSS (الحد الأقصى لحجم المقطع) هو خيار TCP الذي يُخبر الطرف الآخر بمقدار البيانات التي يمكنه إرسالها في كل مقطع. MSS = MTU - رأس IP - رأس TCP.
بالنسبة لـ IPv6: MSS = MTU - 40 (IPv6) - 20 (TCP) = MTU - 60
مع MTU قياسي 1500 بايت: MSS = 1440
يُجبر تثبيت MSS اتصالات TCP على استخدام قيمة MSS أقل، والعمل حول مشاكل MTU دون الاعتماد على PMTUD. هذا شائع على الموجهات التي تنهي الأنفاق أو اتصالات PPPoE.
تكوين تثبيت MSS على Linux:
# تثبيت MSS إلى 1280 لـ IPv6
ip6tables -t mangle -A FORWARD \
-p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --set-mss 1220القيمة 1220 تأخذ في الاعتبار MTU 1280 ناقص 60 بايت للرؤوس.
بالنسبة لـ PPPoE مع MTU 1492:
ip6tables -t mangle -A FORWARD \
-p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --set-mss 1432يؤثر تثبيت MSS فقط على TCP. لا تزال UDP و SCTP والبروتوكولات الأخرى تعتمد على PMTUD أو تجزئة على مستوى التطبيق.
تكوين جدار الحماية#
يجب أن يسمح جدار الحماية برسائل ICMPv6 من النوع 2 لكي يعمل PMTUD. هذا غير قابل للتفاوض لشبكات IPv6 في الإنتاج.
أنواع ICMPv6 المطلوبة الحد الأدنى لتشغيل IPv6:
- النوع 1: الوجهة غير قابلة للوصول
- النوع 2: حزمة كبيرة جدًا (PMTUD)
- النوع 3: انتهت المدة
- النوع 4: مشكلة في المعلمة
- النوع 133-137: بروتوكول اكتشاف الجيران
قاعدة iptables لـ PMTUD:
# السماح بـ ICMPv6 حزمة كبيرة جدًا
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
ip6tables -A OUTPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type 2 -j ACCEPTنهج أفضل — السماح بجميع ICMPv6 الضرورية:
# السماح بـ ICMPv6 المُنشأة
ip6tables -A INPUT -p ipv6-icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
# السماح بأنواع ICMPv6 الضرورية
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 1 -j ACCEPT # Destination Unreachable
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT # Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 3 -j ACCEPT # Time Exceeded
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 4 -j ACCEPT # Parameter Problem
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 128 -j ACCEPT # Echo Request
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 129 -j ACCEPT # Echo Reply
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 133 -j ACCEPT # Router Solicitation
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 134 -j ACCEPT # Router Advertisement
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 135 -j ACCEPT # Neighbor Solicitation
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 136 -j ACCEPT # Neighbor Advertisementتحديد المعدل مقبول ولكن حدد حدودًا سخية:
# السماح بـ ICMPv6 مع تحديد المعدل
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 \
-m limit --limit 10/sec --limit-burst 20 -j ACCEPTلا تحظر ICMPv6 تمامًا أبدًا. إنه ليس خطرًا أمنيًا — إنه متطلب بروتوكول.
اعتبارات MTU للنفق#
تُقلل الأنفاق من MTU الفعال بحمل رؤوس التغليف.
أنواع الأنفاق الشائعة والحمل:
| نوع النفق | الحمل | MTU الفعال (من 1500) |
|---|---|---|
| 6in4 | 20 بايت | 1480 |
| 6to4 | 20 بايت | 1480 |
| 6rd | 20 بايت | 1480 |
| ISATAP | 20 بايت | 1480 |
| GRE | 24 بايت | 1476 |
| IPsec | 50-70 بايت | 1430-1450 |
| WireGuard | 60 بايت | 1420 |
| OpenVPN | 40-80 بايت | 1420-1460 |
تكوين MTU للنفق بشكل صريح لتجنب المشاكل:
# نفق 6in4
ip tunnel add tun6in4 mode sit remote 203.0.113.1 local 198.51.100.1
ip link set tun6in4 mtu 1480
ip link set tun6in4 upبالنسبة لـ WireGuard:
[Interface]
MTU = 1420تدعم بعض بروتوكولات الأنفاق اكتشاف MTU، ولكن التكوين الصريح أكثر موثوقية.
الإطارات الجامبو ومراكز البيانات#
غالبًا ما تستخدم شبكات مراكز البيانات MTU بحجم 9000 بايت (إطارات جامبو) لتحسين الإنتاجية لعمليات النقل الضخمة.
تمكين الإطارات الجامبو على الواجهات:
ip link set eth0 mtu 9000تأكد من أن جميع المفاتيح والموجهات في المسار تدعم الإطارات الجامبو. سيصبح جهاز واحد بـ MTU 1500 بايت عنق زجاجة.
لا يزال PMTUD ينطبق. إذا غادرت الحزمة شبكة الإطارات الجامبو الخاصة بك نحو الإنترنت، فيجب أن تنخفض إلى 1500 أو أقل.
الاختبار والتحقق#
تحقق من تكوين MTU لمضيفك:
ip -6 link showابحث عن قيمة MTU على كل واجهة.
تحقق من ذاكرة التخزين المؤقت الحالية لـ MTU للمسار:
ip -6 route get 2001:db8::1يُظهر الإخراج MTU المخزن مؤقتًا لتلك الوجهة.
اختبار الاتصال من طرف إلى طرف مع أحجام حزم متفاوتة:
for size in 1232 1352 1402 1452; do
echo "Testing $size bytes:"
ping6 -M do -s $size -c 3 2001:db8::1
doneاستخدم netcat لاختبار تفاوض MSS لـ TCP:
# الخادم
nc -6 -l 8080
# العميل
nc -6 2001:db8::1 8080التقط الحزم باستخدام tcpdump وتحقق من قيم MSS في حزم SYN.
السيناريوهات الشائعة والإصلاحات#
المشكلة: تُحمّل صفحات الويب ببطء، تفشل الصور السبب: ثقب أسود لـ PMTUD بسبب حظر جدار الحماية لـ ICMPv6 النوع 2 الإصلاح: تكوين جدار الحماية للسماح بـ ICMPv6 النوع 2
المشكلة: يتصل SSH ولكنه يتجمد بعد تسجيل الدخول السبب: MTU كبير جدًا، PMTUD لا يعمل الإصلاح: تقليل MTU على واجهة العميل أو تمكين تثبيت MSS على الموجه
المشكلة: يعمل VPN لعمليات النقل الصغيرة، يفشل للملفات الكبيرة السبب: لم يتم تكوين MTU للنفق بشكل صحيح الإصلاح: تقليل MTU للنفق لمراعاة حمل التغليف
المشكلة: يعمل IPv6 على الشبكة المحلية، يفشل عبر الإنترنت السبب: الموجه الأولي لديه MTU أصغر، لا يعلن عنه بشكل صحيح الإصلاح: اتصل بـ ISP أو قلل MTU المحلي إلى 1280 (الحد الأدنى)
المشكلة: بعض الوجهات تعمل، والبعض الآخر يفشل السبب: مشاكل MTU خاصة بالمسار الإصلاح: اختبر باستخدام ping لتحديد MTU العامل، وقم بتكوين الواجهة وفقًا لذلك
أفضل الممارسات#
- اسمح دائمًا بـ ICMPv6 النوع 2 في جدران الحماية
- قم بتكوين MTU للنفق بشكل صريح بدلاً من الاعتماد على الكشف التلقائي
- اختبر مع الحد الأدنى لـ MTU (1280) لضمان الاتصال الأساسي
- استخدم تثبيت MSS على نقاط نهاية النفق واتصالات PPPoE
- راقب فشل PMTUD باستخدام التقاط الحزم أثناء استكشاف الأخطاء وإصلاحها
- وثق MTU لشبكتك في كل طبقة (مادية، نفق، تطبيق)
- حدد قيم MTU متحفظة عند الشك (1280 يعمل دائمًا)
مقالات ذات صلة#
- شرح ICMPv6 — فهم بروتوكول التحكم في IPv6
- تكوين جدار حماية IPv6 — تأمين IPv6 دون كسر الوظيفة
- استكشاف أخطاء IPv6 وإصلاحها — تصحيح مشاكل اتصال IPv6 الشائعة