IP & Network

Мережевий traceroute

Простежує мережевий шлях до будь-якого хоста, хоп за хопом.

Про цей інструмент

Traceroute показує реальний маршрут, яким ваші пакети йдуть інтернетом — кожен роутер, кожен хоп, кожну зміну латентності по шляху. Якщо ping відповідає на «чи хост працює», то traceroute відповідає на «який вигляд має шлях і де він уповільнюється».

Наш інструмент запускає traceroute -n -q 1 -m 30 з нашого сервера у Франкфурті, відправляючи один пробний пакет на хоп із таймаутом 2 секунди. У міру того, як кожен роутер відповідає, рядок з'являється у вашому браузері — ви бачите трасу, що будується хоп за хопом. Ми додаємо reverse DNS, країну (з прапором), місто та ASN/власника для кожної публічної IP, тож видно, кому належить кожен фрагмент шляху.

Що можна робити з цим

  • Знайти, де живе латентність. Чиста траса з низькими RTT, яка раптом стрибає на 80 мс на хопі 12, вказує на конкретний транзит. ASN цього хопа скаже, чия це мережа.
  • Підтвердити, що шлях іде через очікувану географію. Трафік із Франкфурта до «європейського» хоста, який обходить через Нью-Йорк, — це значимий сигнал; може бути неправильна маршрутизація, може бути нормальний CDN edge, але це варто побачити.
  • Порівняти два хости поруч. Запустіть traceroute до A і до B; якщо обидва «помирають» на тому самому хопі, проблема між нами і цим проміжним роутером, а не на призначеннях.

Як читати результат

Хопи з * означають, що відповіді не було протягом 2 секунд — це або роутер, який не надсилає ICMP TTL-exceeded (дуже поширено), або реальна втрата пакета. Постійні * на останніх хопах при тому, що раніше все працює, зазвичай означають, що firewall на призначенні мовчки відкидає traceroute-пробінги — сам хост у порядку, просто прихований. Колонка reverse DNS натякає на топологію оператора: імена на кшталт be-1234.cr1-fra.de.example.net мають структуру (інтерфейс, роль, локація, ASN-суфікс).

Часті запитання

Чому деякі хопи весь час «*»?

* означає, що ми не отримали відповіді для цього TTL протягом 2 секунд. Найчастіша причина — роутер просто не генерує ICMP TTL-exceeded; багато операторів обмежують або відключають це на магістральних роутерах. Траса продовжується далі нормально, тож кілька зірочок посередині — не проблема. Довгий «хвіст» зірочок у кінці зазвичай означає, що firewall призначення відкидає пробінги; сам хост ще може бути доступним через TCP.

Чому мій traceroute відрізняється від вашого?

Наші пробінги виходять із Франкфурта, ваші — з вашої машини. Різні провайдери, різні upstream-пірінги, різна географія. Траса — це знімок шляху між двома конкретними точками в конкретний час. Порівнювати обидві версії — і є сенс: якщо наш шлях чистий, а ваш ні, регресія upstream від вас, а не на призначенні.

Чи дозволені приватні/loopback IP як цілі?

Ні. Приватні діапазони RFC 1918, loopback, link-local (169.254/16), CGN (100.64/10) та cloud-metadata endpoints відхиляються — та сама SSRF-політика, що й у решті наших інструментів. Використовуйте traceroute на власній машині для огляду LAN; публічний сервіс має пробінгувати лише публічний інтернет.

Чому лише один RTT на хоп, а не три?

Класичний traceroute відправляє по три пробінги на TTL і друкує три round-trip. Ми використовуємо один на хоп (-q 1), щоб найгірший випадок (30 недосяжних хопів × 2 с) лишився в межах 60-секундного бюджету — пробінги дешеві, а перезапуск завжди можливий, якщо хочете точнішого вимірювання. Для глибшого аналізу jitter на конкретному хопі краще підходить Ping: він шле 5–30 echo з підсумком min/avg/max/mdev.