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
    

    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.

    Спасибо за внимание!
    Поделиться публикацией

    Похожие публикации

    Комментарии 63

      +12
      мы отправляем udp фрагмент с порта 45000 ( к примеру) на порт 33434

      Может получится так, что порт назначения будет открыт. В данном случае сервер отправит на хост-инициатор например TCP ACK, что тоже будет являться триггером к окончанию трассировки.


      TCP ACK в ответ на UDP-пакет? Это какое-то новое слово в сетевых технологиях?
        +1
        Для трассировки может использоваться и udp пакеты и tcp-что в статье отражено. Если порт tcp открыт, то на tcp SYN мы.получим tcp ACK. Если udp порт открыт (к примеру 67), то мы получаем ответ сервера с ошибкой, так как 67 порт ждет dhcp discover. Помоему это само собой разумеется, не так?? Внес в статью корректировку что бы никто больше так, как вы не подумал.
          +3
          И давно у нас все UDP-сервисы обязательно отвечают отправителю?
            +1
            При использовании udp ответственность за предоставление ответа лежит на сервисе, который использует udp как транспорт. Если запрос попадет на открытый порт, утилита traceroute ответа скорее всего не получит.
              0
              Ваш вопрос меня заинтересовал, поэтому провел тест в лабе. Открыл 53 udp порт на сервере (DNS сервер) и попробовал сделать трассировку по UDP на 53 порт. В дампе ICMP-сообщение о том что порт не доступен, а от DNS-сервера — ошибка Malformed Packet.
                0
                ЕМНИП, если порт открыт но ничем не занят или правильно закрыт, то срабатывает REJECT (ICMP Port Unreachable). И это, вроде, даже в стандарте описано.
                  0
                  Это понятно, но в данном случае порт открыт и ждал запрос к службе dns. Dns ответил, что запрос не верный.
                    +1
                    Если на порту что-то слушает, то тут уж зависит от реализации.
            +1
            Спасибо за корректировку и внимательность.
              0
              Спасибо за статью. Всегда думал, что трассировка производится только с помощью ICMP Echo, а оказалось, что нынче такие хитрые технологии задействуются.

              А бывает такое, что путь пакета различается для разных протоколов (TCP, UDP, ICMP) или даже для разных портов?
                0
                Это уже PBR. Классифицируем пакеты по адресу/протоколу/порту и отправляем эти пакеты на отличный от остального трафика next-hop.
                  0
                  Интересная вещь, а она где-то реально используется?
                    +1
                    PBR/FBF используется, если надо выкручиваться с маршрутизацией. Но лучше избегать по возможности.
                      +2
                      Где вы живете, если первый раз слышите про Port-based NAT? :) При взгляде «снаружи» — «внутрь» именно так все и выглядит: разные маршруты для разных портов.
                        +1
                        Точно, затупил чего-то :)
                  +8
                  Надеюсь мы разобрались в работе данных утилит.

                  Да ладно Вам.
                  Простейшая трассировка:
                  # traceroute -n 8.8.8.8
                  traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
                  1 31.41.40.1 0.569 ms 0.476 ms 0.452 ms
                  2 10.52.12.1 0.463 ms 0.561 ms 0.514 ms
                  3 95.213.189.1 0.608 ms 0.549 ms 0.536 ms
                  4 195.208.208.232 1.539 ms 0.957 ms 1.587 ms
                  5 66.249.94.100 2.137 ms
                  66.249.94.94 2.101 ms 1.619 ms
                  6 66.249.95.241 25.756 ms
                  64.233.174.85 25.829 ms
                  209.85.243.149 22.934 ms
                  7 216.239.56.208 17.262 ms
                  216.239.40.240 16.171 ms
                  209.85.247.77 16.547 ms
                  8 * * *
                  9 8.8.8.8 14.459 ms 14.591 ms 13.890 ms

                  Откуда взялся серый адрес на втором хопе?
                  Почему на 5-6-7 ответы от нескольких ip?
                  Почему время ответов на 9-м шаге меньше чем на 6-м?
                  и т.д. и т.п.
                  О traceroute можно роман написать.

                  P.S.: ответы не требутся.
                    0
                    А позвольте узнать, как это понимать, что на одном хопе несколько ip?
                    Я сколько работаю с сетевым оборудованием — не сталкивался с таким выводом traceroute.
                    Везде был один ip на хопе.
                      0
                      Это может быть по разным причинам. Например роутер имеет несколько одинаковых по косту маршрутов и использует балансировку per-packet. Если у роутера будет например 4 пути, то может быть не два а три адреса на одном и то и же хопе.
                        0
                        Допустим такую ситуацию.

                        Отправляется пакетом с TTL=5.
                        По вашей трассировке пакет дойдёт до хоста, имеющий ip адреса 66.249.94.100 и 66.249.94.94. Этот роутер должен будет ответить одним пакетом с каким-то одним source ip (loopback или физический интерфейс, не суть). Используется балансировка трафика или нет, пакет пойдёт по какому-то одному пути.
                        Как в выводе на пятом хопе 2 ip светится?
                          +1
                          Это не один роутер, а два. Вы отправите пакет с ttl 5 и четвертый роутер балансируя попакетно трафик отправит пакеты двум роутерам (так как идет серия из трех пакетов), согласно его маршрутам. Те уже ответят, что Time Exceeded.
                            0
                            Прошу прощения, поторопился со своим последним вопросом. У вас отправляется по 3 запроса, а не по одному. Поэтому всё верно.
                            Благодарю за объяснение.
                      +1
                      Для особых нубов в сетях — почему 8 хоп пуст? Это значит, что он маршрутизирует, но не откликается сам на запросы?
                        +1
                        Это значит что icmp сообщение от данного хоста не получено.Скорее всего они запрещены на данном хосте администратором. Это бывает, ничего страшного в этом нет.
                          +1
                          На самом деле из наиболее заметного, если запрещен ICMP ответ Destination Unreachable с кодом 4 (Fragmentation Needed and Don't Fragment was Set) то может перестать работать TCP path MTU discovery что приводит к дропам TCP пакетов с MTU превышающим MTU на данном маршрутизаторе. Это было распространенной причиной странного поведения TCP в 1990-1998 годах, когда много серверов были за модемами.
                            +1
                            Также альтернативно может иметь место на прдыдущем hop уменьшение на 2 TTL в заголовке пакета и тихий локальный дроп его вследствии достижения 0. Хотя, конечно это много менее вероятный вариант.
                          0
                          Тут был вопрос, но уже понял, что всё есть по ссылке
                          https://habrahabr.ru/post/129627/
                            +2
                            Откуда взялся серый адрес на втором хопе?

                            Пирринг между хоп 1 и хоп 2, а также хоп 2 и хоп 3 может быть на серых адресах, никто не заставляет обязательно для пирринга использовать белые, ситуация часто встречается когда внутри одной сети несколько маршрутизаторов на разных уровнях, среди ISP — это вообще частая ситуация.
                            Почему на 5-6-7 ответы от нескольких ip?

                            Потому, что для 8.8.8.8 используется anycast и нормальная ситуация когда ответило несколько серверов с разных маршрутов, тут кто раньше ответил, того ответ и приняли.
                              +1
                              anycast работает не так. Каждый запрос «доходит» только до одного сервера.
                                0
                                имеется в виду, что маршруты могут быть разные (потому что «светятся» anycast адреса из многих сетей), а в промежутке оказалось, что какой-то маршрут лучше — и ушло по финальному
                                  0
                                  Так на каждом шаге отправляется по три пакета.
                                  В одном случае все три пришли на один роутер, а в другом случае три пакета разлетелись на три разных роутера.
                                    0
                                    Да, но при этом все зависит лишь от маршрутов. Нет никакого «кто раньше ответил, того ответ и приняли».
                                0
                                Anycast гуглового DNS всегда был шикарен
                                0
                                Ссылку внутри статьи посмотрите, там есть.ответы на ваши вопросы. Дублировать другие посты нет смысла да и цель статьи была не рассказать о всех нюансах данных утилит, которых очень много.
                                  –8
                                  Вы про какой traceroute говорите? Мой, линуксовый, умеет работать и по UDP, и по TCP, и по ICMP.
                                  -I, --icmp
                                  Use ICMP ECHO for probes

                                  -T, --tcp
                                  Use TCP SYN for probes
                                    +7
                                    Не понял вопроса если честно. Traceroute в линуксе не только у вас умеет и icmp, и tcp и udp. Это в статье отражено.
                                      –1
                                      Дело в том, что линуксоид man traceroute умеет, и про то, что там масса переключателей знает (на практике иногда мешаются к месту и ни к месту сетевые фильтры, поэтому знание — сила, иначе маршрут туманен. MS Windows изначально не имеет мощной встроенной поддержки сетей (до 1994 TCP/IP не поддерживался вовсе). Поэтому встроенный tracert такой простенький. Некоторые сетевые службы в весьма продвинутом в свое время MS Windows 2003 Server оказывались в работе хуже, а в настройке не проще, чем в любых тогдашних Linux/FreeBSD.
                                      Во времена MS Windows 2000 MS DNS был крайне сырой, что очень весело сказывалось на большом количестве запросов к корневым серверам.
                                    +2
                                    Извиняюсь за оффтоп: попробуйте traceroute к 162.252.205.157. Раньше такое срабатывало с 216.81.59.173 (Звездные войны и сетевые технологии).
                                      0
                                      Это из Dr. Horrible?
                                        0
                                        Кажется, да
                                      0
                                      В процессе трассировки номер порта назначения будет инкрементироваться при каждой попытке ( 33434, 33435 и т д)
                                      А это для чего?
                                        –4
                                        В статье совершена большая ошибка: стандартный traceroute unix использует протокол UDP по ограниченному диапазону портов. Более того, следующему пакету, вместе уменьшением TTL, traceroute будет выставлять другой порт UDP. Диапазон выбирался с точки зрения малоиспользуемости. Например, traceroute Cisco IOS вы никакие порты указать не сможете.
                                        Утилита, которой можно указать порты TCP или UDP занимается tcptraceroute. И изначально это было реализовано отдельной утилитой. Сейчас это функционал реализован во многих утилитах, которые занимаются трассировкой.
                                        И конечно, в traceroute можно указать использование ICMP для трассировки. Тогда он будет себя как tracert.
                                          +2
                                          Добрый день!

                                          По порядку разберем ваш комментарий.

                                          1.Ваша цитата:
                                          «В статье совершена большая ошибка: стандартный traceroute unix использует протокол UDP по ограниченному диапазону портов. Более того, следующему пакету, вместе уменьшением TTL, traceroute будет выставлять другой порт UDP. Диапазон выбирался с точки зрения малоиспользуемости.»

                                          В статье:
                                          «В процессе трассировки номер порта назначения будет инкрементироваться при каждой попытке ( 33434, 33435 и т д).»

                                          Это стандартное поведение утилиты без каки либо флагов и оно описано в статье. Что касается этого: «Диапазон выбирался с точки зрения малоиспользуемости.» — диапазон специально определен и начинается с порта 33434, количество используемых портов зависит от количества хопов при трассировке.

                                          2. Ваша цитата:
                                          «Например, traceroute Cisco IOS вы никакие порты указать не сможете.»

                                          Правда? Пора бы перейти на IOS 15 или XR:
                                          R1#traceroute 100.0.0.2 ?
                                            numeric  display numeric address
                                            port     specify port number
                                            probe    specify number of probes per hop
                                            source   specify source address or name
                                            timeout  specify time out
                                            ttl      specify minimum and maximum ttl
                                            <cr>
                                          


                                          3. Ваща цитата:
                                          «Утилита, которой можно указать порты TCP или UDP занимается tcptraceroute.»

                                          tcptraceroute это более расширенный инструмент, который умеет делать трассировку не только TCP SYN. Ну и на сколько мне известно, задать UDP как протокол в нем нельзя. Плюс к тому же tcptraceroute необходимо ставить отдельным пакетом, в то время как traceroute стандартная утлилита для любого unix-сервера.

                                          4. Ваша цитата:
                                          «И изначально это было реализовано отдельной утилитой. Сейчас это функционал реализован во многих утилитах, которые занимаются трассировкой.»

                                          То есть раньше traceroute не умел делать того, что умеет сейчас. Мы находимся в настоящем и говорим о том, что утилита может сейчас.

                                          5. Ваша цитата:
                                          «И конечно, в traceroute можно указать использование ICMP для трассировки. Тогда он будет себя как tracert»

                                          Это строка меня поразила. Вы точно прочитали статью?

                                          «Собственно говоря, утилита traceroute может работать как и утилита tracert с использованием ICMP Echo-Request. Для этого ее следует запустить с ключом -I.»
                                            0
                                            Утилита, которой можно указать порты TCP или UDP занимается tcptraceroute

                                            Возможность выбора диапазона портов была в первой же версии traceroute, по крайней мере во FreeBSD 1.0 уже присутствовала. Вот выбор протоколов появился только с FreeBSD 4.0.
                                            в то время как traceroute стандартная утлилита для любого unix-сервера

                                            Если правильно ошибаюсь, то в CentOS-7 её нет.
                                              –2
                                              Ну так CentOS не unix, CentOS — linux.
                                              –1
                                              Ещё раз: есть понятие стандартный traceroute unix-систем, который работает только по UDP, использует ограниченный диапазон портов UDP, и ждёт что порты там будут закрыты. Диапазон выбирался, в своё время, как малоиспользуемый. Поэтому у всех ОС, которые растут от всевозможных BSD и System 5 поведение этой команды именно такое.
                                              Трассировка TCP появилась не так уж давно (примерно с 2000), по сравнению с возрастом UNIX, и долгое время на windows подобного не было (кстати, вы точно уверены, что название tcptrace, а не tracetcp?). И вот все эти TCP плюшки — это traceroute, входящий в состав такой-то ОС. И по умолчанию утилита с функционалом tcp trace стала появляться в дистрибутивах LInux и UNIX не так уж давно(года с 2005, а у некоторых тру из тру помоему до сих пор нет).
                                              И вот именно поэтому traceroute Cisco IOS, который создавался как UNIX-like — ведёт себя именно так, а порт, который там задаётся — это порт UDP. TCP trace оно не умеет. Да наверно сетевому оборудованию и не к чему это.
                                              Всё что я хотел этим сказать, так только то, что не надо все варианты trace смешивать в один абзац, а всё же делать выделение UDP trace, потому что когда говорят «стандартный unix traceroute» имеют ввиду именно UDP trace c порта 33434. Когда говорят про «стандартный windows trace» имеют ввиду icmp trace.
                                              PS. А вообще, появление tcp traceroute, ИМХО вызвал массовый фаерволинг всего подряд, эпидемия которого и пошла с конца 90-х. Для того, чтобы понять, на каком хопе закрыли порт, нужен был инструмент. До этого момента, похоже об этом мало кто задумывался.
                                            0
                                            Я вот даже не пойму как мне относится к этой статье. С одной стороны вроде всё правильно написано, хоть тема и довольно известная, у меня даже в своё время сложилось мнение, что это один из самых распространённых вопросов на собеседованиях (был?).
                                            С другой, тема не раскрыта до конца и количество писем провайдерам с темой «я нашёл где у вас проблема» вырастет в разы…
                                            итак уже сылка https://habrahabr.ru/post/129627/ + «особое внимание обратите на 4й снизу абзац» забит шаблоном в почтовые клиенты техподдержки, достали их уже «полуумные» которые где-то что-то прочитали, но до конца не разобрались…
                                              0
                                              Техподдержка так отвечает только тем, кто действительно что то где то прочитал и думается теперь он самый умный.

                                              Дело в том, что что бы понять как работает эти утилиты на уровне сетевого специалиста нужно хотя бы изучить курс ccna, а лучше ccnp или jnsip-sp. Только тогда придет понимание.

                                              Цель статьи дать минимальные базовые знания и толчке к изучению,. Как уже кто то написал выше — про traceroute можно написать роман.
                                                0
                                                CCNA для более глубокого понимания. Возьмем ходовой Routing and Switching прослушать ICND1, ICND2, может еще сдать 200-120, чтобы уж наверняка? эдак 130 т р если найти недорого. Притом, что Cisco уже давно не является лидером в области сетей(хотя все еще так думает).

                                                А может таки RTFM вот отсюда. Первое описание traceroute от 1993 года, этот RFC естественно, не последний.

                                                Кстати, при всем уважении к учебным материалам Cisco (они реально хороши), там медицинский факт того, что не пропиеритарные вещи описаны в документах Request-For-Comments, которые опубликованы упомянут?
                                                  +2
                                                  А кто является лидером в области сетей?
                                                    0
                                                    Нужно определится с критериями, что определяет лидерство: прибыль за год, количество инноваций.
                                                    Есть, конечно, обзоры всяких там агентств.
                                                      0
                                                      количество инноваций
                                                        0
                                                        Тогда трудно ответить. Просто есть 2 варианта: 1. По вложениям в НИОКР. 2. По рекламируемым плюшкам.
                                                +1
                                                Небольшой оффтоп.
                                                сложилось мнение, что это один из самых распространённых вопросов на собеседованиях

                                                Напомнили вопросы на одном из собеседований (лет 10 назад, компания сейчас с Громким именем):
                                                1) кто автор утилиты traceroute?
                                                2) почему Ван выбрал порт 33434 (и как его легко запомнить)?
                                                Ответил на оба, но работать к ним не пошёл. Нахрена мне это знать как простому админу?
                                                0
                                                Хорошая статья. Заодно появились подозрения почему эти две команды у местами выдают разный результат.
                                                  0
                                                  А можно вопрос касательно темы маршрутизации? У нас была такая ситуация: мы в Москве, а сервера были в Праге, и иногда происходили сбои связи — потери пакетов, пинг увеличивался. В результате проверки маршрута провайдером, выяснили, что это происходит на участке сети в Германии. Я попросил изменить маршрут нашего провайдера — Глобустелеком, но они отказали — не имеют возможности. При этом другой провайдер в ДЦ, имея такие же проблемы, спокойно изменил маршрут. Почему один провайдер может менять маршрут, а другой — нет? Реально это так? От чего зависит?
                                                    0
                                                    От кучи вариантов начиная от того, сколько и каких каналов, как ходит трафик и в каких отношениях сетевой инженер состоит с сетевым инженером аплинка.
                                                    Иногда можно совершенно безболезненно пустить часть трафика в обход проблемного участка своими силами, иногда можно попросить сделать это аплинка просто написав знакомому в скайп «у нас вон там фигня, перекинь пожалуйста трафик», а иногда упираешься в корп. систему заявок и ответы типа «не имеем технической возможности» которые следует читать как «нам не выгодно гонять этот трафик по другому маршруту».
                                                      0
                                                      Провайдер может лишь выбрать следующую сеть в маршруте — или попросить следующую сеть поменять маршрут. Вполне может быть ситуация, когда у провайдера всего один аплинк — и выбирать не из чего. Или аплинков несколько — но потом все возможные маршруты все равно проходят через проблемного провайдера.

                                                      Возможны также технические проблемы с переключением маршрута (желанный вами вариант перегружен). Или экономические (желанный вами вариант слишком дорогой).

                                                      Наконец, не исключен вариант простой лени — ведь ваш договор с провайдером не предусматривает решения провайдером тех проблем, в возникновении которых он не виноват.
                                                      –2
                                                      Здравствуйте, нагуглить решения вопроса не удалось, спрошу здесь:
                                                      Я закрыл на своем сервере все порты кроме 80 и 22, через arno-iptables-firewall. После этого начал получать письма от Я.Метрики что с сайтами размещенными на этом сервере проблемы и они не доступны.

                                                      Описание проблемы: Закончилось время подключения к серверу

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


                                                      При этом сайты работают отлично, и нагрузки на сервере практически нет.
                                                      В чем может быть проблема? Может быть такое что Я.Метрика проверяет доступность не только по 80 порту, как тогда еще?
                                                      Кстати, сервер не пингуется, какой порт отвечает за прием и ответ icmp-запросов?
                                                      Буду благодарен за наводку.
                                                        +1
                                                        icmp — это отдельный протокол. Он не имеет никакого отношения к портам протокола TCP.
                                                          –1
                                                          Спасибо за развернутый ответ.
                                                          Перефразирую вопрос:
                                                          Если файрвол настроен на отбрасывание всех пакетов, кроме тех что приходят на 80 и 22 порт, при этом icmp-пакеты тоже отбрасываются, какое правило для IP-tables разрешит прием icmp-пакетов?
                                                            +2
                                                            Например такие, ну если нужны еще типы кроме 8 и 11 — добавьте по аналогии.
                                                            iptables -A INPUT -p ICMP --icmp-type 8 -j ACCEPT
                                                            iptables -A INPUT -p ICMP --icmp-type 11 -j ACCEPT
                                                            

                                                        0
                                                        что интересно, на некоторых дистрибутивах нет в комплекте Traceroute. Чем заменять?

                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                      Самое читаемое