آموزش ping، traceroute و mtr؛ عیب‌یابی مسیر شبکه تا سرور

چرا این سه ابزار را باید بلد باشید؟

وقتی سایت کند باز می‌شود، SSH مدام قطع می‌شود یا کاربران از یک شهر خاص شکایت دارند، اولین سؤال این است: مشکل از سرور است یا از مسیر شبکه؟ بدون اندازه‌گیری، هر پاسخی حدس است. ping، traceroute و mtr سه ابزار استاندارد برای همین اندازه‌گیری‌اند و روی همهٔ سیستم‌عامل‌ها در دسترس هستند. پشتیبانی هر ارائه‌دهندهٔ سرور هم معمولاً اولین چیزی که می‌خواهد خروجی mtr است.

در این آموزش یاد می‌گیرید هر ابزار را چطور اجرا کنید، خروجی‌اش را درست بخوانید و از اشتباه‌های رایج در تفسیر دوری کنید. اگر علت‌های پینگ بالا و راه‌حل‌هایش را می‌خواهید، مقالهٔ پینگ بالا و Packet Loss مکمل همین آموزش است.

ping: آیا سرور جواب می‌دهد؟

ping بستهٔ کوچکی از نوع ICMP Echo به مقصد می‌فرستد و منتظر پاسخ می‌ماند. سه چیز را از خروجی آن می‌فهمید: آیا مقصد در دسترس است، زمان رفت‌وبرگشت (RTT) چقدر است و چه سهمی از بسته‌ها گم شده است.

# لینوکس و مک: ۲۰ بسته بفرست و خلاصه را نشان بده
ping -c 20 203.0.113.10

# فقط IPv4 یا فقط IPv6
ping -4 -c 10 example.com
ping -6 -c 10 example.com

# ویندوز (پیش‌فرض ۴ بسته؛ -n تعداد را تعیین می‌کند)
ping -n 20 203.0.113.10

در انتهای خروجی، خطی مثل packet loss و خطی با مقادیر min/avg/max/mdev می‌بینید. مقدار mdev نشان‌دهندهٔ نوسان (Jitter) است؛ اگر میانگین قابل‌قبول باشد ولی mdev بزرگ باشد، تجربهٔ کاربر در بازی آنلاین، تماس صوتی یا SSH ناپایدار خواهد بود.

یک هشدار مهم: بسیاری از سرورها و فایروال‌ها ICMP را مسدود می‌کنند. «ping جواب نمی‌دهد» همیشه به معنی خاموش بودن سرور نیست. در این حالت پورت سرویس را مستقیم تست کنید:

nc -vz 203.0.113.10 22
curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://example.com

تست اندازهٔ بسته و مشکل MTU

گاهی ping معمولی سالم است، اما صفحه‌های بزرگ باز نمی‌شوند یا اتصال SSH پس از ورود قفل می‌کند. یکی از علت‌های شناخته‌شده، ناسازگاری MTU (حداکثر اندازهٔ بسته‌ای که مسیر عبور می‌دهد) است. با ping و پرچم «تکه‌تکه نکن» می‌توانید بزرگ‌ترین اندازهٔ قابل عبور را پیدا کنید:

ping -c 3 -M do -s 1472 203.0.113.10
ping -c 3 -M do -s 1400 203.0.113.10

اگر اندازهٔ بزرگ‌تر خطای message too long یا عدم پاسخ می‌دهد ولی اندازهٔ کوچک‌تر سالم است، احتمالاً جایی در مسیر MTU کمتری دارد و باید MTU رابط شبکه یا تنظیمات تونل را کاهش دهید.

traceroute: بسته‌ها از کجا عبور می‌کنند؟

traceroute با ارسال بسته‌هایی که TTL (عمر بسته) آن‌ها یکی‌یکی افزایش می‌یابد، هر روتر میان راه را وادار به پاسخ می‌کند. نتیجه فهرست هاپ‌ها (روترهای میانی) از شما تا مقصد است.

sudo apt install -y traceroute
traceroute 203.0.113.10
# اگر UDP مسدود است، با ICMP یا TCP روی پورت ۴۴۳ امتحان کنید
sudo traceroute -I 203.0.113.10
sudo traceroute -T -p 443 example.com

# ویندوز
tracert 203.0.113.10

هر خط یک هاپ است و سه زمان رفت‌وبرگشت برایش نمایش داده می‌شود. ستاره (* * *) یعنی آن روتر پاسخ نداده است؛ این لزوماً مشکل نیست، چون بسیاری از روترها به بسته‌های traceroute پاسخ نمی‌دهند یا اولویت پایینی برایشان قائل‌اند. اگر هاپ‌های بعدی و مقصد پاسخ می‌دهند، ستاره‌های میانی را نادیده بگیرید.

mtr: ترکیب ping و traceroute

mtr (مخفف My Traceroute) مسیر را مثل traceroute پیدا می‌کند و سپس به همهٔ هاپ‌ها پشت‌سرهم ping می‌فرستد. بنابراین برای هر هاپ آمار تجمعی دارید: درصد گم‌شدن، میانگین، بهترین و بدترین زمان و نوسان. به همین دلیل بهترین ابزار برای گزارش دادن مشکل شبکه است.

sudo apt install -y mtr-tiny
# حالت گزارش: ۱۰۰ بسته، بدون حل نام (سریع‌تر)، با شمارهٔ AS هر هاپ
mtr -rwzbc 100 203.0.113.10

# با TCP روی پورت وب، وقتی ICMP محدود است
sudo mtr -rwzbc 100 -T -P 443 example.com

در ویندوز می‌توانید از WinMTR استفاده کنید که همین اطلاعات را در یک جدول گرافیکی نشان می‌دهد.

$ mtr -rwzbc 100 203.0.113.10HOST: server        Loss%  Snt  Last  Avg  Best  Wrst StDev  1. AS???  10.0.0.1     0.0%  100   ...  ...   ...   ...   ...  2. AS64500 192.0.2.1   0.0%  100   ...  ...   ...   ...   ...  3. AS64501 198.51.100.9  ...   100   ...  ...   ...   ...   ...  4. AS64502 203.0.113.10  0.0%  100   ...  ...   ...   ...   ...$ 

خواندن درست خروجی mtr

رایج‌ترین اشتباه این است که فرد هاپی با loss بالا را در وسط مسیر می‌بیند و نتیجه می‌گیرد «مشکل از این روتر است». قواعد درست تفسیر این‌هاست:

1. فقط loss پایدار تا انتهای مسیر مهم است. اگر هاپ پنجم loss نشان دهد ولی هاپ‌های ششم تا آخر بدون loss باشند، آن روتر فقط پاسخ‌دادن به بسته‌های mtr را محدود کرده است (Rate Limit) و ترافیک واقعی را سالم عبور می‌دهد.
2. lossی که از یک هاپ شروع و تا مقصد ادامه پیدا می‌کند، واقعی است. محل شروع آن نشان می‌دهد مشکل در کدام بخش مسیر رخ می‌دهد.
3. افزایش ناگهانی زمان که تا آخر ادامه دارد معمولاً یعنی عبور از یک لینک طولانی (مثلاً خروج از کشور) یا شلوغی در آن نقطه. افزایشی که فقط در یک هاپ دیده می‌شود و بعد برطرف می‌شود اهمیتی ندارد.
4. مسیر رفت و برگشت می‌تواند متفاوت باشد. به همین دلیل باید mtr را از سمت سرور به سمت شما هم اجرا کنید.

ستون ASN (با گزینهٔ -z) نشان می‌دهد هر هاپ متعلق به کدام شبکه است. این اطلاعات کمک می‌کند بفهمید مشکل در شبکهٔ اینترنت خانگی شما، شبکهٔ بین‌المللی یا شبکهٔ دیتاسنتر است.

سناریوهای واقعی عیب‌یابی

SSH مدام قطع می‌شود: از کامپیوتر خود mtr -rwzbc 200 به سرور بگیرید. اگر loss از هاپ‌های اول (مودم یا شبکهٔ اپراتور) شروع می‌شود، مشکل نزدیک شماست. اگر مسیر سالم است، علت را در تنظیمات SSH جست‌وجو کنید؛ راهنمای خطای Connection timed out در SSH کمک می‌کند.

کاربران یک کشور یا اپراتور سایت را کند می‌بینند: از روی سرور به آی‌پی یکی از آن کاربران (یا یک مقصد شناخته‌شده در همان شبکه) mtr بگیرید. اگر مسیر طولانی یا پرنوسان است، استفاده از CDN یا انتخاب لوکیشن نزدیک‌تر به مخاطب معمولاً بیشتر از ارتقای سخت‌افزار اثر دارد.

ping خوب است ولی سایت کند است: مشکل احتمالاً شبکه نیست؛ CPU، رم، دیسک یا تنظیمات وب‌سرور را بررسی کنید. ابزارهای این بخش را در معرفی ابزارهای بنچمارک سرور ببینید.

ساختن گزارش مناسب برای پشتیبانی

وقتی به پشتیبانی ارائه‌دهندهٔ سرور یا اینترنت پیام می‌دهید، این موارد را بفرستید تا مشکل سریع‌تر بررسی شود:

• خروجی کامل mtr -rwzbc 100 از سمت شما به سرور (به‌صورت متن، نه عکس).
• در صورت امکان، خروجی mtr از سرور به آی‌پی عمومی شما. آی‌پی خودتان را با curl -4 ifconfig.me روی سیستم خود پیدا کنید.
• زمان دقیق وقوع مشکل و اینکه همیشگی است یا در ساعت‌های خاصی رخ می‌دهد.
• نوع اتصال شما (اینترنت ثابت یا همراه و نام اپراتور).

اگر کلودیفای ارائه‌دهندهٔ سرور شماست، این گزارش را از بخش پشتیبانی تیکت کنید؛ وضعیت کلی شبکه را هم می‌توانید پیش از آن در صفحهٔ وضعیت سرویس‌ها ببینید.

نکته‌هایی برای اندازه‌گیری منصفانه

• تعداد بسته را کم نگیرید؛ ده بسته برای نتیجه‌گیری کافی نیست. حداقل ۱۰۰ بسته بفرستید.
• در ساعت‌های مختلف روز تکرار کنید؛ شلوغی شبکه در ساعت‌های اوج متفاوت است.
• هم IPv4 و هم IPv6 را جداگانه بسنجید؛ مسیر این دو ممکن است کاملاً متفاوت باشد.
• برای مقایسهٔ لوکیشن‌های مختلف پیش از خرید سرور، می‌توانید یک سرور ساعتی در هر لوکیشن بسازید، چند ساعت تست کنید و بعد حذفش کنید؛ روش کار را در صفحهٔ سرور ساعتی ببینید.

سؤالات متداول