اكتشاف Path MTU والثقوب السوداء: حل مشكلات تعطل VPN وضبط TCP MSS

تعد ظاهرة «التجمد الصامت» (Silent Freeze) واحدة من أكثر المشكلات إرباكاً في هندسة شبكات بروتوكول الإنترنت. في هذه الحالة، تكتمل المصافحة الثلاثية الأولية لبروتوكول TCP بنجاح، وتتبادل الأجهزة حزم التحكم الصغيرة (٤٠ إلى ٦٠ بايت) دون أي عائق، ولكن بمجرد أن يبدأ تدفق البيانات الحقيقية الضخمة—مثل تحميل صفحات الويب الغنية، أو تبادل شهادات تشفير TLS 1.3 ServerHello، أو مصادقة مفاتيح OpenSSH—يتوقف الاتصال تماماً بشكل مفاجئ. لا تظهر رسائل خطأ واضحة مثل TCP RST، بل يظل الاتصال معلقاً حتى انتهاء مهلة إعادة الإرسال (TCP Retransmission Timeout).

في بيئات الشبكات الافتراضية الخاصة وهياكل الأنفاق المشفرة للطبقة الثالثة، تشير هذه الأعراض بصورة شبه حتمية إلى فشل آلية اكتشاف وحدة النقل الكبرى للمسار (Path Maximum Transmission Unit Discovery - PMTUD) المعرفة في معيار RFC 1191 ونشوء ما يعرف باسم الثقب الأسود لبروتوكول ICMP (ICMP Black Hole).

تفرض شبكات الإيثرنت القياسية (IEEE 802.3) سقفاً لوحدة النقل الكبرى Maximum Transmission Unit (MTU) يبلغ ١٥٠٠ بايت. ومع ذلك، عندما تقوم أنفاق التشفير بتغليف الحزم داخل أظرف بروتوكول UDP مع مصادقة ChaCha20-Poly1305، تستهلك الترويسات الإضافية (Encapsulation Overhead) ما بين ٦٠ إلى ٨٠ بايت من سعة الإطار. إذا عجزت الموجهات الوسيطة في مسار النقل عن التنسيق الصحيح لأحجام الحزم، يتم إسقاط الحزم كبيرة الحجم بصمت تام، مما يسبب اختناقاً شديداً في أداء الشبكة.

[مسار شبكة الإيثرنت القياسية]
حمولة البيانات + ترويسة TCP (20B) + ترويسة IP (20B) = 1500 بايت (إطار فيزيائي كامل)

────────────────────────────────────────────────────────────────────────────────────────

[مسار النفق المشفر عبر شبكة VPN]
[IP خارجي (20B)] [UDP خارجي (8B)] [ترويسة WireGuard (16B)] [وسم Poly1305 (16B)] [الحزمة الداخلية]
                                  إجمالي عبء التغليف الإضافي = 60 إلى 80 بايت!
الحد الأقصى المسموح لوحدة MTU الداخلية = 1500 - 60 = 1440 بايت (أو 1420 بايت عبر شبكات الجوال/PPPoE)

الآلية البرمجية لاكتشاف Path MTU (معيار RFC 1191)

تحدد وحدة النقل الكبرى (MTU) الحجم الأقصى للحزمة الواحدة بالبايت التي يمكن للواجهة الشبكية نقلها دون الحاجة إلى التجزئة (Fragmentation).

نظراً لأن مسار نقل حزم IP عبر الإنترنت يعبر شبكات متعددة وغير متجانسة—بدءاً من خطوط الألياف الضوئية عالية السرعة (MTU من ١٥٠٠ إلى ٩٠٠٠ بايت Jumbo Frames) وحتى اتصالات DSL PPPoE (MTU ١٤٩٢ بايت) وشبكات الهاتف المحمول 4G LTE/5G (MTU ١٤٠٠ إلى ١٤٢٠ بايت)—فإن القيمة الأصغر لوحدة MTU بين جميع القفزات الوسيطة تسمى وحدة MTU للمسار (Path MTU - PMTU).

في بروتوكول IPv4 التقليدي (RFC 791)، كان يُسمح للموجهات الوسيطة بتجزئة الحزم الأكبر من سعة الرابط (IP Fragmentation). ولكن تجزئة الحزم تفرض عبئاً حسابياً هائلاً، وترفع معدل فقدان البيانات (حيث يؤدي فقدان قطعة واحدة إلى تلف الحزمة بالكامل)، فضلاً عن التهديدات الأمنية المرتبطة بإعادة تجميع الحزم الخبيثة.

لإنهاء التجزئة الضارة، اعتمدت منظومة IETF معيار RFC 1191 لآلية Path MTU Discovery: ١. تفعيل علامة منع التجزئة (DF Flag): يضبط الجهاز المرسل بت Don’t Fragment (DF = 1) في ترويسة IPv4 لجميع الحزم الصادرة. ٢. التحقق عند القفزات الوسيطة: عند وصول حزمة بحجم ١٥٠٠ بايت إلى موجه مقيد بمنفذ يبلغ سقف نقله ١٤٢٠ بايت، تمنع علامة DF = 1 الموجه من تجزئة الحزمة. ٣. إرسال إشعار تحكم ICMP: يقوم الموجه بإسقاط الحزمة ويرسل إشعار ICMP Destination Unreachable إلى المصدر: Type 3, Code 4 (Fragmentation Needed and DF set)، متضمناً القيمة الدقيقة لوحدة MTU للقفزة التالية (Next-Hop MTU). ٤. تعديل حجم الإرسال: يستقبل الجهاز المصدر الإشعار ويخفض قيمة PMTU إلى ١٤٢٠ بايت ويعيد إرسال البيانات ضمن الحدود الجديدة.

أما في بروتوكول IPv6 (RFC 8201)، فإن التجزئة بواسطة الموجهات الوسيطة محظورة بالكامل؛ وتعد آلية PMTUD إلزامية عبر رسائل التحكم ICMPv6 Packet Too Big (Type 2, Code 0).

تشريح الثقب الأسود لبروتوكول ICMP (ICMP Black Hole)

تعتمد كفاءة معيار RFC 1191 بالكامل على موثوقية وصول رسائل ICMP التحذيرية. ولكن في شبكة الإنترنت العامة، تتعطل هذه الآلية باستمرار.

تقوم العديد من جدران الحماية للشركات، والموجهات المنزلية، ومعدات مزودي الخدمة بإسقاط كافة حزم ICMP الواردة بصورة عشوائية، اعتقاداً منها بأنها تشكل تهديداً أمنياً أو ناقلاً لهجمات حجب الخدمة (DoS).

[العميل المرسل]                                [الموجه الوسيط / نقطة الاختناق]                [الخادم الوجهة]
      │                                                      │                                           │
      ├─ 1. TCP SYN (MSS=1460, DF=1) ───────────────────────>│──────────────────────────────────────────>│ (اكتمال المصافحة)
      │<─ 2. TCP SYN-ACK (MSS=1460) <────────────────────────│<──────────────────────────────────────────┤
      │                                                      │                                           │
      ├─ 3. إرسال حزمة TLS ClientHello ضخمة (1500B) ────────>│ [سقف رابط MTU: 1420 بايت]                 │
      │                                                      │ (إسقاط الحزمة: تجاوزت سعة الرابط!)         │
      │                                                      │                                           │
      │   (جدار الحماية يحظر رسالة ICMP Type 3 Code 4!)      ├─ توليد إشعار ICMP Fragmentation ────────X │
      │                                                      │                                           │
      │   العميل لا يتلقى أي إشعار نهائياً!                  │                                           │
      ▼                                                      │                                           │
[تجمد الاتصال: محاولات إعادة إرسال متكررة حتى انتهاء المهلة] │                                           │

عندما يُسقط الموجه الحزمة ويرسل إشعار ICMP Type 3 Code 4، لكن جدار الحماية في مسار العودة يحظر هذا الإشعار:

• لا يعلم الجهاز المرسل أبداً أن حزمته قد أُسقطت بسبب حجمها.
• يفترض المرسل أن الحزمة فُقدت بسبب ازدحام عابر، فيعيد إرسال نفس الحزمة بحجم ١٥٠٠ بايت مع DF = 1.
• يقوم الموجه بإسقاطها مرة أخرى.
• يدخل الاتصال في حالة تجمد تام: تمر حزم تأكيد الاستلام الصغيرة TCP ACK (٤٠ إلى ٦٠ بايت) بسلاسة، بينما تختفي تدفقات البيانات الضخمة داخل ثقب ICMP الأسود.

حساب أعباء الترويسات في أنفاق WireGuard وRiceGuard

عند بناء شبكات VPN تعتمد توجيهاً آمناً على الطبقة الثالثة، يعد الحساب الدقيق لسقف MTU أمراً حاسماً لاستقرار الاتصال. تُغلف كل حزمة داخل إطار UDP مشفر بتقنية ChaCha20-Poly1305.

يوضح الجدول التالي العبء البايتي الإضافي لبروتوكول WireGuard:

على واجهة شبكية فيزيائية قياسية بوحدة MTU تبلغ ١٥٠٠ بايت:

• يمكن لواجهة نفق WireGuard المعتمدة على IPv4 (wg0) استيعاب سقف أقصى قدره 1500 - 60 = 1440 بايت.
• يمكن لواجهة النفق المعتمدة على IPv6 استيعاب سقف قدره 1500 - 80 = 1420 بايت.

في البيئات الواقعية، تفرض خطوط الإنترنت قيوداً إضافية: تستخدم اتصالات PPPoE المنزلية ٨ بايت إضافية للتغليف (MTU ١٤٩٢ بايت)، بينما تستخدم شبكات الهاتف المحمول 4G/5G بروتوكول نفق GPRS (GTP)، مما يقلص سقف MTU الأساسي إلى ١٤٠٠ أو ١٤٢٠ بايت.

لضمان الاستقرار الشامل وتفادي اختناقات المسار، تضبط بوابات Anycast التابعة لخدمة VPNRice سقف وحدة MTU الافتراضية للواجهات الافتراضية بحذر عند ١٤٢٠ بايت (أو ١٢٨٠ بايت، وهو الحد الأدنى الإلزامي المعتمد في معيار IPv6 RFC 8200).

تقنية تثبيت TCP MSS Clamping: التدبير الوقائي الحاسم

بينما تنتظر آلية PMTUD وقوع الخطأ وتوليد إشعار ICMP، يقدم بروتوكول التحكم في النقل (TCP) تدبيراً وقائياً يمنع تشكل الحزم الزائدة من البداية: تثبيت الحجم الأقصى للقطعة (TCP Maximum Segment Size Clamping).

خلال المصافحة الأولية، يتبادل الطرفان سعة الاستقبال القصوى عبر حقل خيارات TCP في حزم SYN وSYN-ACK. يمثل خيار MSS الحجم الصافي الأقصى للبيانات التي يستطيع الجهاز استقبالها في شريحة TCP واحدة، دون احتساب ترويسات IP وTCP:

$$\text{MSS} = \text{MTU الواجهة} - \text{ترويسة IP (20/40B)} - \text{ترويسة TCP (20B)}$$

• في شبكة إيثرنت قياسية سعة ١٥٠٠ بايت: $\text{MSS} = 1500 - 20 - 20 = 1460\text{ بايت}$.
• في نفق WireGuard بسقف ١٤٢٠ بايت: $\text{MSS} = 1420 - 20 - 20 = 1380\text{ بايت}$ (أو ١٣٦٠ بايت لبروتوكول IPv6).

إذا حاول جهاز عميل متصل عبر النفق التفاوض مع خادم خارجي بقيمة MSS الافتراضية للشبكة المحلية (١٤٦٠ بايت)، سيرسل الخادم حزماً بحجم ١٥٠٠ بايت تفوق قدرة النفق.

ولحل هذا التعارض، تفحص بوابة الشبكة حزم SYN المارة عبر جدول التوجيه وتقوم تلقائياً بتعديل قيمة MSS:

# قاعدة جدار حماية iptables في لينكس لتثبيت قيمة TCP MSS وفق Path MTU
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# تعيين قيمة MSS ثابتة لضمان أقصى درجات الاستقرار عبر شبكات الجوال
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

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

آلية استكشاف MTU على طبقة التجزئة (PLPMTUD - معيار RFC 4821)

بالنسبة لحزم البيانات غير المعتمدة على بروتوكول TCP—مثل تدفقات UDP المستخدمة في بروتوكول HTTP/3 (QUIC)، واستعلامات DNS، والبث المباشر—لا يمكن الاعتماد على تثبيت MSS لغياب خيارات التفاوض على حجم الشريحة.

ولحل هذه المشكلة لحزم UDP، وضعت هيئة IETF معيار RFC 4821 تحت مسمى Packetization Layer Path MTU Discovery (PLPMTUD).

بدلاً من الاعتماد على إشعارات ICMP الواردة من الموجهات، تنقل هذه التقنية عملية الاستكشاف بالكامل إلى أطراف التطبيق المرسل والمستقبل. يرسل التطبيق حزم فحص استكشافية بأحجام متفاوتة. إذا تلقى التطبيق تأكيد استلام، يُثبت أن المسار يدعم ذلك الحجم؛ وإذا فُقدت الحزمة دون تأكيد، يخفض النظام سقف PMTU المقدر تدريجياً وبشكل تلقائي دون انتظار إشارات ICMP. تطبق البروتوكولات الحديثة مثل QUIC (RFC 9000 القسم ١٤) هذه الآلية بصفة مدمجة لضمان أداء مستقر عبر الشبكات المقيدة.

الانعكاسات الأمنية: التصدي لهجمات التجزئة وبصمات الأجهزة

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

١. إحباط هجمات التجزئة والتداخل (Tiny Fragment & Overlapping Attacks): اعتاد المهاجمون تجزئة حزم TCP الخبيثة (كما هو موضح في RFC 1858 وRFC 3128) بحيث تحتوي القطعة الأولى على ترويسة IP وجزء فقط من المنفذ، بينما تُدفع رايات التحكم إلى القطعة الثانية للتحايل على جدران الحماية غير المزودة بحالة اتصال. تطبيق سقف MTU صارم ورفض الحزم المجزأة غير الموثوقة يحصن الشبكة ضد هذا الاستغلال. ٢. منع تحديد بصمة نظام التشغيل عبر MSS: تحلل أنظمة التتبع السلبي القيمة الابتدائية لحقل MSS في حزم SYN للتعرف على نوع نظام تشغيل العميل وطبيعة واجهة الشبكة المستخدمة. ٣. الحد من ظاهرة تضخم الذاكرة الوسيطة (Bufferbloat): يؤدي تجزئة الحزم في الموجهات الوسيطة إلى مضاعفة طوابير الانتظار في محولات الشبكة، مما يرفع زمن الاستجابة ويولد تذبذباً ملحوظاً (Jitter).

كيف تعزز منصة VPNRice وبروتوكول RiceGuard استقرار الاتصال

تعتمد بنية VPNRice التحتية على حلول هندسية متكاملة ضمن بروتوكول RiceGuard تضمن انسيابية الاتصال ومنع التجمد:

• تثبيت ديناميكي لـ TCP MSS على أطراف الشبكة: تضبط خوادم Anycast التابعة لـ VPNRice قيم MSS تلقائياً في جداول التوجيه بما يتطابق مع المسار المشفر، مما يضمن عدم إصدار أي حزم تفوق سعة القنوات.
• اعتماد سقف MTU افتراضي مرن (١٤٢٠ بايت): تمت تهيئة الواجهات لتفادي التجزئة عبر شبكات الجوال المتغيرة والخطوط المزودة بتقنية PPPoE.
• سياسة رفض الحزم المجزأة غير الموثقة: يتم إسقاط الحزم المجزأة المشبوهة مع تدقيق سلامة البيانات بواسطة خوارزمية التشفير ChaCha20-Poly1305، مما يضمن كفاءة النقل وحماية المستخدمين من المخاطر الأمنية القديمة المرتبطة بتجزئة IP.