Як використовувати команду 'traceroute' в Linux
Що потрібно знати
- Єдиний параметр, який ви повинні включити в команду traceroute, - це ім'я хоста або IP-адреса місця призначення.
- Почніть тестування з TTL, рівним одиниці, і збільшуйте на один, поки не отримаєте ICMP «порт недоступний» або не досягнете максимального значення спроб.
Ця стаття охоплює інформацію traceroute, застосовну до машин Linux, і включає пояснення перемикача команд, а також інформацію про те, як інтерпретувати результати. Traceroute є використовується по-різному в Windows.
Як працює Traceroute
Команда traceroute відображає шлях, який проходить пакет інформації від свого джерела до місця призначення. Одним із способів використання traceroute є визначення місця втрати даних у всій мережі, що може означати, що вузол не працює.
Оскільки кожен стрибок у записі відображає новий сервер або маршрутизатор між початковим ПК та передбачуваним target, перегляд результатів сканування трасування визначає повільні точки, які можуть негативно вплинути на вашу мережу трафіку.
Усунення несправностей за допомогою Traceroute
Оцінка конкретного маршруту, за яким рухається мережевий трафік (або виявлення несанкціонованого шлюзу, який відкидає ваші пакети) представляє кілька проблем з усунення несправностей. Traceroute використовує протокол IP час жити поле, щоб отримати відповідь ICMP TIME_EXCEEDED від кожного шлюзу на шляху до хоста призначення.
Єдиний параметр, який ви повинні включити під час виконання команди traceroute, — це ім’я хоста або IP-адреса місця призначення.
Синтаксис і перемикачі Traceroute
Traceroute дотримується такого загального синтаксису:
traceroute [ -dFInrvx ] [ -f first_ttl ] [ -g шлюз ] [ -i iface ] [ -m max_ttl ] [ -p порт ] [ -q nqueries ] [ -s src_addr ] [ -t tos ] [ -w час очікування ] [ -z pausemssecs ] хост [ packetlen ]
Ви можете змінити продуктивність або вихід команди, вказавши один або кілька додаткових перемикачів.
Командні перемикачі Traceroute | |
---|---|
Перемикач | Пояснення |
-f | Встановіть початковий час життя, що використовується в першому вихідному пакеті проби. |
-Ф | Встановіть біт «не фрагментувати». |
-d | Увімкнути налагодження на рівні сокета. |
-г | Вкажіть вільний вихідний маршрутний шлюз (максимум 8). |
-я | Вкажіть мережевий інтерфейс, щоб отримати вихідну IP-адресу для вихідних пакетів проби. Зазвичай це корисно лише на багатодомному хості. (Див -s прапорець для іншого способу зробити це.) |
-Я | Використовуйте ICMP ECHO замість UDP дейтаграми. |
-м | Встановіть максимальний час життя (максимальна кількість стрибків), що використовується у вихідних пакетах проби. За замовчуванням — 30 стрибків (таке саме, що використовується для TCP-з'єднань). |
-n | Друкувати адреси переходів у числовому вигляді, а не в символічному чи числовому вигляді (зберігає пошук адреси до імені сервера імен для кожного шлюзу, знайденого на шляху). |
-стр | Встановіть базовий номер порту UDP, який використовується в пробниках (за замовчуванням — 33434). Traceroute сподівається, що нічого не прослуховує порти UDP бази до база + nhops - 1 на хості призначення (тому буде повернуто повідомлення ICMP PORT_UNREACHABLE, щоб завершити трасування маршруту). Якщо щось прослуховує порт у діапазоні за замовчуванням, цю опцію можна використовувати, щоб вибрати невикористаний діапазон портів. |
-r | Обійти звичайні таблиці маршрутизації та відправити безпосередньо на хост у підключеній мережі. Якщо хост не знаходиться в безпосередньо підключеній мережі, повертається помилка. Цей параметр можна використовувати для ping локального хоста через інтерфейс, який не має маршруту через нього (наприклад, після того, як інтерфейс був відкинутий маршрутизується(8C)). |
-s | Використовуйте наступну IP-адресу (яку зазвичай вказують як IP-номер, а не ім’я хоста) як адресу джерела у вихідних пробних пакетах. На хостах з кількома домівками (з більш ніж однією IP-адресою) цей параметр можна використовувати, щоб змусити вихідну адресу бути чимось іншим, ніж IP-адреса інтерфейсу, на який надсилається пакет проби. Якщо IP-адреса не є однією з адрес інтерфейсу цього пристрою, повертається помилка і нічого не надсилається. (Див -я прапорець для іншого способу зробити це.) |
-т | Встановіть тип послуги у пакетах зондування до наступного значення (за замовчуванням нуль). Значення має бути цілим десятковим числом у діапазоні від 0 до 255. Цей параметр можна використовувати, щоб побачити, чи призводять різні типи послуг до різних шляхів. (Якщо ви не використовуєте 4.4bsd, це може бути академічним, оскільки звичайні мережеві служби, такі як telnet і ftp не дозволяйте вам контролювати TOS.) Не всі значення TOS є законними або значущими — див. специфікацію IP для визначення. Корисними значеннями, ймовірно, є `-т16' (низька затримка) і `-т8' (висока пропускна здатність). |
-v | Детальний вихід. Перелічено отримані пакети ICMP, відмінні від TIME_EXCEEDED та UNREACHABLE. |
-w | Встановіть час (у секундах) очікування відповіді на зонд (за замовчуванням 5 секунд). |
-x | Переключити IP контрольні суми. Зазвичай це заважає traceroute обчислювати контрольні суми IP. У деяких випадках операційна система може перезаписувати частини вихідного пакета, але не перераховувати контрольну суму; таким чином, у деяких випадках за замовчуванням не обчислюються контрольні суми та не використовують -x змушує їх розраховувати. Зверніть увагу, що контрольні суми зазвичай потрібні для останнього стрибка під час використання зондів ICMP ECHO (-Я), тому вони завжди обчислюються при використанні ICMP. |
-z | Встановіть час (у мілісекундах) для паузи між датчиками (за замовчуванням 0). Деякі системи, такі як Solaris і маршрутизатори від Cisco, обмежують швидкість повідомлень icmp. Хорошим значенням для цього є 500 (наприклад, 1/2 секунди). |
Інтерпретація результатів
Traceroute окреслює шлях, за яким IP-пакет йде до Інтернет-хосту, запускаючи пакети UDP-проби з невеликим TTL, а потім прослуховуючи ICMP-відповідь «перевищення часу» від шлюзу. Почніть тестування з TTL, рівним одиниці, і збільшуйте на один, поки не отримаєте ICMP «порт недоступний» (що означає, що пакет прибув до місця призначення) або досягнуто максимального значення спроб, яке за замовчуванням становить 30 переходів і може бути змінено з -м прапор.
Коли виконується traceroute, він надсилає три проби для кожного параметра TTL, а потім друкує рядок на консоль, що показує TTL, адресу шлюзу та час передачі кожного зонда. Якщо відповіді на тестування надходять з різних шлюзів, друкується адреса кожної системи, яка відповідає. Якщо traceroute не отримує відповідь протягом п’яти секунд (змінюється за допомогою -w прапор), він друкує зірочку для цього зонда.
Щоб не допустити, щоб обробка пакетів UDP переповнювала кінцевий хост, traceroute встановлює для порту призначення значення, яке пристрій навряд чи використає. Якщо мережа або служба в місці призначення використовує цей порт, змініть значення за допомогою -стр прапор.
Приклади результатів Traceroute
Зразок використання та виведення поверне результати, подібні до цього прикладу:
[як 71]% traceroute nis.nsf.net.
traceroute до nis.nsf.net (35.1.1.48), максимум 30 переходів, пакет 38 байт
1 helios.ee.lbl.gov (128.3.112.1) 19 мс 19 мс 0 мс
2 бузок-dmc. Берклі. EDU (128.32.216.1) 39 мс 39 мс 19 мс
3 бузок-dmc. Берклі. EDU (128.32.216.1) 39 мс 39 мс 19 мс
4 ccngw-ner-cc. Берклі. EDU (128.32.136.23) 39 мс 40 мс 39 мс
5 ccn-nerif22.Берклі. EDU (128.32.168.22) 39 мс 39 мс 39 мс
6 128.32.197.4 (128.32.197.4) 40 мс 59 мс 59 мс
7 131.119.2.5 (131.119.2.5) 59 мс 59 мс 59 мс
8 129.140.70.13 (129.140.70.13) 99 мс 99 мс 80 мс
9 129.140.71.6 (129.140.71.6) 139 мс 239 мс 319 мс
10 129.140.81.7 (129.140.81.7) 220 мс 199 мс 199 мс
11 nic.merit.edu (35.1.1.48) 239 мс 239 мс 239 мс
Другий і третій рядки однакові. Цей результат стосується помилкового ядра в системі другого стрибка — lbl-csam.arpa — яке пересилає пакети з нульовим TTL (помилка в розподіленій версії 4.3 BSD). Ви повинні здогадатися, який шлях переміщуються пакети між країнами, оскільки NSFNet (129.140) не забезпечує трансляції адреси в ім'я для своїх NSS.
Приклад тихого шлюзу
Більш цікавий приклад:
[як 72]% traceroute allspice.lcs.mit.edu.
traceroute до allspice.lcs.mit.edu (18.26.0.115), максимум 30 хмелів
1 helios.ee.lbl.gov (128.3.112.1) 0 мс 0 мс 0 мс
2 бузок-dmc. Берклі. EDU (128.32.216.1) 19 мс 19 мс 19 мс
3 бузок-dmc. Берклі. EDU (128.32.216.1) 39 мс 19 мс 19 мс
4 ccngw-ner-cc. Берклі. EDU (128.32.136.23) 19 мс 39 мс 39 мс
5 ccn-nerif22.Берклі. EDU (128.32.168.22) 20 мс 39 мс 39 мс
6 128.32.197.4 (128.32.197.4) 59 мс 119 мс 39 мс
7 131.119.2.5 (131.119.2.5) 59 мс 59 мс 39 мс
8 129.140.70.13 (129.140.70.13) 80 мс 79 мс 99 мс
9 129.140.71.6 (129.140.71.6) 139 мс 139 мс 159 мс
10 129.140.81.7 (129.140.81.7) 199 мс 180 мс 300 мс
11 129.140.72.17 (129.140.72.17) 300 мс 239 мс 239 мс
12 * * *
13 128.121.54.72 (128.121.54.72) 259 мс 499 мс 279 мс
14 * * *
15 * * *
16 * * *
17 * * *
18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 мс 279 мс 279 мс
Зауважте, що шлюзи на відстані 12, 14, 15, 16 і 17 або не надсилають ICMP-повідомлення про перевищення часу, або надсилають їх із занадто малим TTL, щоб до нас дістатися. У рядках з 14 по 17 виконується код шлюзу MIT C, який не надсилає повідомлення про перевищення часу.
Безшумний шлюз 12 у наведеному вище прикладі може бути результатом помилки в коді мережі 4.[23]BSD та його коді мережі. похідні: машини з кодом 4.3 і раніше надсилають повідомлення про недоступність, використовуючи будь-який TTL, що залишився в оригінальна дейтаграма. Для шлюзів TTL, що залишився, дорівнює нулю, ICMP "перевищений час" гарантовано не повернеться до нас.
Приклад тихого шлюзу системи призначення
Поведінка цієї помилки трохи цікавіша, коли вона з’являється в системі призначення:
1 helios.ee.lbl.gov (128.3.112.1) 0 мс 0 мс 0 мс
2 бузок-dmc. Берклі. EDU (128.32.216.1) 39 мс 19 мс 39 мс
3 бузок-dmc. Берклі. EDU (128.32.216.1) 19 мс 39 мс 19 мс
4 ccngw-ner-cc. Берклі. EDU (128.32.136.23) 39 мс 40 мс 19 мс
5 ccn-nerif35.Берклі. EDU (128.32.168.35) 39 мс 39 мс 39 мс
6 csgw. Берклі. EDU (128.32.133.254) 39 мс 59 мс 39 мс
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 рип. Берклі. EDU (128.32.131.22) 59 мс! 39 мс! 39 мс!
Зверніть увагу, що існує 12 «шлюзів» (13 — кінцевий пункт призначення), а остання половина з них відсутня. Насправді відбувається те, що сервер назвав розривати (Sun-3 під керуванням Sun OS 3.5) використовує TTL з нашої дейтаграми, що надходить, як TTL у своїй відповіді ICMP. Отже, час очікування відповіді на зворотному шляху (без повідомлення нікому, оскільки ICMP не надсилається для ICMP) поки ми не будемо досліджувати за допомогою TTL, який принаймні вдвічі перевищує довжину шляху — іншими словами, rip насправді становить лише сім стрибків далеко.
Відповідь, яка повертається з TTL 1, є підказкою про існування цієї проблеми. Traceroute друкує a! через час, якщо TTL менше або дорівнює 1. Оскільки постачальники постачають багато застарілого (DEC Ultrix, Sun 3.x) або нестандартного (HPUX) програмного забезпечення, очікуйте, що ця проблема буде часто зустрічатися, і подбайте про вибір цільового хосту ваших зондів.
Інші можливі анотації після часу !H, !Н, або !P (хост, мережа або протокол недоступні), !S (помилка вихідного маршруту), !F- (необхідна фрагментація — відображається значення RFC1191 Path MTU Discovery), !X (спілкування адміністративно заборонено), !В (порушення пріоритету хосту), !C (діє обмеження пріоритету), або ! (Недоступний код ICMP). Ці коди визначаються RFC1812, який замінює RFC1716. Якщо майже всі проби призведуть до якогось недосяжного хоста, traceroute відмовиться і вийде.
Ця програма призначена для тестування, вимірювання та керування мережею. Його слід використовувати в першу чергу для ручної ізоляції несправностей. Через навантаження, яке воно може накласти на мережу, нерозумно використовувати traceroute під час звичайних операцій або з автоматизованих сценаріїв.