Tracert vs Traceroute
В чем отличие маршрута пакета от его пути?
Стандартный механизм маршрутизации пакетов в интернете — 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 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.
Трассировка до сервера
Трассировка – это проверка доставки пакетов данных по маршруту до удаленного сервера. Такой способ диагностики позволяет выявить проблемный участок сети, где возникают потери сетевых пакетов. Делается это всегда в тот момент, когда наблюдаются проблемы.
Трассировку можно выполнять с помощью команд traceroute (для Linux) и tracert (для Windows). Более информативный способ – посредством специального программного обеспечения, например, MTR.
При наличии проблем в доступности сервера или сайта трассировку нужно выполнять именно с проблемного устройства – онлайн сервисы в этом случае не подойдут.
Принцип работы системных утилит tracert и traceroute
Когда пользователь открывает какой-либо сайт, браузер обращается с запросом к серверу, на котором этот сайт расположен. Запрос идет через маршрутизаторы, которые называют узлами или хопами (hop – прыжок). Команды tracert и traceroute позволяют узнать, через сколько узлов пройдет запрос, пока достигнет целевого адресата.
Утилиты создают пакет, предназначенный для целевого узла и отправляют через маршрутизаторы – транзитные, то есть нецелевые узлы. В заголовке передаваемого пакета есть специальное поле TTL, переводится как «время жизни».
Это поле определяет количество узлов, проходимых пакетом. На каждом узле от заданного количества TTL отнимается одна жизнь. Если в процессе маршрута значение TTL станет равно 0, маршрутизатор отбросит пакет и вернет отправителю сообщение об ошибке «Time Exceeded».
Диагностика с помощью команд
Чтобы выполнить трассировку пути в Windows и проверить подключение к серверу с помощью команды tracert:
- Нажмите Win+R, либо «Выполнить».
- В открывшееся окошко, введите команду «cmd».
- Нажмите «ОК».
- В командную строку впишите tracert и через пробел – нужный сервер, домен или IP-адрес.
- Нажмите «Enter».
В нашем примере запрос прошел через 13 транзитных узлов, чтобы дойти до целевого – yandex.ru.
В Linux трассировка делается по такому же принципу, но с применением команды traceroute.
Расширенная диагностика с помощью программы MTR
Трассирование посредством программы MTR дает более полное представление о проблеме, особенно когда она плавающая, поскольку выполняется непрерывно. То есть, если утилиты tracert / traceroute отправляют определенное количество пакетов, то MTR будет проводить диагностику столько времени, сколько потребуется.
Скачайте программу WinMTR для Windows по ссылке с Github: https://github.com/White-Tiger/WinMTR/releases, выбрав архив WinMTR-v100-static.zip. Чтобы начать диагностику:
- Распакуйте архив и запустите файл WinMTR.exe.
- Вверху в поле «Host» введите имя сервера, домен или IP-адрес.
- Нажмите «Start».
Теперь подождите около минуты, пока данные будут собраны. Если проблема непостоянная — дождитесь, пока она появится, соберите данные около минуты и остановите диагностику. Скриншот с результатом отправьте в поддержку.
Для Linux есть аналог программы MTR, его можно установить из пакетного менеджера операционной системы.