الثقب الأسود في MTU: لماذا تنجح الطلبات الصغيرة ويتوقف الرفع

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

ما الذي يجعل الثقب أسود

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

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

ابحث عن الحجم الذي ينكسر عنده

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

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

تنجح حمولة من 1472 بايت على مسار Ethernet نظيف بسعة 1500 بايت بمجرد إضافة 28 بايت من ترويستَي IPv4 و ICMP. وعندما ينجح الاختبار نفسه عند حمولة أصغر فقط بعد تشغيل النفق، يكون الفرق هو عبء التغليف، وحدود النفق هي المكان الذي كان ينبغي أن تُولَّد فيه رسالة الرفض. سجّل الرقمين، قبل الاتصال وبعده، لأن هذا الزوج هو الدليل. أعد الاختبار لبروتوكول IPv6 عندما يستخدمه التطبيق، إذ إن الترويسة أكبر وعتبة الفشل تتحرك.

اقرأ الأدلة قبل أن تلوم النفق

أخطاء التطبيقات البعيدة والازدحام والفقد العادي تؤخر الرفع أيضًا، لذا لا يحدد نقل واحد فاشل ثقبًا أسود. ما يفصل بينها هو علاقة الحجم: نجاح متكرر عند 1200 بايت وتوقف متكرر عند 1400 بايت، في الاتجاه نفسه وعبر نقطة النهاية نفسها.

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

تحقق من الإصلاح على النقلين

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

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

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