Що таке MTR і як перевірити мережевий маршрут
Автор: Редакція Domeny.ForSale Опубліковано
Коротко: MTR, тобто My Traceroute, — це інструмент діагностики мережі, який поєднує перевірку маршруту пакетів із повторними вимірюваннями затримок і втрати відповідей. У системі Linux він допомагає з’ясувати, чи проблема зі з’єднанням виникає вже в локальній мережі, чи далі на шляху до сервера. Найважливіше правило тлумачення результатів: відсутність відповіді від окремого маршрутизатора ще не означає, що він втрачає пакети, які пересилає до цілі.
Як працює MTR і чим відрізняється від ping
ping перевіряє, чи відповідає вказаний хост, і вимірює час до отримання відповіді. traceroute показує послідовність вузлів на шляху до цілі. MTR поєднує ці функції: визначає маршрут і багаторазово надсилає зондувальні пакети, оновлюючи результати для кожного вузла.
Вузол, який також називають переходом або hop, — це зазвичай маршрутизатор, що пересилає пакети далі. MTR виявляє такі пристрої, поступово збільшуючи TTL — ліміт переходів пакета. Коли ліміт вичерпується, маршрутизатор може надіслати повідомлення, за яким можна визначити його адресу.
Вимірювання показує час проходження зондувального пакета та відповіді на нього, а не лише затримку між двома сусідніми маршрутизаторами. Зворотний шлях може відрізнятися від шляху до цілі, тому звіт не завжди дає змогу однозначно визначити місце збою.
Встановлення та перший тест у системі Linux
У системах Debian і Ubuntu текстову версію інструмента зазвичай можна встановити командами:
sudo apt update
sudo apt install mtr-tiny
В інших дистрибутивах назва пакета може відрізнятися; часто це mtr. Уточніть її в документації дистрибутива або через пошук пакетів у менеджері, яким користуєтеся.
Щоб запустити інтерактивний тест, укажіть IP-адресу або ім’я хоста:
mtr 1.1.1.1
Результати оновлюватимуться, доки ви не завершите тест, наприклад клавішею q. Адреса 1.1.1.1 тут слугує для перевірки з’єднання з публічно доступною ціллю; діагностуючи конкретний сервіс, насамперед перевіряйте його хост.
Для збереження та передавання результатів зручніше створити звіт із заданою кількістю циклів:
mtr -r -w -c 100 -n 1.1.1.1
Параметр -r вмикає звіт, -w розширює його формат, -c 100 задає 100 циклів вимірювання, а -n вимикає перетворення IP-адрес на імена хостів. Якщо програма повідомляє про відсутність дозволів на надсилання зондувальних пакетів, перевірте налаштування пакета; залежно від способу встановлення може знадобитися запуск через sudo.
Як читати стовпці звіту
Кожен рядок описує виявлений вузол. Найкорисніші стовпці:
| Стовпець | Значення |
|---|---|
Loss% | Частка зондувальних пакетів, на які не отримано відповіді |
Snt | Кількість надісланих зондувальних пакетів |
Last | Час отримання останньої відповіді |
Avg | Середній час відповіді |
Best / Wrst | Найкоротший і найдовший час відповіді |
StDev | Міра мінливості часу відповіді |
Час зазвичай подається в мілісекундах. Високе значення Wrst за низького середнього може означати одиничний стрибок затримки. Велике значення StDev вказує на нестабільність вимірювань, але саме по собі не пояснює її причину.
Не оцінюйте з’єднання за кількома зондувальними пакетами. Виконайте, наприклад, 100 циклів, коли проблема проявляється, а потім порівняйте результати з вимірюванням, зробленим тоді, коли сервіс працює належно.
Коли втрата відповідей означає проблему
Маршрутизатори можуть обмежувати діагностичні відповіді або надавати їм нижчий пріоритет, ніж пересиланню трафіку. Тому Loss% для проміжного вузла не можна автоматично вважати показником втрати пакетів користувача.
Приклад: четвертий вузол показує 70% втрати відповідей, але всі наступні, включно з цільовим, мають 0%. Такий результат зазвичай свідчить про обмеження відповідей четвертим маршрутизатором, а не про втрату трафіку, який він пересилає. Адже пакети доходять до наступних пристроїв.
Більше занепокоєння викликає втрата відповідей, яка починається з певного місця і спостерігається також на наступних вузлах та на цільовому хості. Це підстава для подальшої діагностики, а не доказ вини конкретного маршрутизатора: на результат можуть впливати різні маршрути, фільтрація та спосіб обробки зондувальних пакетів.
Так само тлумачте затримки. Якщо один маршрутизатор відповідає повільно, а наступні — швидко, його високий показник не доводить уповільнення всього з’єднання. Відсутність відповіді, позначена символами ???, також не обов’язково означає, що маршрут перервано.
Що перевірити, якщо проблема стосується вебсайту
За замовчуванням MTR використовує для зондування ICMP — протокол, який застосовують, зокрема, для діагностичних повідомлень. Мережа може обробляти ці пакети інакше, ніж трафік вебсайту. У разі проблем із HTTPS іноді допомагає тест TCP на порту 443:
mtr -r -w -c 100 -n --tcp -P 443 example.com
Замініть pryklad.com на хост сервісу, який перевіряєте. Такий тест усе одно не вимірює завантаження сторінки, узгодження параметрів TLS чи роботу застосунку. Отже, звіт MTR без ознак проблем не виключає неполадок із DNS, вебсервером або базою даних.
Якщо хост має адреси IPv4 та IPv6, можна порівняти тести з параметрами -4 і -6. Звертаючись до адміністратора, додайте звіт, час вимірювання із зазначенням часового поясу, перевірену ціль та опис прояву проблеми. Перед публікацією видаліть адреси або назви, що розкривають приватну інфраструктуру.
Дивіться також: Що таке ping?
Читайте також
