Комментарии 63
мы отправляем udp фрагмент с порта 45000 ( к примеру) на порт 33434
…
Может получится так, что порт назначения будет открыт. В данном случае сервер отправит на хост-инициатор например TCP ACK, что тоже будет являться триггером к окончанию трассировки.
TCP ACK в ответ на UDP-пакет? Это какое-то новое слово в сетевых технологиях?
Для трассировки может использоваться и udp пакеты и tcp-что в статье отражено. Если порт tcp открыт, то на tcp SYN мы.получим tcp ACK. Если udp порт открыт (к примеру 67), то мы получаем ответ сервера с ошибкой, так как 67 порт ждет dhcp discover. Помоему это само собой разумеется, не так?? Внес в статью корректировку что бы никто больше так, как вы не подумал.
И давно у нас все UDP-сервисы обязательно отвечают отправителю?
При использовании udp ответственность за предоставление ответа лежит на сервисе, который использует udp как транспорт. Если запрос попадет на открытый порт, утилита traceroute ответа скорее всего не получит.
Ваш вопрос меня заинтересовал, поэтому провел тест в лабе. Открыл 53 udp порт на сервере (DNS сервер) и попробовал сделать трассировку по UDP на 53 порт. В дампе ICMP-сообщение о том что порт не доступен, а от DNS-сервера — ошибка Malformed Packet.
ЕМНИП, если порт открыт но ничем не занят или правильно закрыт, то срабатывает REJECT (ICMP Port Unreachable). И это, вроде, даже в стандарте описано.
Спасибо за корректировку и внимательность.
Спасибо за статью. Всегда думал, что трассировка производится только с помощью ICMP Echo, а оказалось, что нынче такие хитрые технологии задействуются.
А бывает такое, что путь пакета различается для разных протоколов (TCP, UDP, ICMP) или даже для разных портов?
А бывает такое, что путь пакета различается для разных протоколов (TCP, UDP, ICMP) или даже для разных портов?
Надеюсь мы разобрались в работе данных утилит.
Да ладно Вам.
Простейшая трассировка:
# 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.: ответы не требутся.
А позвольте узнать, как это понимать, что на одном хопе несколько ip?
Я сколько работаю с сетевым оборудованием — не сталкивался с таким выводом traceroute.
Везде был один ip на хопе.
Я сколько работаю с сетевым оборудованием — не сталкивался с таким выводом traceroute.
Везде был один ip на хопе.
Это может быть по разным причинам. Например роутер имеет несколько одинаковых по косту маршрутов и использует балансировку per-packet. Если у роутера будет например 4 пути, то может быть не два а три адреса на одном и то и же хопе.
Допустим такую ситуацию.
Отправляется пакетом с TTL=5.
По вашей трассировке пакет дойдёт до хоста, имеющий ip адреса 66.249.94.100 и 66.249.94.94. Этот роутер должен будет ответить одним пакетом с каким-то одним source ip (loopback или физический интерфейс, не суть). Используется балансировка трафика или нет, пакет пойдёт по какому-то одному пути.
Как в выводе на пятом хопе 2 ip светится?
Отправляется пакетом с TTL=5.
По вашей трассировке пакет дойдёт до хоста, имеющий ip адреса 66.249.94.100 и 66.249.94.94. Этот роутер должен будет ответить одним пакетом с каким-то одним source ip (loopback или физический интерфейс, не суть). Используется балансировка трафика или нет, пакет пойдёт по какому-то одному пути.
Как в выводе на пятом хопе 2 ip светится?
Для особых нубов в сетях — почему 8 хоп пуст? Это значит, что он маршрутизирует, но не откликается сам на запросы?
Это значит что icmp сообщение от данного хоста не получено.Скорее всего они запрещены на данном хосте администратором. Это бывает, ничего страшного в этом нет.
На самом деле из наиболее заметного, если запрещен ICMP ответ Destination Unreachable с кодом 4 (Fragmentation Needed and Don't Fragment was Set) то может перестать работать TCP path MTU discovery что приводит к дропам TCP пакетов с MTU превышающим MTU на данном маршрутизаторе. Это было распространенной причиной странного поведения TCP в 1990-1998 годах, когда много серверов были за модемами.
Также альтернативно может иметь место на прдыдущем hop уменьшение на 2 TTL в заголовке пакета и тихий локальный дроп его вследствии достижения 0. Хотя, конечно это много менее вероятный вариант.
Тут был вопрос, но уже понял, что всё есть по ссылке
https://habrahabr.ru/post/129627/
https://habrahabr.ru/post/129627/
Откуда взялся серый адрес на втором хопе?
Пирринг между хоп 1 и хоп 2, а также хоп 2 и хоп 3 может быть на серых адресах, никто не заставляет обязательно для пирринга использовать белые, ситуация часто встречается когда внутри одной сети несколько маршрутизаторов на разных уровнях, среди ISP — это вообще частая ситуация.
Почему на 5-6-7 ответы от нескольких ip?
Потому, что для 8.8.8.8 используется anycast и нормальная ситуация когда ответило несколько серверов с разных маршрутов, тут кто раньше ответил, того ответ и приняли.
anycast работает не так. Каждый запрос «доходит» только до одного сервера.
имеется в виду, что маршруты могут быть разные (потому что «светятся» anycast адреса из многих сетей), а в промежутке оказалось, что какой-то маршрут лучше — и ушло по финальному
Так на каждом шаге отправляется по три пакета.
В одном случае все три пришли на один роутер, а в другом случае три пакета разлетелись на три разных роутера.
В одном случае все три пришли на один роутер, а в другом случае три пакета разлетелись на три разных роутера.
Anycast гуглового DNS всегда был шикарен
Ссылку внутри статьи посмотрите, там есть.ответы на ваши вопросы. Дублировать другие посты нет смысла да и цель статьи была не рассказать о всех нюансах данных утилит, которых очень много.
Вы про какой traceroute говорите? Мой, линуксовый, умеет работать и по UDP, и по TCP, и по ICMP.
-I, --icmp
Use ICMP ECHO for probes
-T, --tcp
Use TCP SYN for probes
НЛО прилетело и опубликовало эту надпись здесь
В процессе трассировки номер порта назначения будет инкрементироваться при каждой попытке ( 33434, 33435 и т д)А это для чего?
В статье совершена большая ошибка: стандартный traceroute unix использует протокол UDP по ограниченному диапазону портов. Более того, следующему пакету, вместе уменьшением TTL, traceroute будет выставлять другой порт UDP. Диапазон выбирался с точки зрения малоиспользуемости. Например, traceroute Cisco IOS вы никакие порты указать не сможете.
Утилита, которой можно указать порты TCP или UDP занимается tcptraceroute. И изначально это было реализовано отдельной утилитой. Сейчас это функционал реализован во многих утилитах, которые занимаются трассировкой.
И конечно, в traceroute можно указать использование ICMP для трассировки. Тогда он будет себя как tracert.
Утилита, которой можно указать порты TCP или UDP занимается tcptraceroute. И изначально это было реализовано отдельной утилитой. Сейчас это функционал реализован во многих утилитах, которые занимаются трассировкой.
И конечно, в traceroute можно указать использование ICMP для трассировки. Тогда он будет себя как tracert.
Добрый день!
По порядку разберем ваш комментарий.
1.Ваша цитата:
«В статье совершена большая ошибка: стандартный traceroute unix использует протокол UDP по ограниченному диапазону портов. Более того, следующему пакету, вместе уменьшением TTL, traceroute будет выставлять другой порт UDP. Диапазон выбирался с точки зрения малоиспользуемости.»
В статье:
«В процессе трассировки номер порта назначения будет инкрементироваться при каждой попытке ( 33434, 33435 и т д).»
Это стандартное поведение утилиты без каки либо флагов и оно описано в статье. Что касается этого: «Диапазон выбирался с точки зрения малоиспользуемости.» — диапазон специально определен и начинается с порта 33434, количество используемых портов зависит от количества хопов при трассировке.
2. Ваша цитата:
«Например, traceroute Cisco IOS вы никакие порты указать не сможете.»
Правда? Пора бы перейти на IOS 15 или XR:
3. Ваща цитата:
«Утилита, которой можно указать порты TCP или UDP занимается tcptraceroute.»
tcptraceroute это более расширенный инструмент, который умеет делать трассировку не только TCP SYN. Ну и на сколько мне известно, задать UDP как протокол в нем нельзя. Плюс к тому же tcptraceroute необходимо ставить отдельным пакетом, в то время как traceroute стандартная утлилита для любого unix-сервера.
4. Ваша цитата:
«И изначально это было реализовано отдельной утилитой. Сейчас это функционал реализован во многих утилитах, которые занимаются трассировкой.»
То есть раньше traceroute не умел делать того, что умеет сейчас. Мы находимся в настоящем и говорим о том, что утилита может сейчас.
5. Ваша цитата:
«И конечно, в traceroute можно указать использование ICMP для трассировки. Тогда он будет себя как tracert»
Это строка меня поразила. Вы точно прочитали статью?
«Собственно говоря, утилита traceroute может работать как и утилита tracert с использованием ICMP Echo-Request. Для этого ее следует запустить с ключом -I.»
По порядку разберем ваш комментарий.
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.»
Утилита, которой можно указать порты TCP или UDP занимается tcptraceroute
Возможность выбора диапазона портов была в первой же версии traceroute, по крайней мере во FreeBSD 1.0 уже присутствовала. Вот выбор протоколов появился только с FreeBSD 4.0.
в то время как traceroute стандартная утлилита для любого unix-сервера
Если правильно ошибаюсь, то в CentOS-7 её нет.
Ещё раз: есть понятие стандартный 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-х. Для того, чтобы понять, на каком хопе закрыли порт, нужен был инструмент. До этого момента, похоже об этом мало кто задумывался.
Трассировка 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-х. Для того, чтобы понять, на каком хопе закрыли порт, нужен был инструмент. До этого момента, похоже об этом мало кто задумывался.
Я вот даже не пойму как мне относится к этой статье. С одной стороны вроде всё правильно написано, хоть тема и довольно известная, у меня даже в своё время сложилось мнение, что это один из самых распространённых вопросов на собеседованиях (был?).
С другой, тема не раскрыта до конца и количество писем провайдерам с темой «я нашёл где у вас проблема» вырастет в разы…
итак уже сылка https://habrahabr.ru/post/129627/ + «особое внимание обратите на 4й снизу абзац» забит шаблоном в почтовые клиенты техподдержки, достали их уже «полуумные» которые где-то что-то прочитали, но до конца не разобрались…
С другой, тема не раскрыта до конца и количество писем провайдерам с темой «я нашёл где у вас проблема» вырастет в разы…
итак уже сылка https://habrahabr.ru/post/129627/ + «особое внимание обратите на 4й снизу абзац» забит шаблоном в почтовые клиенты техподдержки, достали их уже «полуумные» которые где-то что-то прочитали, но до конца не разобрались…
Техподдержка так отвечает только тем, кто действительно что то где то прочитал и думается теперь он самый умный.
Дело в том, что что бы понять как работает эти утилиты на уровне сетевого специалиста нужно хотя бы изучить курс ccna, а лучше ccnp или jnsip-sp. Только тогда придет понимание.
Цель статьи дать минимальные базовые знания и толчке к изучению,. Как уже кто то написал выше — про traceroute можно написать роман.
Дело в том, что что бы понять как работает эти утилиты на уровне сетевого специалиста нужно хотя бы изучить курс ccna, а лучше ccnp или jnsip-sp. Только тогда придет понимание.
Цель статьи дать минимальные базовые знания и толчке к изучению,. Как уже кто то написал выше — про traceroute можно написать роман.
Небольшой оффтоп.
Напомнили вопросы на одном из собеседований (лет 10 назад, компания сейчас с Громким именем):
1) кто автор утилиты traceroute?
2) почему Ван выбрал порт 33434 (и как его легко запомнить)?
Ответил на оба, но работать к ним не пошёл. Нахрена мне это знать как простому админу?
сложилось мнение, что это один из самых распространённых вопросов на собеседованиях
Напомнили вопросы на одном из собеседований (лет 10 назад, компания сейчас с Громким именем):
1) кто автор утилиты traceroute?
2) почему Ван выбрал порт 33434 (и как его легко запомнить)?
Ответил на оба, но работать к ним не пошёл. Нахрена мне это знать как простому админу?
Хорошая статья. Заодно появились подозрения почему эти две команды у местами выдают разный результат.
А можно вопрос касательно темы маршрутизации? У нас была такая ситуация: мы в Москве, а сервера были в Праге, и иногда происходили сбои связи — потери пакетов, пинг увеличивался. В результате проверки маршрута провайдером, выяснили, что это происходит на участке сети в Германии. Я попросил изменить маршрут нашего провайдера — Глобустелеком, но они отказали — не имеют возможности. При этом другой провайдер в ДЦ, имея такие же проблемы, спокойно изменил маршрут. Почему один провайдер может менять маршрут, а другой — нет? Реально это так? От чего зависит?
От кучи вариантов начиная от того, сколько и каких каналов, как ходит трафик и в каких отношениях сетевой инженер состоит с сетевым инженером аплинка.
Иногда можно совершенно безболезненно пустить часть трафика в обход проблемного участка своими силами, иногда можно попросить сделать это аплинка просто написав знакомому в скайп «у нас вон там фигня, перекинь пожалуйста трафик», а иногда упираешься в корп. систему заявок и ответы типа «не имеем технической возможности» которые следует читать как «нам не выгодно гонять этот трафик по другому маршруту».
Иногда можно совершенно безболезненно пустить часть трафика в обход проблемного участка своими силами, иногда можно попросить сделать это аплинка просто написав знакомому в скайп «у нас вон там фигня, перекинь пожалуйста трафик», а иногда упираешься в корп. систему заявок и ответы типа «не имеем технической возможности» которые следует читать как «нам не выгодно гонять этот трафик по другому маршруту».
Провайдер может лишь выбрать следующую сеть в маршруте — или попросить следующую сеть поменять маршрут. Вполне может быть ситуация, когда у провайдера всего один аплинк — и выбирать не из чего. Или аплинков несколько — но потом все возможные маршруты все равно проходят через проблемного провайдера.
Возможны также технические проблемы с переключением маршрута (желанный вами вариант перегружен). Или экономические (желанный вами вариант слишком дорогой).
Наконец, не исключен вариант простой лени — ведь ваш договор с провайдером не предусматривает решения провайдером тех проблем, в возникновении которых он не виноват.
Возможны также технические проблемы с переключением маршрута (желанный вами вариант перегружен). Или экономические (желанный вами вариант слишком дорогой).
Наконец, не исключен вариант простой лени — ведь ваш договор с провайдером не предусматривает решения провайдером тех проблем, в возникновении которых он не виноват.
Здравствуйте, нагуглить решения вопроса не удалось, спрошу здесь:
Я закрыл на своем сервере все порты кроме 80 и 22, через arno-iptables-firewall. После этого начал получать письма от Я.Метрики что с сайтами размещенными на этом сервере проблемы и они не доступны.
При этом сайты работают отлично, и нагрузки на сервере практически нет.
В чем может быть проблема? Может быть такое что Я.Метрика проверяет доступность не только по 80 порту, как тогда еще?
Кстати, сервер не пингуется, какой порт отвечает за прием и ответ icmp-запросов?
Буду благодарен за наводку.
Я закрыл на своем сервере все порты кроме 80 и 22, через arno-iptables-firewall. После этого начал получать письма от Я.Метрики что с сайтами размещенными на этом сервере проблемы и они не доступны.
Описание проблемы: Закончилось время подключения к серверу
Возможные причины проблемы: Сервер, на котором находится сайт, перегружено или на нем неправильно сконфигурирован файрвол
При этом сайты работают отлично, и нагрузки на сервере практически нет.
В чем может быть проблема? Может быть такое что Я.Метрика проверяет доступность не только по 80 порту, как тогда еще?
Кстати, сервер не пингуется, какой порт отвечает за прием и ответ icmp-запросов?
Буду благодарен за наводку.
icmp — это отдельный протокол. Он не имеет никакого отношения к портам протокола TCP.
что интересно, на некоторых дистрибутивах нет в комплекте Traceroute. Чем заменять?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Tracert vs Traceroute