تقديم traceroute باستخدام MTR

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

أنتج تقرير تشخيص شبكة لتذكرة دعم. ينطبق على أي مشكلة اتصال بينك وبين خادم WebGee.

يجمع MTR بين traceroute وping: فهو يرسم المسار إلى وجهة ثم يواصل اختبار كل قفزة، فيُظهر الفقد والكمون المستمرين لا لقطة واحدة. وذلك ما يجعله مفيدًا — فـ traceroute المجرّد لا يستطيع التمييز بين ومضة عابرة وعطل مستمر.

ثبّته

# دبيان / أوبونتو
sudo apt install mtr

# RHEL / AlmaLinux / Rocky
sudo dnf install mtr

# macOS
brew install mtr

وعلى ويندوز، استخدم WinMTR.

شغّله

mtr --report --report-cycles 100 example.com

وهذا يشغّل 100 دورة — نحو دقيقة ونصف — ويطبع تقريرًا نصيًا. والدورات الأقل تنتج ضجيجًا يسهل إساءة قراءته.

استبدل example.com باسم مضيف خادمك أو عنوانه.

شغّله في الاتجاهين

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

شغّل MTR من جهازك إلى الخادم، ومن الخادم إلى عنوانك أنت. وأرسل الاثنين.

ومن الخادم، اعثر على عنوانك أولًا:

curl -s https://ifconfig.me

ثم شغّل MTR من الخادم نحوه.

أرسله نصًا

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

وضمّن:

التقريرين كليهما، كلًا منهما موسومًا باتجاهه
عنوان IP العام لديك
متى بدأت المشكلة، وهل هي ثابتة أم متقطّعة

قراءته بنفسك

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