Для чего сетевой администратор может использовать утилиту tracert: Tracert vs Traceroute / Habr – Что такое tracert? И как его запускать: инструкция

Tracert vs Traceroute / Habr

В чем отличие маршрута пакета от его пути?
Стандартный механизм маршрутизации пакетов в интернете — per hop behavior — то есть каждый узел в сети принимает решение куда ему отправить пакет на основе информации, полученной от протоколов динамической маршрутизации и статически указанных администраторами маршрутов.

Маршрут — это интерфейс, в который нам надо послать пакет для достижения какого то узла назначения и адрес следующего маршрутизатора (next-hop):

R1#sh ip rou | i 40.  
	 40.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O        40.0.0.0/31 [110/3] via 20.0.0.0, 00:01:54, FastEthernet0/0
O        40.1.1.1/32 [110/4] via 20.0.0.0, 00:00:05, FastEthernet0/0

Что такое путь? Путь — это список узлов, через которые прошел (пройдет) пакет:
 1  10.0.0.1  16.616 ms  16.270 ms  15.929 ms
 2  20.0.0.0  15.678 ms  15.157 ms  15.071 ms
 3  30.0.0.1  26.423 ms  26.081 ms  26.744 ms
 4  40.0.0.0  48.979 ms  48.674 ms  48.384 ms
 5  100.0.0.2  58.707 ms  58.773 ms  58.536 ms

Путь пакета можно посмотреть с помощью утилит tracert в OC Windows и traceroute в GNU/Linux и Unix-подобных системах. (другие команды, типа tracepath мы не рассматриваем).
Многие считают что этих утилит один и тот же принцип работы, но это не так. Давайте разберемся.

Итак, утилита tracert.
В основе работы данной утилиты лежит протокол icmp. Рассмотрим вот такую схему:

Host отправляет по указанному в его таблице маршрутизации маршруту ICMP Echo-Request с ttl 1. Router1, получив такой пакет, проверит адрес назначения — может быть пакет ему. Так как данный пакет адресован другому хосту, то Router1 считает себя транзитным узлом, декрементирует ttl пакета и отбрасывает его, так как время жизни пакета становится равным 0. Так как пакет был дропнут, Router1 отправляет источнику пакета icmp сообщение с указанием причины дропа — Time Exceeded. Утилита tracert, получив данное icmp сообщение, указывает Router1 как первый хоп (информация об адресе указана в icmp сообщении). Далее процесс повторяется с инкрементированием ttl, пока ttl icmp запроса не будет равен количеству хопов между узлом-отправителем и узлом получателем. В данном примере Server1 является узлом назначения. Получив пакет, он проверит адрес назначения, увидит, что запрос адресован ему и отправит ICMP Echo-Reply, что и будет являться для утилиты tracert триггером к окончанию трассировки.

Вывод:
Icmp -протокол третьего уровня, и о портах он не знает ничего. Поэтому сделать tracert с указанием порта невозможно. Надеюсь тут мы разобрались.

Traceroute — данная утилита работает по иному принципу, хоть и вывод команды похож на вывод предыдущей.
Traceroute основана не на ICMP Echo-Request, а на отправке udp фрагментов и получения сообщения о доступности/недостижимости порта. Вернемся к прошлой схеме. Host генерирует udp фрагмент, инкапсулирует его в IP пакет и выставляет ttl=1. Router1, являясь транзитным узлом, ответит на данный пакет icmp сообщением об окончании времени жизни пакета. Утилита traceroute, получив данное сообщение, указывает адрес источника icmp пакета (Router1) как адрес первого хопа. Далее процесс повторяется с инкрементированием ttl пакета. Всё практически так же, как и в tracert. Но ведь мы не отправляем ICMP Echo-Request, как утилита traceroute поймет, что трассировка закончена? Все просто — в udp заголовке есть поля source и destination порт. Логично, что source порт будет любым портом выше 1023. А каким указать destination порт? Как было сказано выше, работа утилиты traceroute основана на получении сообщения о недостижимости или доступности порта назначения. То есть мы отправляем udp фрагмент с порта 45000 ( к примеру) на порт 33434 (именно этот порт используется по умолчанию). Как и в предыдущем случае, Server1 является узлом назначения. Получив пакет, он распаковывает его и должен передать его протоколам высшего уровня. Но так как порт 33434 по умолочанию будет закрыт на сервере, то Server1 формирует icmp сообщение о недостижимости порта назначения (ICMP Type 3 «Destination Unreachable» Code 3 «Port Unreachable»). Получив данное сообщение, утилита traceroute считает трассировку законченной. В процессе трассировки номер порта назначения будет инкрементироваться при каждой попытке ( 33434, 33435 и т д). Может получится так, что порт назначения будет открыт. В данном случае сервер отправит на хост-инициатор например TCP ACK если для трассировки используются TCP SYN пакеты, что тоже будет являться триггером к окончанию трассировки.

Вывод:
Утилита traceroute позволяет сделать трассировку с указанием порта назначения.

Для этого разберем пример ниже:

Возьмем предыдущую схему и сделаем трассировку:

С использованием TCP SYN пакетов:

bormoglots@ubuntu-server-s1:~$ sudo traceroute -T -p 22 -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
 1  10.0.0.1  16.616 ms  16.270 ms  15.929 ms
 2  20.0.0.0  15.678 ms  15.157 ms  15.071 ms
 3  30.0.0.1  26.423 ms  26.081 ms  26.744 ms
 4  40.0.0.0  48.979 ms  48.674 ms  48.384 ms
 5  100.0.0.2  58.707 ms  58.773 ms  58.536 ms

C использованием UDP пакетов:
bormoglots@ubuntu-server-s1:~$ sudo traceroute -U -p 22 -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
 1  10.0.0.1  7.102 ms  6.917 ms  6.680 ms
 2  20.0.0.0  17.021 ms  16.838 ms  17.051 ms
 3  30.0.0.1  31.035 ms  30.859 ms  30.658 ms
 4  40.0.0.0  41.124 ms  40.941 ms  40.728 ms
 5  100.0.0.2  51.291 ms  51.045 ms  50.720 ms

Как видите трассировка прошла успешно. Мы видим путь до указанного хоста.

А теперь повесим на интерфейс Router4 фильтр на in (как указано на рисунке):

R4#sh run int fa0/0
Building configuration...

Current configuration : 121 bytes
!
interface FastEthernet0/0
 ip address 40.0.0.0 255.255.255.254
 ip access-group deny-to-server in
 duplex half
 !
end

R4#sh access-lists deny-to-server
Extended IP access list deny-to-server
    10 deny tcp any host 100.0.0.2 log (32 matches)
    20 deny udp any host 100.0.0.2 log (29 matches)
    30 permit ip any any (128 matches)

Снова сделаем трассировку:
bormoglots@ubuntu-server-s1:~$ sudo traceroute -T -p 22 -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
 1  10.0.0.1  4.575 ms  4.490 ms  4.367 ms
 2  20.0.0.0  18.431 ms  18.359 ms  29.573 ms
 3  30.0.0.1  30.579 ms  30.690 ms  30.722 ms
 4  40.0.0.0  52.518 ms !X  62.977 ms !X  62.898 ms !X
bormoglots@ubuntu-server-s1:~$ sudo traceroute -U -p 22 -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
 1  10.0.0.1  5.614 ms  5.523 ms  5.689 ms
 2  20.0.0.0  18.364 ms  18.629 ms  18.556 ms
 3  30.0.0.1  42.289 ms  42.225 ms  42.143 ms
 4  40.0.0.0  41.984 ms !X  41.898 ms !X  41.815 ms !X

Теперь трассировка закончилась на предпоследнем хопе и в выводе появились знаки! Х. Почему это произошло? Router4 получив пакет к Server1 дропает его, так как он попадает под запрещающее правило на входящем интерфейсе и отправляет хосту-инициатору сообщение о том, что пакет был зафильтрован (ICMP Type 3 «Destination Unreachable» Code 13 — «Communication Administratively Prohibited»). Это тоже сообщение о недостижимости порта назначения. Поэтому утилита traceroute получив такое сообщение, заканчивает свою работу так не добравшись до хоста назначения. В данном случае в выводе важно понять, что пакеты были именно зафильрованы, о чем нам подсказывает знак !X (в Unix) или знак !A (в Cisco):
R1#traceroute 100.0.0.2 Type escape sequence to abort. Tracing the route to 100.0.0.2 1 20.0.0.0 24 msec 24 msec 16 msec 2 30.0.0.1 16 msec 36 msec 40 msec 3 40.0.0.0 !A !A !A

Примечание: Возможен случай, когда пакеты будут дропаться без отправки ICMP сообщений ( отправка в Null-интерфейс в Cisco/Huawei или discard в Juniper). В данном случае трассировка будет идти пока не кончится максимальное TTL, указанное в утилите traceroute (по умолчанию максимум 30 хопов, но можно задать вручную до 255, правда обычно достаточно 15-18 хопов) или ее не прервет администратор, а в выводе будут звездочки.

Примечание: Появление звездочек вместо адресов хостов может быть обусловлено различными причинами и хорошо описано тут

Собственно говоря, утилита traceroute может работать как и утилита tracert с использованием ICMP Echo-Request. Для этого ее следует запустить с ключом -I. В примеры выше фильтр не блокирует ICMP, поэтому трассировка с использованием данного протокола покажет нам весь путь пакета:

bormoglots@ubuntu-server-s1:~$ sudo traceroute -I -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
 1  10.0.0.1  4.073 ms  3.986 ms  3.890 ms
 2  20.0.0.0  19.474 ms  19.389 ms  19.294 ms
 3  30.0.0.1  30.147 ms  30.276 ms  30.826 ms
 4  40.0.0.0  42.316 ms  42.240 ms  42.145 ms
 5  100.0.0.2  52.705 ms  52.622 ms  52.521 ms

Надеюсь мы разобрались в основных принципах работы данных утилит. Если надо сделать трассировку по какому то порту в Windows системах, можно использовать сторонние утилиты, к примеру tcptrace.

Спасибо за внимание!

про умение читать вывод / Habr

  • Почему в трейсроуте после узла X идут звездочки?
  • Сервис не работает, а трейсроут обрывается на узле X — значит проблема в узле X?
  • Почему одинаковые трейсроуты с Windows и Unix показывают разные результаты?
  • Почему трейсроут показывает большие задержки на определенном узле?
  • Почему трейсроут показывает «серые» адреса при трассировке через интернет?
  • Почему маршрутизатор отвечает на трейсроут не тем адресом, каким я хочу?
  • Почему трейсроут показывает какие-то «не такие» доменные имена?
  • Почему вообще вывод трейсроута отличается от интуитивно ожидаемого чаще, чем хотелось бы?

Сетевые инженеры и администраторы в отношениях с трейсроутом делятся на две категории: регулярно задающие себе и окружающим эти вопросы и заколебавшиеся на них отвечать.

Сей топик не дает ответов на вышепоставленные вопросы. Или почти не дает. Но предлагает подумать, нужно ли их вообще задавать, и если да, то когда и кому.

По поводу взаимоотношений с трейсроутом Ричард нашевсе Стинберген сделал на конференции NANOG-47 (2009) доклад, тезисы которого я и рекомендую к изучению всем заинтересованным лицам. A Practical Guide to (Correctly) Troubleshooting with Traceroute (PDF, 222 КБ) (на английском, разумеется, языке).

Не стану пересказывать тут подробности (желающие да прочтут), остановлюсь лишь на своде аргументов и выводах, которые хорошо бы иметь в виду, прежде чем звать на помощь с криком «у меня трейс показывает, что…»

Все ниже (и выше) излагаемое — моя личная точка зрения. Топик написан под влиянием указанной презентации, но не является ни ее пересказом, ни, упаси господь, переводом. Возможно даже, вы сможете обнаружить в ней разночтения с данным топиком. Уж как минимум не стоит приписывать Ричарду тех или иных высказываний, прочтя их у меня, но не сверившись с его докладом.

Некоторые факты (без углубления в детали)
  • Задержка прохождения пакета по сети складывается из нескольких факторов: сериализация, буферизация, распространение. Каждый из факторов сложнее, чем вы о нем думаете.
  • Задержка, которую вам показывает трейсроут, — еще более комплексная величина: маршрутизаторы обрабатывают пакеты, адресованные самим себе, абсолютно иначе, чем транзитные пакеты. Данное обстоятельство приводит к специфической природе значений задержек, которые нам показывает трейсроут. Из этого не следует, что на них нельзя ориентироваться, но нужно уметь их читать.
  • Трафик в интернете почти всегда идет разными путями в направлениях от клиента к серверу и от сервера к клиенту. Трейсроут же всегда показывает суммарную задержку в обе стороны, а трассировку — только по одному направлению.
  • Указание трейсроуту адреса источника на устройстве с несколькими интерфейсами (маршрутизаторе) не влияет на выбор интерфейса, с которого будут отправлены запросы. А влияет — на выбор обратного пути, по которому передаются ответы. Их трассировка не видна в выводе, но таким образом можно измерять разницу задержки для параллельных обратных маршрутов.
  • Использование L3-балансировки где-то на интернет-магистралях скорее всего заставит разные пакеты в рамках одной трассировки идти разными путями. Такое поведение приводит к сложноинтерпретируемому выводу, грамотно прочесть который может далеко не каждый.
  • Современные маршрутизаторы при ответе на трейсроут не соблюдают требования пункта 4.3.2.4 RFC1812, обязывающего устанавливать IP-адрес источника ICMP-ответов равным адресу исходящего интерфейса. Вместо этого они устанавливают его равным адресу интерфейса, на который был получен трейсроут-запрос (пакет с TTL=1). Впрочем, если б было наоборот, читать вывод трейсроута было бы куда тяжелее.
  • Наличие MPLS-коммутации внутри магистральных сетей (нынче это так у любого уважающего себя крупного провайдера) приводит к контруинтуитивному пути передачи ответов на трейсроут и еще менее очевидному способу вычисления задержек.

Некоторые наиболее важные выводы (с моим творческим осмыслением)
  • Трейсроут — не такая простая штука, как кажется; ею нужно уметь пользоваться. А для этого надо понимать, как она работает.
  • Большинство админов и инженеров служб эксплуатации, не говоря уже о простых пользователях, не понимают и не умеют. Такое положение дел очень часто приводит к ложным тревогам, неправильной диагностике и т. п.
  • Трейсроут трейсроуту рознь. Стандартные утилиты tracert в Windows и traceroute в Линукс реализованы по-разному и могут давать разные результаты. Windows посылает ICMP, а Linux — UDP, файрволы на пути трассировки могут иметь неодинаковые настройки фильтрации для разных протоколов.
  • При интерпретации результатов трассировки требуется опыт и сообразительность. Бывает, что важные выводы можно сделать лишь путем догадки, опираясь на косвенные данные, а иные — и вовсе не однозначно, а лишь с точностью до «скорее всего».

Итого

Если вы клиент
Не донимайте техподдержку провайдеров, интеграторов, вендоров корпоративный хелп-деск и т. п. выводами трейсроута, если только вы не абсолютно уверены в ответе на вопрос «почему я именно так интерпретирую трассировку?» В лучшем случае вас просто проигнорируют или пошлют. В худшем — можете убедить неопытных сотрудников поддержки в справедливости своей неправильной версии, в результате чего они отправятся копать проблему совсем не в том месте, где нужно.

Если вы не видите проблем с сервисом (все работает), но в выводе трейсроута вам что-то не нравится — подумайте хорошенько, прежде чем подымать тревогу. Крайне вероятно, что вы просто неверно интерпретируете вывод. Очень нечасто по одному трейсроуту можно судить о наличии проблемы. А если проблема действительно есть, обычно ее проще продемонстрировать без трейсроута.

Если вы исполнитель
Никогда не ведитесь на чужую интерпретацию вывода трейсроута. Думайте своей головой (всегда пожалуйста — ваш кэп). Вообще, если сообщение о проблеме начинается с вывода трейсроута — это верный признак, что прежде чем что-либо делать, излагаемые дальше сведения нужно трижды перепроверить лично.

Прочтите презентацию Ричарда. С осторожностью пользуйтесь трейсроутом, как основным инструментом траблшутинга: ошибиться в интерпретации очень легко, информации часто недостаточно для однозначных выводов. Всегда сопоставляйте показания трейсроута с другими доступными данными, по возможности пользуйтесь им лишь в качестве дополнительной или черновой информации.

Утилита tracert или как проверить маршрут до хоста. Сетевые утилиты 2 часть

Утилита tracert или как проверить маршрут до хоста. Сетевые утилиты 2 часть-01

Всем привет ранее я начал рассказ про сетевые утилиты системного администратора в статье Утилита ping или как проверить доступность хоста. Сетевые утилиты 1 часть, движемся дальше и разбираем еще одну утилиту tracert или как проверить маршрут до хоста. Сетевые утилиты 2 часть.

Traceroute — это служебная компьютерная программа, предназначенная для определения маршрутов следования данных в сетях TCP/IP. Traceroute может использовать разные протоколы передачи данных в зависимости от операционной системы устройства. Такими протоколами могут быть UDP, TCP, ICMP или GRE. Компьютеры с установленной операционной системой Windows используют ICMP-протокол, при этом операционные системы Linux и маршрутизаторы Cisco — протокол UDP.

Открываем командную строку Windows и вводим tracert. Перед вами откроется справка команды tracert.

Утилита tracert или как проверить маршрут до хоста. Сетевые утилиты 2 часть-02

C:\Users\sem>tracert

Использование: tracert [-d] [-h максЧисло] [-j списокУзлов] [-w таймаут]
[-R] [-S адресИсточника] [-4] [-6] конечноеИмя

Параметры:
-d Без разрешения в имена узлов.
-h максЧисло Максимальное число прыжков при поиске узла.
-j списокУзлов Свободный выбор маршрута по списку узлов (только IPv4).
-w таймаут Таймаут каждого ответа в миллисекундах.
-R Трассировка пути (только IPv6).
-S адресИсточника Используемый адрес источника (только IPv6).
-4 Принудительное использование IPv4.
-6 Принудительное использование IPv6.

Давайте посмотрим каким маршрутом мы обращаемся до яндекса. Вводим

Видим каждого участника маршрута, они еще называются хопами. В роли участников выступают маршрутизаторы разных провайдеров и на конце хост назначения.

Утилита tracert или как проверить маршрут до хоста. Сетевые утилиты 2 часть-03

Для ускорения получения информации из tracert можно отключить разрешение имен и получать только ip адреса, скорость увеличиться.

Утилита tracert или как проверить маршрут до хоста. Сетевые утилиты 2 часть-04

Если у вас с какого то момента пошли звездочки вместо адресов то вероятнее всего данных хост не доступен и из за него вы не можете попасть на нужный вам ресурс, обычно так выясняется на уровне какого провайдера сейчас сетевая проблема.

Утилита tracert или как проверить маршрут до хоста. Сетевые утилиты 2 часть-05

Вот такая вот полезная утилита tracert и вы научились с помощью нее проверять маршрут до нужного вам хоста. Читайте далее утилита pathping или как точно диагностировать проблему на маршруте до сайта. Сетевые утилиты 3 часть.

Материал сайта pyatilistnik.org

Команда tracert поможет в диагностике проблем со связью

Команда tracert служит для запуска диагностической утилиты, определяющей маршрут прохождения трафика в сети. Эта программа присутствует в большинстве современных операционных систем. Используется утилита в основном при тестировании и выявлении проблемного места в сети.

Что проверяет команда tracert?

Команда tracertTracert посылает в точку назначения запросы подобно команде ping. Заметив, что пользователем набрана команда tracert, Windows отправляет специально помеченные пакеты, которые, достигнув первого же шлюза, возвращаются обратно на компьютер пользователя. При этом в полученных данных содержится информация об узле, вернувшем его. После этого отправляется следующий запрос, в теле которого уже присутствует указание пропустить его предыдущему шлюзу.

Последовательная отправка пакетов позволяет получить полный маршрут прохождения информации от компьютера пользователя до любого узла в интернете или локальной сети. Таким образом, команда tracert становится необходимым инструментом при диагностировании проблем, позволяя выявить участок, на котором пакеты теряются.

Запуск команды tracert в Windows

Запустить утилиту проверки сетевого маршрута в Windows можно из командной строки. В версиях операционной системы ниже 8, чтобы открыть интерфейс командной строки, достаточно нажать «Пуск-Выполнить» и набрать cmd. В Windows 8 придется обратиться к меню «Все программы» и найти там пункт «Командная строка». В любой версии ОС также можно воспользоваться сочетанием клавиш Win+R.

Команда tracert windows

Попав в командную строку, необходимо ввести tracert domen.ru, где вместо domen.ru можно указать любое доменное имя или IP-адрес. Это приведет к запуску утилиты со стандартными параметрами.

Ключи команды tracert

Запущенная опытным пользователем, содержит команда tracert описание ключей. Его можно вызвать, просто набрав команду tracert с параметром -?.

Приведем краткое описание параметров, которые поддерживает команда tracert:

  • -h задает максимальное количество переходов, которое может быть выполнено при поиске конечного узла.
  • -d запрещает команде производить попытки превратить IP-адрес промежуточного шлюза в имя.
  • -j позволяет утилите производить свободный поиск маршрута по списку узлов. Максимум можно указать 9 маршрутизаторов.
  • -w служит для указания времени ожидания ответа на запрос от узла. Если ответ не получен, то будет выведена звездочка. Указывается в миллисекундах.

По умолчанию максимальное число прыжков ограничено 30-ю, а время ожидания — 4-мя секундами.

Аналог в Linux

команда tracert описаниеПользователям операционной системы Linux доступна утилита с более широким функционалом, чем имеет команда tracert. Называется она traceroute. Отличается данное приложение от аналога для Windows наличием разнообразных режимов, которые задаются с помощью параметров.

Запуск трассировки с помощью ICMP осуществляет команда tracertroute с ключом –I. Стоит обратить внимание, что для выполнения этой операции потребуются права администратора. При стандартных настройках в большинстве дистрибутивов запуск команды tracertroute может быть осуществлен любым пользователем. В этом случае будут использовать UDP-пакеты, также можно утилите принудительно указать использовать именно их с помощью параметра –U.

Звездочки в выводе маршрутов

Очень часто команда tracert или ее аналог для Linux в ряде мест выводят вместо информации об ответе узла звездочки. Не стоит рассматривать это как ошибку. Это означает только одно: конкретный маршрутизатор не ответил на запрос за заданный период времени. Ничего плохого в этом нет, так как причин может быть достаточно много. Одна из них – установка файерволов или других средств защиты, блокирующих прохождение определенных пакетов.

tracert команда

Что следует знать о трассировке маршрутов?

Tracert — команда, которая очень важна при диагностике сетевых проблем. Однако стоит учитывать, что ошибиться, рассматривая вывод команды tracert, достаточно просто. Поэтому не надо использовать трассировку маршрутов как единственное средство поиска неполадок.

Еще одной причиной того, что трассировка может только косвенно указать на проблему, является отличие маршрутов прохождения пакетов в интернете в разном направлении. Как правило, пакет, отправленный пользователем, до сервера идет через одни узлы, а посланный обратно — совершенно по-другому.

Задержки прохождения пакетов, присутствующие в выводе утилиты tracert или traceroute, не имеют ничего общего с задержками для транзитных пакетов. Это связано со спецификой их обработки на маршрутизаторе. Поэтому для ориентирования на них необходимо уметь правильно читать вывод команды, что довольно сложно.

Утилита MTR

Программа MTR существует в версиях для большинства операционных систем. Принцип ее работы очень похож на команду tracer (traceroute). Она опрашивает заданный узел в течение определенного промежутка времени, при этом позволяя зафиксировать изменения задержек.

Версия утилиты для Windows имеет название WinMTR и распространяется бесплатно.

что проверяет команда tracertПользователю предоставляется возможность работать с графическим интерфейсом, в котором необходимо указать IP-адрес или домен узла назначения, запустить сбор статистики. Как правило, для анализа необходимо отправить минимум 100 пакетов.

Пользователям Linux также придется MTR устанавливать дополнительно из репозиториев. В этих операционных системах обычно используется консольная версия утилиты. Пользователю доступны разнообразные параметры, позволяющие задать количество отправляемых пакетов, запись отчета в файл, таймаут. Также версия для Linux может использовать для тестирования определенные порты или TCP-пакеты.

Что следует отправлять провайдеру для диагностики сетевых проблем?

Администратору сервера или провайдеру, как правило, лучше отправить выводы команд tracert (traceroute), ping и отчет утилиты MTR. Можно, конечно, постараться обойтись только последним, но чем больше информации предоставлено, тем легче специалисту найти и устранить проблему.

Трассировка маршрута сети (команда tracert) — 192.168.1.1 admin логин вход

Для диагностики и поиска проблем в сети системные администраторы часто применяют такой удобный инструмент, как трассировка маршрута. Она позволяет определить все узлы (маршрутизаторы, серверы, компьютеры), через которые проходит трафик по дороге к точке назначения. Если связь с каким-либо удалённым хостом рвётся или вообще пропадает, то трассировка маршрута сети позволит быстро найти участок, на котором появились проблемы как в локальной сети, так и в глобальной паутине Интернет.
Для выполнения этой процедуры в каждой современной операционной системе есть соответствующий инструмент. 

tracert трассировка сети

 В ОС Windows — это утилита tracert. В XP она была доступна по умолчанию, а вот во всех последующих версия вплоть до Windows 10 её надо включать дополнительно через «Программы и Компоненты».

В операционных система ОС семейства *NIX — Linux, FreeBSD, Android — программа traceroute
Смысл алгоритма трассировки маршрута в том, что посылается по три специальных запроса на каждый сетевой узел, через который идёт трафик до нужного хоста, затем для каждого из них на экране, рядом с его адресом, выдаётся время ответа.По этим результатам можно легко отследить на каком участке сети начинают повяляться задержки ответа или он вообщ пропадает.

Трассировка в Windows 10

Для проведения трассировки сети в Windows 10 необходимо нажать комбинацию клавиш Win+R и в окне «Выполнить» набрать команду «cmd». Этим Вы откроете командную строку Виндовс, в которой надо ввести команду:

tracert <IP-адрес или имя сервера>

Для примера возьмём сайт google.ru

windows 10 tracert команда

Трассировка в Linux

В операционных системах семейства Linux — Ubuntu, Fedora, CentOS и т.п. — для запуска трассировки маршрута в надо открыть системную консоль и ввести команду:

traceroute <имя_сервера>

Пример:

traceroute трассировка маршрута

Внимание! Использовать трассировку маршрута в сети для оценки качества последней мили (абонентской линии ADSL,FTTB или PON) нельзя, так как эта системная программа никоим образом оценить качество линии не может и не умеет.

Команда traceroute Linux | Losst

Не всегда сеть работает так, как от нее требуется, иногда определенный компьютер в вашей локальной сети компании, или удаленный может не отвечать. Казалось бы, все работает, все подключено, но похоже на каком-то из узлов, на пути от вашего компьютера, до нужного случается ошибка.

Утилита ping позволяет только определить наличие проблемы, что узел не отвечает, но как узнать где обрывается соединение? Для этого применяется утилита traceroure. В этой небольшой инструкции мы рассмотрим как пользоваться traceroute linux, как понимать ее вывод и определить где же все-таки проблема. Но сначала рассмотрим, как работает traceroute.

Содержание статьи:

Как работает traceroute?

Вы, наверное, уже знаете, что вся информация в сети передается в виде пакетов. Поток данных разбивается специальным программным обеспечением на небольшие пакеты и передается через сеть интернет на целевой узел, а там собирается обратно.

Каждый пакет проходит на своем пути определенное количество узлов, пока достигнет своей цели. Причем, каждый пакет имеет свое время жизни. Это количество узлов, которые может пройти пакет перед тем, как он будет уничтожен. Этот параметр записывается в заголовке TTL, каждый маршрутизатор, через который будет проходить пакет уменьшает его на единицу. При TTL=0 пакет уничтожается, а отправителю отсылается сообщение Time Exceeded.

Команда traceroute linux использует UDP пакеты. Она отправляет пакет с TTL=1 и смотрит адрес ответившего узла, дальше TTL=2, TTL=3 и так пока не достигнет цели. Каждый раз отправляется по три пакета и для каждого из них измеряется время прохождения. Пакет отправляется на случайный порт, который, скорее всего, не занят. Когда утилита traceroute получает сообщение от целевого узла о том, что порт недоступен трассировка считается завершенной.

Утилита Traceroute

Перед тем как перейти к примерам работы с утилитой давайте рассмотрим ее синтаксис и основные опции. Синтаксис вызова очень прост:

$ traceroute опции адрес_узла

В качестве адреса может использоваться ip адрес или доменное имя. Рассмотрим основные опции:

  • -4 или -6 — использовать ipv4 или ipv6 протокол;
  • -I — использовать ICMP пакеты вместо UDP;
  • -T — использовать TCP пакеты вместо UDP;
  • -F — не фрагментировать пакеты;
  • -f — указать TTL с которого нужно начать;
  • -g — передавать пакет через указанный шлюз;
  • -i — передавать пакет через указанный интерфейс;
  • -m — максимальное количество узлов, через которые пройдет пакет;
  • -q — количество пакетов, отправляемых за раз, по умолчанию три;
  • -n — не узнавать доменные имена;
  • -p — указать порт вместо порта по умолчанию;
  • -w — установить время ожидания ответа от узла, по умолчанию полсекунды;
  • -r — использовать другой роутер вместо того, что указанный в таблице маршрутизации;
  • -z — минимальный интервал между пакетами;
  • -U — использовать UDP с увеличением номера порта;
  • -UL — использовать протокол UDPLITE;
  • -D — использовать протокол DCCP;
  • —mtu — указать размер пакета;
  • -P — протокол, доступны такие значения: raw, dccp, udplite, udp, tcpconn, tcp, icmp.

Это не все опции утилиты, но все основные, которыми вы будете пользоваться. Дальше перейдем практике того, как выполняется трассировка сети Linux.

Примеры трассировки сети в Linux

Например, выполним трассировку до сервера losst.ru:

sudo traceroute losst.ru

Как видите, пакет прошел через 6 узлов перед тем, как дойти до цели. На каждый узел отправлялось по три пакета и для каждого из них было засечено время прохождения. И если на одном из узлов возникнет проблема, теперь вы будете знать на каком.

У вас, наверное, возник вопрос, почему время прохождения для некоторых узлов такое долгое? Ведь если выполнить ping, то общее время будет намного меньше. Дело в том, что время засекается для пути пакета туда и обратно. От запроса до ответа. Это раз, но еще нужно учитывать что маршрутизаторы дают высший приоритет для приходящих пакетов, когда для сервисных  задержки могут быть более длинными.

Еще, вместо одного узла вы можете видеть звездочки traceroute. Это еще не значит, что он не работает. Это означает что всего лишь он не захотел нам отвечать. Давайте проверим еще что-нибудь, например, публичный DNS google:

sudo traceroute 8.8.8.8

Здесь уже больше узлов, и такая же ситуация со звездочками. Если бы на пути к серверу возникла ошибка, мы бы это увидели. Например, узел 195.153.14.1 нам не ответил и мы смогли отследить запрос только до 212.162.26.169.

sudo traceroute 195.153.14.1

Иногда трассировка с помощью UDP не работает, это может произойти потому, что фаервол блокирует все лишние пакеты. Мы можем воспользоваться ICMP с помощью опции -I.

sudo traceroute history.pl

sudo traceroute -I history.pl

Но трассировка может использоваться не только для обнаружения обрыва в цепочке маршрутизаторов. У нее еще есть достаточно интересное применение по исследованию сети. Например, вы можете попытаться определить использование подсетей провайдером. Отправим три запроса на разные адреса:

sudo traceroute losst.ru
$ sudo traceroute history.pl
$ sudo traceroute habrahabr.ru

Затем сравните выводы этих команд. Вы увидите, что начальные IP адреса одинаковые. Мы можем сделать вывод, что наш роутер 192.168.1.1 подключен к локальной сети провайдера 195.5.8.0/24, которая, в свою очередь, подключена к сети 10.50.50.0/24 откуда уже получает доступ к внешней сети.

Выводы

В этой статье мы рассмотрели как работает команда traceroute linux, а также как выполняется трассировка сети linux. Эти функции больше нужны системным администраторам, но и обычным пользователям тоже иногда могут пригодиться.

Оцените статью:

Загрузка…

Как работает traceroute — «Хакер»

Бывают в сетевой жизни (особенно у dial-up юзеров 😉 моменты, когда невозможно достучаться до какого-нибудь хоста (у меня это часто www.microsoft.com ;-|) — здесь то на помощь и придет эта утилита (в Windows — tracert.exe). С ее помощью можно попытаться определить на каком участке IP-сети произошел сбой — то ли хост упал, то ли у провайдер тормоза, или у тебя с IP-соединением хреново :).

Но за что я по-настоящему люблю tracert — так это за те возможности исследования IP-сетей, которые он дает — а они бывают разные, по масштабам и по целенаправленности ;). Первым шагом может стать исследование подсети своего провайдера. С помощью traceroute ты можешь исследовать саму сети, применяя на практике полученные теоретические знания — о маршрутизации, серверах DNS, бэкбонах, системах подсетей, да мало ли о чем еще ;).

Как это работает?

Для начала нужно вспомнить формат заголовка IP-пакета, точнее одно из его полей — TTL (Time To Live). Это восьмибитное поле задает максимальное число хопов (hop — «прыжок» — прохождение дейтаграммы от одного маршрутизатора к другому) в течение которого пакет может находиться в сети. Каждый маршрутизатор,  обрабатывающий эту дейтаграмму, выполняет операцию TTL=TTL-1. Когда TTL становится равным нулю, маршрутизатор уничтожает пакет, отправителю высылается ICMP-сообщение Time Exceeded.

Утилита посылает в направлении заданного хоста пакет с TTL=1, и ждет, от кого вернется ответ time exceeded. Отвечающий записывается как первый хоп (результат первого шага на пути к цели). Затем посылаются последовательно пакеты с TTL=2, 3, 4 и т.д. по порядку, пока при некотором значении TTL пакет не достигнет цели и не получит от нее ответ.

*nix traceroute посылает в сторону заданного хоста UDP-пакеты на произвольный порт — скорее всего не занятый другим сервисом (например 28942, 30471) или на зарезервированный, например 0, умолчанию — 33434. Сначала посылается серия из 3-х таких пакетов с TTL=1, по приходу ответов замеряется время прохождения и определяется доменное имя транзитного узла (хотя это зависит от заданных опций). Затем, посылаются очередные серии пакетов с одинаковым TTL, предназначенных для выявления одного и того же хопа. В конце мы получаем от конечного хоста отклик port unreachable (порт недоступен), что означает завершение трассировки. Стандартный консольный Windows tracert работает точно также, но посылает только ICMP echo request пакеты.

Сам я охотно пользуюсь как стандартным tracert, так и вшитым в CyberKit (достаточно неплохой утилитой еще является Necrosoft Quick Traceroute). Под Линукс ничего дополнительного посоветовать не могу — юзал только стандартный Debian’овский traceroute :).

В заключение скажу, не бойся экспериментировать — только так можно по настоящему «понять» сеть. Ищи информацию и пользуйся ею. Удачи.

Leave a comment