استجابة ping تعمل لكن الموقع يتجمد: تحقق من الحجم

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

ابدأ من أصغر سؤال إلى أكبره، ودوّن ما أثبته كل خطوة فعليًا.

رد الصدى يجيب عن سؤال أصغر بكثير

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

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

اكتشف ما إذا كان الاتصال قد بدأ

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

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

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

قِس الحجم برقم معلن

عندما يظهر التعطل تحت الحِمل، اختبر حجم حزمة واحد مع تعيين بت عدم التجزئة واذكر الحساب حتى تعني النتيجة شيئًا. على Linux مع iputils، ينتج حِمل قدره 1392 بايتًا بالإضافة إلى ترويسة ICMP ذات 8 بايتات وترويسة IPv4 ذات 20 بايتًا حزمة داخلية من 1420 بايتًا بالضبط. اذكر هذا الحساب في التذكرة، لأن ping مجردًا يصل إلى البوابة لا يثبت شيئًا عن تطبيق.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

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

احتسب المسار الخارجي

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

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

غيّر رقمًا واحدًا وأعد اختبار التطبيق

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

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

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