Ping ليس دليلاً: اختبر المسار بين موقعين

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

ابدأ من العميل الذي يحتاج الخدمة

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

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

امشِ المسار عند كل حافة

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

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

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

استخدم البروتوكول الذي يستخدمه التطبيق

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

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

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

أعد إنتاج الحالة التي تفشل

الفشل الذي يظهر فقط مع النقل الكبير مشكلة حجم، لا مشكلة اتصال. أرسل حزمة كبيرة مع بت don't-fragment مضبوطاً وراقب أين تتوقف. إذا نجح طلب صغير وتعلّق طلب كبير، فإن MTU النفق ومعالجة MSS عند البوابتين هما المشتبه بهما التاليان.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

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

بعد الإصلاح، أعد الاختبار نفسه

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

سجّل قيم الأساس الأربع والنتيجة. عندها يمكن أن يبدأ التقرير التالي عن العَرَض نفسه من دليل بدلاً من Ping.