Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
в линуксе кроме traceroute есть ещё утилита tracepath. В чём отличие? (кроме того, что traceroute требует права рута, а tracepath — нет)
traceroute не требует рутовых прав
Когда как :)
user@host:~$ traceroute www.ru -I
The specified type of tracerouting is allowed for superuser only
user@host:~$ traceroute www.ru -I
The specified type of tracerouting is allowed for superuser only
Судя по описанию http://www.opennet.ru/man.shtml?topic=tracepath&category=8&russian=0, её отличие в том что она не требует привилегий суперпользователя и не имеет расширенных настроек. И всё.
где вы такой traceroute нашли? Зайдите на любой обычный хостинг и попробуйте сделать traceroute если админ не слишком умный, то вы сделаете это без особых усилий.
man tracepath:
tracepath, tracepath6 — traces path to a network host discovering MTU along this path
Курсив мой. tracepath по умолчанию пытается определить mtu на каждом из линков пути. Трейсроут это тоже может, но со специальным ключом.
tracepath, tracepath6 — traces path to a network host discovering MTU along this path
Курсив мой. tracepath по умолчанию пытается определить mtu на каждом из линков пути. Трейсроут это тоже может, но со специальным ключом.
есть куда более информативный mtr
беими руками и ногами за mtr — статистика всегда решает…
Самый большой плюс — совмещение трэйса и пинга.
Заодно, если меняется один из узлов, то это отображается.
Заодно, если меняется один из узлов, то это отображается.
В Windows, кстати, есть аналог mtr — штатная утилита pathping, но она сбивается, если какой-то узел по маршруту на icmp не отвечает (упомянутые звездочки). Так что winmtr для этих целей намного лучше.
У traceroute много всяких различных опций, можно трассировать и UDP и TCP и ICMP и много чего еще.
А tracepath простой, но умеет показывать когда трафик предположительно идет не симметрично «asymm».
А tracepath простой, но умеет показывать когда трафик предположительно идет не симметрично «asymm».
Если кратко: вы не умеете читать вывод трейсроута. Даже не пытайтесь.
Только у меня ощущение что прочел много букв а в голове осталась только одны мысль?
В целом не без этого. Точнее, если лень всерьез разбираться, кто таки оно работает, то как минимум не нежно никому рассказывать, о том, что вы там прочли :)
Ну вы хотя бы объяснили про звёздочки =)
:) Звездочки в N-ной строчке — это отсутствие ответа на пакеты с TTL=n. По какой-то причине вам не хотят отвечать. Ничего криминального в этом нет. И в большинстве случаев это не имеет никакого отношения к работоспособности сервиса, который вы трейсите.
Делаете вы трейс на какой-нибудь www.ru. Перед веб-сервером наверняка стоит файрвол, который блокирет все, кроме tcp/80, tcp/443 и icmp echo-request. И правильно делает, что блокирует. Соответственно, UDP-трейс через такой файрвол не пролезет — вы увидите звездочки. При этом сам файрвол, если вы его потрейсите, вполне вероятно, вам ответит, а если сквозь него — на сервер, который за ним — может и не ответить (а может и ответить, но дальше не пустить — смотря как настроено, и какой файрвол). Если не ответит, то при трассировке сервера последним хопом в трейсе будет маршрутизатор перед файрволом.
Но ей-богу. Нормальному не то что пользователю, а даже и админу не слишком нужно об этом всем вообще думать. Больше проку будет. Я, собственно, об этом хотел сказать, а не подменять собой доку по трейсроуту :)
А уж если все-таки хочется знать ответы, то доклад Ричарда — это 54 слайда конскими буквами (по 10 строчек на слайд) с картинками и слайдами-заголовками.
Делаете вы трейс на какой-нибудь www.ru. Перед веб-сервером наверняка стоит файрвол, который блокирет все, кроме tcp/80, tcp/443 и icmp echo-request. И правильно делает, что блокирует. Соответственно, UDP-трейс через такой файрвол не пролезет — вы увидите звездочки. При этом сам файрвол, если вы его потрейсите, вполне вероятно, вам ответит, а если сквозь него — на сервер, который за ним — может и не ответить (а может и ответить, но дальше не пустить — смотря как настроено, и какой файрвол). Если не ответит, то при трассировке сервера последним хопом в трейсе будет маршрутизатор перед файрволом.
Но ей-богу. Нормальному не то что пользователю, а даже и админу не слишком нужно об этом всем вообще думать. Больше проку будет. Я, собственно, об этом хотел сказать, а не подменять собой доку по трейсроуту :)
А уж если все-таки хочется знать ответы, то доклад Ричарда — это 54 слайда конскими буквами (по 10 строчек на слайд) с картинками и слайдами-заголовками.
а я то ожидал в статье какой-то практической составляющей и надеялся подчерпнуть для себя что-то новое. Ладно, сольём доклад — почитаем на досуге.
не знаю про ответы, но я теперь боюсь использовать traceroute, вдруг что-то не правильно пойму и все — конец! =)
В докладе Ричарда.
А я не про ответы на вопросы, а про необходимость эти вопросы задавать. Не побоюсь этого слова, большинству пользователей не надо. Даже большинству админов не надо. Просто вот не надо и все — толку больше будет.
А я не про ответы на вопросы, а про необходимость эти вопросы задавать. Не побоюсь этого слова, большинству пользователей не надо. Даже большинству админов не надо. Просто вот не надо и все — толку больше будет.
Это конечно оффтоп, и выступлю в роли Кепа, но ИМХО простому юзеру, да и в 99% случаев админу mtr удобнее ;) единственно на линухе его часто ставить надо отдельно.
Но зато, иногда, с его помощью можно избежать некоторых проблем трейсроута.
Но зато, иногда, с его помощью можно избежать некоторых проблем трейсроута.
> Трейсроут трейсроуту рознь. Стандартные утилиты tracert в Windows и traceroute
> в Линукс реализованы по-разному и могут давать разные результаты.
> Windows посылает ICMP, а Linux — UDP
В Windows утилита tracert действительно использует только ICMP.
Но traceroute в *nix-системах (Linux, BSD, etc.) может использовать, как UDP, так и ICMP.
По умолчанию UDP, с ключиком -I будет использовать ICMP.
> в Линукс реализованы по-разному и могут давать разные результаты.
> Windows посылает ICMP, а Linux — UDP
В Windows утилита tracert действительно использует только ICMP.
Но traceroute в *nix-системах (Linux, BSD, etc.) может использовать, как UDP, так и ICMP.
По умолчанию UDP, с ключиком -I будет использовать ICMP.
Ни о чем… Только вопросов позадавали без ответов. Хотели дать ссылку на презентацию? Тогда и надо было ссылку делать. А в постах пишут ответы, а не вопросы.
Ссылку на эту статью мне только что скинул дежурный администратор Rascom. Смысл этого его действия и смысл этой статьи не в разжевывании ответов на поставленные вопросы. Правильно поставленные вопросы лучше ответов, так как ответы на них можно искать лично и в разных источниках, главное знать формулировку вопроса. С этим иногда больше проблем, чем с поиском ответов.
mtr действительно куда удобнее.
хотя бы тем, что не подвисает на неопределенное время в попытках отлукапить ptr полученного адреса, а продолжает трассировку. любителей делать traceroute -n (tracert -d) во внешние сети я никогда не понимал.
хотя бы тем, что не подвисает на неопределенное время в попытках отлукапить ptr полученного адреса, а продолжает трассировку. любителей делать traceroute -n (tracert -d) во внешние сети я никогда не понимал.
Честно говоря, я никогда не понимал любителей делать эту трассировку и без ключа -n/-d. Ну то есть понимал, конечно: круто почувствовать себя причастным к тайному знанию внутренней структуры интернета. Но если бы это простым любопытством и заканчивалось, то оно бы и ничего. Ну или стимулировало к дальнейшему его удовлетворению путем чтения книг. А то ведь увидел звездочки или задержку в 100 мс — и сразу какраул кричать :)
Никакой конкретики. Одна вода.
Трафик в интернете почти всегда идет разными путями в направлениях от клиента к серверу и от сервера к клиенту. Трейсроут же всегда показывает суммарную задержку в обе стороны, а трассировку — только по одному направлению.
Вот это действительно очень сложно для понимания неподготовленным то и дело можно слышать «да у вас там голден тупит», хотя на деле затык на обратке через рт )
В докладе два раза повторяется страница 42, странное совпадение.
Как то пост не о чём. Для приличия хоть бы pdf перевод сделали.
Если в кратце что не плохо знать
1) Routing on the Internet has no guarantee of symmetry.
Traceroute shows you only the forward path.
The reverse path is completely invisible to traceroute.
2) Все реализации traceroute полагаються на пакеты ICMP (тип 11), посылаемых отправителю.
а) Windows OS
tracert.exe
отправитель: отсылает 3 пакета ICMP-тип8 с TTL=1
--ответ от-- промежут. устр.: ICMP-тип11 с TTL=1
--ответ от-- цели: ICMP-тип0
PathPing.exe = combines ping and traceroute functionality.
б) FreeBSD, Linux & Cisco IOS
отправитель: отсылает (со случайные портов) UDP датаграммы на порты цели >=33434 с TTL=1 (следующий пакет — порт назначения увеличивается)
--ответ от-- промежут. устр.: ICMP-тип11 с TTL=1
--ответ от-- цели: ICMP-тип3 код 3 («destination unreachable,» «port unreachable»)
3)TCP is a poor choice for general use (frequently filtered), typically only seen as a method to work around specific firewalls.
и это есть гуд
C:\>tracert -w 100 www.microsoft.com
12 146 ms 126 ms 126 ms ge-0-0-0-0.ash-64cb-1a.ntwk.msn.net [207.46.43.2]
13 189 ms * 189 ms ge-0-1-0-0.co2-64c-1b.ntwk.msn.net [207.46.43.179]
14 191 ms 190 ms * xe-0-0-0-0.co2-96c-2b.ntwk.msn.net [207.46.43.69]
15 191 ms 191 ms * 207.46.40.242
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * ^C
C:\>tracetcp.exe www.microsoft.com
…
11 120 ms 120 ms 120 ms 207.46.43.44 [ge-3-0-0-0.nyc-64cb-1a.ntwk.msn.net]
12 128 ms 127 ms 127 ms 207.46.43.2 [ge-0-0-0-0.ash-64cb-1a.ntwk.msn.net]
13 190 ms 190 ms 189 ms 207.46.43.179 [ge-0-1-0-0.co2-64c-1b.ntwk.msn.net]
14 192 ms 191 ms 191 ms 207.46.43.69 [xe-0-0-0-0.co2-96c-2b.ntwk.msn.net]
15 190 ms 190 ms 191 ms 207.46.40.242
16 * * * Request timed out.
17 Destination Reached in 192 ms. Connection established to 65.55.12.249
1) Routing on the Internet has no guarantee of symmetry.
Traceroute shows you only the forward path.
The reverse path is completely invisible to traceroute.
2) Все реализации traceroute полагаються на пакеты ICMP (тип 11), посылаемых отправителю.
а) Windows OS
tracert.exe
отправитель: отсылает 3 пакета ICMP-тип8 с TTL=1
--ответ от-- промежут. устр.: ICMP-тип11 с TTL=1
--ответ от-- цели: ICMP-тип0
PathPing.exe = combines ping and traceroute functionality.
б) FreeBSD, Linux & Cisco IOS
отправитель: отсылает (со случайные портов) UDP датаграммы на порты цели >=33434 с TTL=1 (следующий пакет — порт назначения увеличивается)
--ответ от-- промежут. устр.: ICMP-тип11 с TTL=1
--ответ от-- цели: ICMP-тип3 код 3 («destination unreachable,» «port unreachable»)
3)
и это есть гуд
C:\>tracert -w 100 www.microsoft.com
12 146 ms 126 ms 126 ms ge-0-0-0-0.ash-64cb-1a.ntwk.msn.net [207.46.43.2]
13 189 ms * 189 ms ge-0-1-0-0.co2-64c-1b.ntwk.msn.net [207.46.43.179]
14 191 ms 190 ms * xe-0-0-0-0.co2-96c-2b.ntwk.msn.net [207.46.43.69]
15 191 ms 191 ms * 207.46.40.242
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * ^C
C:\>tracetcp.exe www.microsoft.com
…
11 120 ms 120 ms 120 ms 207.46.43.44 [ge-3-0-0-0.nyc-64cb-1a.ntwk.msn.net]
12 128 ms 127 ms 127 ms 207.46.43.2 [ge-0-0-0-0.ash-64cb-1a.ntwk.msn.net]
13 190 ms 190 ms 189 ms 207.46.43.179 [ge-0-1-0-0.co2-64c-1b.ntwk.msn.net]
14 192 ms 191 ms 191 ms 207.46.43.69 [xe-0-0-0-0.co2-96c-2b.ntwk.msn.net]
15 190 ms 190 ms 191 ms 207.46.40.242
16 * * * Request timed out.
17 Destination Reached in 192 ms. Connection established to 65.55.12.249
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Traceroute: про умение читать вывод