الحزم الكبيرة تختفي عبر IPsec بينما تظل بينغات صغيرة تعمل

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

مكانان يمكن أن تُقسَّم فيهما الحزمة

قبل التشفير، يمكن للموجّه أن يقسّم حزمة داخلية متضخمة ويحمي كل جزء على حدة. بعد التشفير، الحزمة الخارجية المكتملة هي ما يُقسَّم، وعلى الطرف البعيد إعادة تجميعها قبل أن يتمكن من فك تشفير أي شيء. العَرَض نفسه، لكن عمل مختلف على المستقبِل ومقابض مختلفة لك.

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

أين يُتخذ قرار الحجم فعليًا

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

افحص قيمة الواجهة أولًا، ثم السلوك الخارجي. رقمان، ومرحلتان، وواحدة منهما فقط هي المسؤولة عادة.

الميزانية الخارجية ليست الميزانية الداخلية

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

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

IPv6 يزيل أحد الخيارين

موجّهات IPv6 لا تجزّئ في أثناء العبور، لذا إما أن تناسب الحزمة الخارجية أو تختفي مع رسالة Packet Too Big. تصبح تلك الرسالة قناة التغذية الراجعة الوحيدة، وحجبها يكسر اكتشاف المسار لكل نقل كبير يتبع. قد تجزّئ موجّهات IPv4 حزمة كبيرة عندما يكون البت واضحًا، وهذا يخفي العطل حتى يضبط شيء آخر ذلك البت.

على حزمة بروتوكولات مختلطة، قد يتصرف النفق نفسه بشكل مختلف مع العائلتين، ولهذا لا يحسم اختبار واحد عبر IPv4 شكوى تخص IPv6. الفحص الذي يمارس عائلة واحدة يترك نصف الجواب دون قياس.

سياسة مقاطع TCP ليست جوابًا عامًا

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

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

الترتيب الذي تعمل به

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

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