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


18

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

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

Конспект зондового метода Traceroute и прямой путь вывода IP поддерживает свою интуицию , что ICMP зонды чаще успеха в достижении места назначения.

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

Ответы:


20

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

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

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

Источники:

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

Редактировать :

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

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

Именно из-за этого поставщики не отправляют ошибки «Превышено время» для эхо-запросов.

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


К вашему сведению, у вас достаточно репутации, чтобы оставлять комментарии по вопросу, который вы мне прислали
Майк Пеннингтон,

Отлично сработано. Особенно мне понравился рассказ в первой ссылке о компьютере, кричащем «Пинг! Пинг! Пинг!» на вершине его легких.
neirbowj

Майк, да, я начинаю
понимать,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.