فشل DNS أم مشكلة MTU؟ أين يتوقف الطلب فعليًا

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

فشلان في طبقتين مختلفتين

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

تختلف الأعراض بطريقة يمكن ملاحظتها دون أي أدوات. فشل DNS فوري وثابت: يقول المتصفح إنه لا يمكن العثور على الخادم. وفشل MTU جزئي: تبدأ الصفحة، وتصل بعض الموارد، ثم يتعطل رد كبير أو عملية رفع.

إذا كانت الأعراض جزئية، فتوقف عن النظر إلى DNS.

المرحلة 1: هل يُحلّ الاسم أصلًا

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

اسأل المحلل الذي سيستخدمه نظام التشغيل، ثم قارن:

dig +short vpn.example.com
dig +short vpn.example.com @10.0.0.53

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

المرحلة 2: أين يتوقف النقل

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

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

توقف واحد قابل للتكرار أثمن من عشرة توقفات متفرقة.

لماذا لا يضر MTU إلا بعد المصافحة

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

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

قِس الحجم صراحة بدلًا من استنتاجه:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

غيّر طبقة واحدة ثم أثبت ذلك

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

الصفحة التي تُحمّل مرة واحدة بعد تغيير عدة إعدادات لا تحدد الإصلاح. غيّر شيئًا واحدًا، وأعد الاختبار نفسه، واحفظ النتيجة بجانب أول مرحلة فاشلة سجلتها.

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