Почему некоторые общие реализации traceroute по умолчанию используют UDP-зонды?

Недавно я устранил проблему мета-проблемы с подключением к сети, поскольку я знал, что данный пункт назначения доступен, но я не смог продемонстрировать это с помощью traceroute, потому что путь прошел холодно после определенного числа хмеля. Учитывая, что последний наблюдаемый прыжок был только выше по течению от узла, представляющего интерес, я принюхался по трафику, ожидая подтверждения того, что зонды достигли его и узнали, какое правило фильтрации блокирует их. Разумеется, я узнал, что пробники - это датаграммы UDP, предназначенные для высокого (и меняющегося) порта, который, конечно, был заблокирован для входящего трафика.

Это меня удивляет, потому что я предположил, что все теги traceroute по умолчанию будут ICMP, так как ответы ICMP. Я сделал обзор документации и обнаружил, что разные реализации делают разные варианты, а некоторые не позволяют пользователю делать выбор по умолчанию.

Реферат Метод зондирования Traceroute и прямой вывод IP-адреса поддерживает моя интуиция, что ICMP-зонды будут чаще достигать цели.

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

17 голосов | спросил neirbowj 9 J0000006Europe/Moscow 2014, 00:20:52

1 ответ


19

Первая версия traceroute была написана Ван Джекобсоном, и она использовала ICMP, но она не очень хорошо работала. Интерпретация поставщика ICMP в RFC792 заключалась в том, что маршрутизаторы не должны отправлять сообщение об ошибке ICMP в ответ на пакет ICMP (см. Примечания по редактированию ниже). Поэтому большинство маршрутизаторов не отправили сообщение с превышением времени в ответ на запрос эха с TTL 1 или 0. Поэтому он изменил его, чтобы использовать UDP, и вот, он отлично работал, и было много радости (и принятия). Инструмент traceroute для Linux и FreeBSD (и я предполагаю, что Cisco) основан на работе Ван Якобсона.

Затем спецификация была изменена на «в ответ на пакет ICMP error ». Мир прогрессировал, продавцы внесли изменения в свои стеки, позволяя сообщениям об ошибках ICMP в ответ на эхо-запросы, а также с ростом брандмауэров и списков ACL блуждающие UDP-пакеты иногда блокируются, но ICCH-эхо-запрос может пройти. Конечно, ваш успех на этом сегодня дико меняется. Я бы ожидал, что tracert и другие инструменты были написаны в то время, когда использование эхо-ответов ICMP было не так проблематично.

В наши дни вы не можете сказать, что UDP лучше, чем ICMP. Или что любой из них лучше TCP. Это полностью зависит от пути, по которому вы проходите, и политики безопасности. Возможно, вам придется попробовать одну, обе или все три реализации.

Источники:

http://ftp.arl.army.mil/~mike/ping.html http://www.inetdaemon.com/tutorials/troubleshooting/tools/traceroute/definition.shtml

Edit

Изменено RFC от IP (RFC791) до ICMP (RFC792), которое указано во вступлении:

  

Чтобы избежать бесконечного регресса сообщений о сообщениях и т. д., ICMP   сообщения отправляются по сообщениям ICMP.

Это бит, который заставил продавцов не отправлять ошибки «превышенного времени» для эхо-запросов.

RFC1122, Требования к интернет-хостам, в разделе 3.2.2. это обновление, в котором говорится, что хосты не должны отвечать на сообщения ICMP error .

ответил karyhead 9 J0000006Europe/Moscow 2014, 07:28:30

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132