3

На странице man для traceroute говорится:«traceroute отслеживает пакеты маршрутов, полученные из IP-сети на пути к данному хосту». , но во время исследования по этой теме я не смог найти статистических данных / научных работ о том, насколько точен Traceroute на самом деле, как то, является ли отображаемый маршрут фактически выбранным маршрутом (возможно, разные пакеты используют совершенно разные маршруты) и какова ошибка margin и, возможно ли это, из-за разных протоколов маршрутизации, ping Traceroute может отображать совершенно другой путь, чем последующий запрос TCP, или даже фактические пакеты ping будут принимать.

Единственная найденная мною работа, подразумевающая, что трассировка Ping может быть неидеальной, - это документация по scamper, в которой говорится:«ping полезен для измерения сквозных задержек и потерь, поиска ответных IP-адресов и классификации поведения хостов по исследуя, как они реагируют на зонды ". и (насколько я понял) использует трассировку MDA для обнаружения пути. Следовательно, подразумевается, что использование PING может не дать желаемого результата.

Поэтому мой вопрос: насколько надежно обнаружение пути с использованием Traceroute (и почему)? Я был бы очень признателен за ссылки на детали по этой теме, но также было бы достаточно общего объяснения, почему или нет.

1 ответ1

3

Самое важное, что нужно помнить, это то, что маршруты не являются статичными. По замыслу, маршруты в общедоступном интернете постоянно меняются. Иногда маршруты меняются из-за балансировки нагрузки; иногда они меняются, потому что узел выходит из строя; иногда они меняются, потому что маршрутизаторы решают буквально наугад изменить правила маршрутизации (просто чтобы встряхнуть).

С точки зрения конечного пользователя, который не имеет доступа на уровне системного администратора к каждому промежуточному маршрутизатору и интернет-концентратору между источником и назначением пакета, вы должны рассматривать его как принцип неопределенности Гейзенберга.

Что нужно учитывать:

  1. Исходя из объявленного IP-адреса "назначения" в вашем пакете, промежуточные маршрутизаторы могут решить направить вас по-другому. Поэтому, если трассировка маршрута является попыткой последовательно сопоставить маршрутизаторы между источником и назначением, трассировка маршрута может быть отклонена от курса, если маршруты выберут разные пути в зависимости от того, к какому узлу вы пытаетесь добраться.

  2. Не все маршрутизаторы будут прослушивать пинг ICMP или UDP. Они могут молча игнорировать этот трафик и просто отбросить его на сетевой карте (часто для борьбы с DDoS). Это может сорвать вашу попытку составить карту маршрута.

  3. Даже если вы успешно сопоставили маршрут, и все промежуточные узлы отвечают на ваши эхо-запросы и не пытаются воспроизвести вашу попытку сопоставления, маршрут может измениться для следующих пакетов, которые вы отправляете, используя какой-то "настоящий" протокол (или даже если вы пытаетесь трассировка во второй раз).

  4. QoS может заставить сети с нормальным поведением маршрутизировать трафик по-разному. Например, VoIP или потоковое видео могут проходить по одному пути, в то время как при обычном просмотре веб-страниц - по другому.

  5. Тип трафика может стать причиной различий в маршрутизации. Например, даже без учета QoS вы можете получить другой путь для FTP, чем для SSH. Промежуточные узлы могут проявлять любую свободу действий (от абсолютно случайного выбора маршрутов, до злонамеренной попытки замедлить ваш трафик, до честной попытки ускорить ваше соединение путем маршрутизации к узлу с наименьшей нагрузкой) при определении того, где направлять ваш трафик с каждого прыжка.

  6. Теоретически, промежуточные маршрутизаторы также могут, если они того пожелают, превратить вашу попытку traceroute в бесконечный цикл: узел A указывает на узел B, узел B указывает на узел C, а узел C указывает на узел A. Ничто не останавливает Маршрутизаторы делают это (я не уверен, почему они выбрали бы это, но это возможно) для пакетов, обнаруженных как "трассировки" (ICMP или UDP-пинги). Это может сделать это, чтобы попытаться сорвать ваши усилия, или по любой другой причине.

Алгоритм обнаружения нескольких путей полезен, но он не может преодолеть эти теоретические ограничения.

В основном, чтобы определить путь, вы должны отправить один или несколько пакетов. Эти пакеты могут быть направлены любым способом, который промежуточные узлы сочтут нужным. Но как только вы отправляете другой пакет, маршрутизаторы не могут помешать изменению пути. Это своего рода сетевая аналогия принципа неопределенности Гейзенберга.

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

С другой стороны, если все участвующие узлы принадлежат вам, вы, как администратор, можете контролировать точное поведение каждого узла. Например, вы можете включить ICMP и настроить статические маршруты (маршруты, которые не меняются). Тогда вы можете быть уверены, что ваша трассировка верна. Но если вы поставите балансировщик нагрузки посередине, то вы должны будете знать о поведении балансировщика нагрузки и о том, как он может переключать маршруты в значительной степени по мере необходимости (хотя обычно он не является случайным и обычно не пытается намеренно тебя обманывают).

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .