آموزش استفاده از Traceroute و MTR برای عیب‌یابی مشکلات شبکه

مقدمه
یادگیری نحوه استفاده از Traceroute و MTR برای عیب‌یابی مشکلات شبکه، یک گام عملی بسیار مهم است زمانی که شما نیاز دارید ببینید چه روترهایی بین ماشین شما و یک میزبان ریموت قرار دارند، آیا در یکی از مراحل (Hop) تاخیر (Latency) بالایی وجود دارد یا خیر، و آیا از دست رفتن بسته‌ها (Packet Loss) واقعی است یا صرفاً ناشی از نحوه پردازش کاوشگرها (Probes) است. ابزار Traceroute یک عکس فوری از مسیر رو به جلو ارائه می‌دهد. اما ابزار MTR کشف مسیر به سبک Traceroute را با ارسال مکرر کاوشگرها ترکیب می‌کند تا بتوانید آمار از دست رفتن بسته‌ها و زمان رفت و برگشت (RTT) را برای هر مرحله به دست آورید.

این آموزش نحوه کارکرد ردیابی مبتنی بر TTL، نحوه نصب و اجرای Traceroute و MTR در سیستم‌عامل‌های رایج، نحوه خواندن خروجی‌های توضیح‌دار، زمانی که مسیرها در هر جهت متفاوت هستند و یک گردش کار کوتاه برای عیب‌یابی را که می‌توانید قبل از پیوست کردن لاگ‌ها به تیکت پشتیبانی استفاده کنید، پوشش می‌دهد.

نکات کلیدی:

• Traceroute با ارسال بسته‌هایی با مقادیر TTL (Time to Live) فزاینده و ثبت پیام‌های “زمان به پایان رسیده” (Time Exceeded) از سمت هر روتر، مسیر رو به جلو را کشف می‌کند. MTR این ایده را تکرار می‌کند و آمار زنده‌ای (افت بسته، حداقل، میانگین، حداکثر و انحراف معیار) ارائه می‌دهد.
• ستاره‌ها (*) در خروجی Traceroute اغلب به این معنی است که یک روتر به درخواست پاسخ نداده است، نه لزوماً اینکه ترافیک کاربر دور ریخته شده است. همیشه نتایج را با MTR (تowards مرحله نهایی) و علائم سطح اپلیکیشن مقایسه کنید.
• مسیرها می‌توانند نامتقارن باشند: هنگامی که هر دو طرف قابل دسترسی هستند، MTR را از لپ‌تاپ خود به سمت سرور و از سرور به سمت IP عمومی شما (یا یک نقطه پایانی پایدار دیگر) اجرا کنید.
• راهنمای تقریبی RTT برای تفسیر: در یک شهر واحد معمولاً کمتر از ۵ میلی‌ثانیه برای هر مرحله است؛ بخش‌های بین‌شهری در یک کشور بزرگ اغلب ده‌ها میلی‌ثانیه طول می‌کشد؛ و بخش‌های فراقاره‌ای معمولاً حدود ۸۰ تا ۱۵۰ میلی‌ثانیه هستند. مقادیر پایدار بالای ۱۵۰ تا ۲۰۰ میلی‌ثانیه در یک مرحله نیاز به بررسی دقیق‌تر دارد.
• زمانی که ابزارهای مسیریابی کافی نیستند، با ابزارهایی مانند tcpdump یا Wireshark بسته‌ها را ضبط کنید، سوکت‌ها را با ss بررسی کنید و قوانین فایروال محلی را بازبینی کنید.

---

مرحله شبکه (Network Hop) چیست؟

یک “هاپ” (Hop) یا مرحله، یک روتر یا دستگاه لایه ۳ در طول مسیر است. بسته‌های شما بین یک شبکه خانگی یا اداری تا یک سرور ابری (مانند سرورهای پارمین کلود) از طریق چندین هاپ عبور می‌کنند.

کامپیوتر شما -- هاپ ۱ (روتر لبه) -- هاپ ۲ (ISP) -- هاپ ۳ (ستون فقرات شبکه) -- ... -- مقصد

هر روتر در مسیر، مقدار TTL بسته IP را یک واحد کاهش می‌دهد. وقتی TTL به صفر برسد، دستگاه مقرر است یک پیام ICMP “Time Exceeded” برگرداند، که این دقیقاً همان چیزی است که همان چیزی است که Traceroute کلاسیک برای کشف آن روتر از آن استفاده می‌کند.

(پوزش: عبارت چینی بالا به اشتباه در متن جایگزین شد. منظور این بود که: “این همان چیزی است که Traceroute کلاسیک برای کشف آن روتر از آن استفاده می‌کند.”)

---

Traceroute چه کاری انجام می‌دهد و چگونه کار می‌کند؟

Traceroute به این سوال پاسخ می‌دهد: “بسته‌های من در مسیر رسیدن به این مقصد از کدام روترها عبور کردند و زمان رفت و برگشت برای هر کدام چقدر بود؟”
در بسیاری از سیستم‌های لینوکس، Traceroute پیش‌فرض کاوشگرهای UDP را به پورت‌های بالا ارسال کرده و به پاسخ‌های ICMP گوش می‌دهد. در macOS، Traceroute سیستم نیز به طور پیش‌فرض از UDP استفاده می‌کند.

کاوش مبتنی بر TTL
فرستنده با یک TTL کوچک شروع می‌کند. اولین روتر بسته را دور می‌ریزد، پیام “Time Exceeded” را برمی‌گرداند و هویت خود را فاش می‌کند. فرستنده TTL را گام به گام افزایش می‌دهد تا زمانی که بسته به مقصد برسد (یا به حد مجاز هاپ برسد).

محدودیت‌های Traceroute

• فایروال‌ها و محدودیت‌های نرخ: ممکن است اپراتورها ICMP یا پورت‌های UDP عجیب را فیلتر کنند یا نرخ آن‌ها را محدود کنند، که این امر باعث تولید * در خروجی می‌شود، حتی زمانی که HTTP یا SSH به خوبی کار می‌کنند.
• مسیریابی نامتقارن: مسیرهای بازگشت برای پیام‌های ICMP ممکن است با مسیری که ترافیک اپلیکیشن شما طی می‌کند متفاوت باشد.
• متعادل‌کننده‌های بار (Load Balancers) و Anycast: اگر مقصد از نوع Anycast یا دارای Load Balancer باشد، ممکن است در اجراهای مختلف، هاپ‌های متفاوتی را ببینید.

---

نصب Traceroute و MTR

اوبونتو و دبیان
بیشتر ایمیج‌های اوبونتو (مانند نسخه ۲۴.۰۴) شامل Traceroute هستند. اگر وجود ندارد:

sudo apt update
sudo apt install traceroute

برای نصب MTR (شامل رابط خط فرمان و رابط کاربری متنی):

sudo apt install mtr

Rocky Linux, CentOS Stream, Fedora و خانواده RHEL

sudo dnf install traceroute mtr

macOS
Traceroute از قبل نصب است. MTR را با Homebrew نصب کنید:

brew install mtr

ویندوز
ابزار tracert به صورت پیش‌فرض نصب است. Command Prompt یا PowerShell را باز کنید:

tracert example.com

---

اجرای Traceroute و خواندن خروجی

سینتکس پایه:

traceroute example.com

خروجی نمونه (با توضیحات):

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  gateway.lan (192.0.2.1)    2.1 ms   2.0 ms   2.2 ms   # روتر لبه شما
 2  isp-core.example.net       10.4 ms  10.1 ms  10.3 ms  # شبکه اپراتور
 3  * * *                                                # عدم پاسخ در این دور
 4  core.backbone.example     18.2 ms  17.9 ms  18.0 ms  # همچنان در حال پیشروی
 ...

خواندن ستون‌ها:

1. شماره هاپ: فاصله به صورت مراحل از هاست شما.
2. نام هاست یا IP: از طریق دی‌ان‌اس معکوس به دست می‌آید.
3. سه زمان رفت و برگشت: به طور پیش‌فرض سه کاوشگر ارسال می‌شود.

معنی ستاره‌ها (*):
ستاره به این معنی است که آن کاوشگر قبل از پایان مهلت زمانی پاسخ قابل استفاده‌ای دریافت نکرده است. این اغلب نشان‌دهنده یک روتر واسط است که به درخواست‌های Traceroute پاسخ نمی‌دهد، محدودیت نرخ ICMP اعمال می‌کند یا توسط فایروال مسدود شده است. اگر هاپ‌های بعدی همچنان نمایش داده می‌شوند، احتمالاً ترافیک کاربر همچنان کار می‌کند.

---

ابزار MTR چه کاری انجام می‌دهد و چه تفاوتی با Traceroute دارد؟

MTR کاوشگرهای مکرر ارسال کرده و آمار را برای هر هاپ به‌روزرسانی می‌کند. این ویژگی باعث می‌شود MTR برای تشخیص از دست رفتن بسته‌های متناوب و Jitter (نوسان تاخیر) بسیار بهتر از یک Traceroute تک‌مرحله‌ای باشد.

قابلیت	Traceroute	MTR
عکس فوری از مسیر	بله	حالت گزارش اختیاری
به‌روزرسانی پیوسته	خیر	بله (پیش‌فرض TUI)
درصد افت بسته در هر هاپ	خیر	بله
انحراف معیار تاخیر	خیر	بله

اجرای MTR و تفسیر گزارش

حالت تعاملی:

mtr example.com

برای خروج از حالت تعاملی معمولاً کلید q را فشار دهید.

گزارش غیرتعاملی (ارسال ۱۰ دور به طور پیش‌فرض):

mtr --report example.com

برای افزایش دقت نمونه‌گیری:

mtr --report --report-cycles 50 example.com

مثال گزارش MTR:

HOST: myserver                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gateway.lan               0.0%    50    0.4   0.5   0.3   1.1   0.2
  2.|-- isp-pe.example.net       0.0%    50    9.2  10.1   8.4  15.2   1.8
  3.|-- core1.backbone.example   0.0%    50   18.0  18.4  17.1  22.0   1.1
  4.|-- core2.backbone.example   0.0%    50   88.5  90.2  85.1 120.4  10.3
  5.|-- target.example.com        0.0%    50   91.0  92.0  89.0 125.0  11.0

در این الگو، تاخیر در هاپ ۴ به شدت افزایش یافته و تا مقصد بالا مانده است، که نشان‌دهنده وجود مشکل در این بخش از مسیر است.

از دست رفتن بسته در هاپ‌های میانی در مقابل مقصد نهایی
اگر یک هاپ میانی افت بسته نشان دهد اما هاپ نهایی حدود ۰٪ افت نشان دهد و سرویس به درستی کار کند، ممکن است آن روتر ترافیک کاوشگر را کم‌اولویت کرده باشد. اما اگر هاپ نهایی افت بسته پایداری نشان دهد که با خطاهای اپلیکیشن مطابقت دارد، آن را به عنوان از دست رفتن بسته انتها به انتها (End-to-End) در نظر بگیرید.

---

تشخیص مشکلات رایج

تاخیر بالا در یک هاپ
پرش ناگهانی در یک هاپ نشان‌دهنده ازدحام، یک بخش جغرافیایی طولانی یا یک نقطه Peering مشکوک است.

الگوهای از دست رفتن بسته (Packet Loss)

• از دست رفتن بسته End-to-End در آخرین هاپ که با خرابی‌های قابل مشاهده کاربر مطابقت دارد، معمولاً نیاز به ارتقا با گزارش‌های MTR و زمان‌سنجی دارد.
• افت بسته فقط در هاپ‌های میانی با وجود سلامت هاپ نهایی، اغلب نیاز به تفسیر دارد، نه یک تغییر اضطراری در مسیریابی.

---

تست دوطرفه (Bidirectional Testing)

مسیرها از A به B و از B به A می‌توانند متفاوت باشند. وقتی شما به شل (Shell) در هر دو انتها دسترسی دارید (مثلاً لپ‌تاپ شما و یک سرور پارمین کلود):
۱. mtr --report <target> را از کلاینت به سمت IP عمومی سرور اجرا کنید.
۲. از روی سرور، mtr --report را به سمت IP عمومی کلاینت اجرا کنید.

هر دو گزارش را کنار هم مقایسه کنید و توجه کنید که تاخیر یا افت بسته در کجا متفاوت است.

---

گردش کار عملی عیب‌یابی (Triage Workflow)

از این توالی زمانی استفاده کنید که کاربران گزارش می‌دهند “سرور کند است” یا “اتصال SSH قطع می‌شود”:
۱. تایید DNS و دسترسی لایه ۴: نام را resolve کنید و به پورت سرویس ping بزنید یا متصل شوید.
۲. عکس فوری Traceroute: traceroute -n <host> برای یک نقشه سریع.
۳. گزارش MTR: mtr --report --report-cycles 50 <host>
۴. جهت‌دار بودن: از میزبان ریموت به سمت کلاینت یا یک نقطه پایانی عمومی پایدار، تست را تکرار کنید.
۵. سیاست محلی: بررسی کنید که UFW یا فایروال‌های ابری ترافیک مورد نیاز را مسدود نکرده باشند.
۶. بسته ارتقا: گزارش‌های MTR را با زمان‌سنجی، IP مبدا و مقصد و اینکه آیا مشکل با یک ISP یا VPN خاص همبستگی دارد یا خیر، پیوست کنید.

---

زمانی که Traceroute و MTR کافی نیستند

• ضبط بسته (Packet Capture): از tcpdump روی یک اینترفیس یا Wireshark روی لپ‌تاپ استفاده کنید.
• وضعیت سوکت: از ss -tunap برای دیدن آنچه در حال شنود و اتصال است استفاده کنید.
• کوبرنیتیز: برای بارهای کاری روی کوبرنیتیز پارمین کلود، مسیریابی سرویس‌ها و رفتار CNI را بررسی کنید.

---

سوالات متداول (FAQ)

۱. چگونه از traceroute برای شناسایی مشکلات شبکه استفاده کنم؟
دستور traceroute <destination> را اجرا کنید و به دنبال اولین هاپی بگردید که تاخیر آن نسبت به هاپ‌های قبلی به شدت پرش می‌کند، یا جایی که ستاره‌ها تجمع کرده‌اند و اپلیکیشن شما نیز با شکست مواجه می‌شود. آن را با mtr --report ترکیب کنید تا فریب یک عکس فوری شانس‌مند را نخورید.

۲. آیا MTR با traceroute یکسان است؟
خیر. Traceroute در هر بار اجرا، هاپ‌ها را یک بار کشف می‌کند. اما MTR به طور مکرر کاوش می‌کند و آمار افت بسته و زمان رفت و برگشت را برای هر هاپ خلاصه می‌کند که برای مشکلات متناوب بسیار مناسب‌تر است.

۳. ستاره‌ها در خروجی traceroute چه معنایی دارند؟
به این معنی که آن کاوشگر قبل از اتمام مهلت زمانی پاسخی دریافت نکرده است. دلایل رایج شامل فیلتر کردن ICMP، محدودیت‌های نرخ، یا روتری است که ترافیک traceroute را اولویت‌بندی نمی‌کند. اگر ردیابی از ستاره‌ها عبور کند و MTR یک هاپ نهایی سالم نشان دهد، احتمالاً مسیر برای ترافیک واقعی اپلیکیشن همچنان سالم است.

---

نتیجه‌گیری
شما می‌توانید برای عیب‌یابی مشکلات شبکه از Traceroute و MTR استفاده کنید تا هاپ‌ها را نقشه‌برداری کنید، زمان‌های رفت و برگشت را مقایسه کرده و افت بسته را در هاپ نهایی در مقابل هاپ‌های میانی بررسی کنید. هنگامی که احتمال نامتقارن بودن مسیر وجود دارد، تست‌های دوطرفه را اضافه کنید، و اگر مسیریابی سالم به نظر می‌رسد اما اپلیکیشن‌ها همچنان با شکست مواجه می‌شوند، به سراغ ضبط بسته و بررسی سوکت‌ها بروید.