TRACEROUTE

Программа Traceroute, написанная Van Jacobson, - отладочное средство, которое позволяет лучше понять устройство протоколов TCP/IP. Обычно две последовательные датаграммы отправленные от одного и того же источника к одному и тому же пункту назначения проходят по одному и тому же маршруту, однако гарантировать этого невозможно. Traceroute позволяет нам посмотреть маршрут, по которому двигаются IP датаграммы от одного хоста к другому. С помощью Traceroute можно воспользоваться IP опцией маршрутизации от источника.

Функционирование программы Traceroute Уже описана IP опция записи маршрута(например, программа ping). Тогда возникает вопрос: «Зачем писать новое приложение?» Есть три причины. Во-первых, исторически не все маршрутизаторы поддерживают опцию записи маршрута, из чего следует, что некоторые маршруты становятся неиспользуемыми. (Traceroute не требует каких-либо специальных характеристик на промежуточных маршрутизаторах). Во-вторых, запись маршрута обычно осуществляется в одном направлении. Отправитель включает опцию, а получатель должен вставить все значения из принятого IP заголовка и каким-либо образом вернуть их отправителю. Traceroute требует только того, чтобы на пункте назначения присутствовал работающий UDP модуль – никаких специальных серверных приложений не требуется.

Третья и основная причина заключается в том, что размер, предоставляемый для опций в IP заголовке, недостаточен для того, чтобы обработать большинство маршрутов. В поле опций IP заголовка входит всего 9 IP адресов. На сегодняшний день этого слишком мало. Traceroute использует ICMP и поле TTL в IP заголовке. Поле TTL (время жизни) это 8-битное поле, которое отправитель устанавливает в какое-либо значение. Рекомендуемое исходное значение указано в Assigned Numbers RFC и в настоящее время равно 64. Каждый маршрутизатор, который обрабатывает датаграмму, уменьшает значение TTL на единицу или на количество секунд, в течение которых маршрутизатор обрабатывал датаграмму. Так как большинство маршрутизаторов задерживает датаграмму меньше чем секунду, поле TTL, как правило, уменьшается на единицу и довольно точно соответствует количеству пересылок.

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

Когда маршрутизатор получает IP датаграмму с TTL равным либо 0, либо 1, он не должен отправлять эту датаграмму дальше. (Хост приемник должен доставить подобную датаграмму в приложение, так как датаграмма не может быть смаршрутизировна. Как правило, системы не должны получать датаграммы с TTL равным 0.) Если такую датаграмму получает маршрутизатор, он уничтожает ее и посылает хосту, который ее отправил ICMP сообщение "время истекло" (time exceeded). Принцип работы Traceroute заключается в том, что IP датаграмма, содержащая это ICMP сообщение, имеет в качестве адреса источника IP адрес маршрутизатора.

Теперь мы можем понять, как работает Traceroute. На хост назначения отправляется IP датаграмма с TTL, установленным в единицу. Первый маршрутизатор, который должен обработать датаграмму, уничтожает ее (так как TTL равно 1) и отправляет ICMP сообщение об истечении времени. Таким образом, определяется первый маршрутизатор в маршруте. Затем Traceroute отправляет датаграмму с TTL равным 2, что позволяет получить IP адрес второго маршрутизатора. Это продолжается до тех пор, пока датаграмма не достигнет хоста назначения. Однако, если датаграмма прибыла именно на хост назначения, он не уничтожит ее и не сгенерирует ICMP сообщение об истечении времени, так как датаграмма достигла своего конечного назначения. Как можно определить, что датаграмма достигла конечного пункта назначения?

В UDP датаграммах, которые посылает Traceroute, устанавливается несуществующий номер UDP порта (больше чем 30000), что делает невозможным обработку этой датаграммы каким-либо приложением. Поэтому, когда прибывает подобная датаграмма, UDP модуль хоста назначения генерирует ICMP сообщение "порт недоступен" (port unreachable). В этом случае Traceroute необходимо определить тип принятого ICMP сообщения - либо об истечении времени, либо о недоступности порта. Именно таким образом мы узнаем, доставлена ли датаграмма в пункт назначения.

Работа в локальной сети Запустим traceroute. Пройдем по маршруту от svr4 к slip через маршрутизатор bsdi. Выделенный SLIP канал между bsdi и slip имеет скорость 9000 бит/с. svr4 % traceroute slip traceroute to slip ( ), 30 hops max, 40 byte packets 1 bsdi ( ) 20 ms 10 ms 10 ms 2 slip ( ) 120 ms 120 ms 120 ms Первая строка, без номера, содержит имя и IP адрес пункта назначения и указывает на то, что величина TTL не может быть больше 30. Размер датаграммы установлен в 40 байт, из которых 20 байт отводится на IP заголовок, 8 байт на UDP заголовок и 12 байт на пользовательские данные. (В 12 байтах пользовательских данных содержится номер последовательности, который увеличивается на единицу при отправке каждой следующей датаграммы, копия исходящего TTL и время, когда датаграмма была отправлена.)

Следующие две строки вывода начинаются с TTL, после чего следует имя хоста или маршрутизатора и их IP адреса. Для каждого значения TTL отправляются 3 датаграммы. Для каждого возвращенного ICMP сообщения рассчитывается и печатается время возврата (round-trip). Если ответ не получен в течение пяти секунд на любую из трех датаграмм, печатается звездочка, после чего отправляется следующая датаграмма. В нашем примере первые три датаграммы имели TTL, установленный в единицу, а ICMP сообщения вернулись через 20, 10 и 10 миллисекунд. Следующие три датаграммы были отправлены с TTL равным 2, а ICMP сообщения вернулись с задержкой 120 миллисекунд. Так как TTL со значением 2 достигло конечного пункта назначения, программа прекратила свою работу. Время возврата (round-trip) рассчитывается программой traceroute на хосте отправителе. Оно представляет из себя полное время возврата от программы traceroute к маршрутизатору. Если необходимо рассчитать время, затраченное на каждую пересылку, мы должны вычесть значение, полученное как TTL N, из значения, полученного как TTL N+1.

1 0.0 arp who-has bsdi tell svr (0.0006) arp reply bsdi is-at 0:0:c0:6f:2d: (0.0025) svr >slip.33435: udp 12 [ttl 1] (0.0013) bsdi>svr4: icmp: time exceeded in-transit (0.0655) svr >slip.33436: udp 12 [ttl 1] (0.0013) bsdi>svr4: icmp: time exceeded in-transit (0.0140) svr >slip.33437: udp 12 [ttl 1] (0.0012) bsdi>svr4: icmp: time exceeded in-transit (0.0322) svr >slip.33438: udp (0.1079) slip>svr4: icmp: slip udp port unreachable (0.0608) svr >slip.33439: udp (0.1079) slip>svr4: icmp: slip udp port unreachable (0.0143) svr >slip.33440: udp (0.1079) slip>svr4: icmp: slip udp port unreachable Рис.1. Вывод tcpdump для примера traceroute от svr4 к slip Строки с 9-й по 14-ю соответствуют трем датаграммам, которые посылаются с TTL равным 2. Они достигают конечного пункта назначения, при этом генерируется ICMP сообщение о недоступности порта.

То что первый пробный пакет к bsdi имел RTT равное 20 млс, а следующие два имели RTT равное 10 млс объясняется тем, что был осуществлен ARP обмен. Значение, которое выбирается как номер UDP порта назначения, начинается с величины и увеличивается на единицу каждый раз, когда отправляется следующая датаграмма. Номер порта может быть изменен с использованием опции командной строки. UDP датаграмма содержит 12 байт пользовательских данных, в том случае, если в выводе traceroute отправляются датаграммы размером в 40 байт. Когда IP датаграмма имеет TTL равное единице, tcpdump печатает комментарий [ttl 1]. Подобное сообщение печатается, когда TTL равно 0 или 1, чтобы предупредить нас о том, что в датаграмме что-то не в порядке. В данном случае мы ожидаем увидеть TTL равное 1, однако некоторые другие приложения получат предупреждение о том, что датаграмма скорее всего не достигла своего конечного пункта назначения. Скорее всего мы никогда не увидим датаграммы с TTL равным 0, если только маршрутизатор, который отправил ее в кабель, не вышел из строя.

ICMP cообщение "время истекло при передаче " (time exceeded in transit) это то, что мы ожидаем увидеть от маршрутизатора bsdi, в том случае если он уменьшит на единицу TTL, и оно станет равным нулю. ICMP сообщение придет от маршрутизатора даже в том случае, если IP датаграмма, которая была уничтожена, направлялась на slip. Существуют два различных ICMP сообщения об истечении времени, в каждом из них содержится различное поле code. Рис. 2. ICMP сообщение об истечении времени ("time exceeded")

Существует возможность, что хост пошлет ICMP сообщение "время истекло в течении повторной сборки" (time exceeded during reassembly) в том случае, если время истекло в течении повторной сборки фрагментированной датаграммы. В этом случае поле code устанавливается в единицу.

Работа в глобальной сети sun % traceroute nic.ddn.mil traceroute to nic.ddn.mil ( ), 30 hops max, 40 byte packets 1 netb.tuc.noao.edu ( ) 218 ms 227 ms 233 ms 2 gateway.tuc.noao.edu ( ) 233 ms 229 ms 204 ms 3 butch.telcom.arizona.edu ( ) 204 ms 228 ms 234 ms 4 Gabby.Telcom.Arizona.EDU ( ) 234 ms 228 ms 204 ms 5 NSIgate.Telcom.Arizona.EDU ( ) 233 ms 228 ms 234 ms 6 JPL1.NSN.NASA.GOV ( ) 234 ms 590 ms 262 ms 7 JPL3.NSN.NASA.GOV ( ) 238 ms 223 ms 234 ms 8 GSFC3.NSN.NASA.GOV ( ) 293 ms 318 ms 324 ms 9 GSFC8.NSN.NASA.GOV ( ) 294 ms 318 ms 294 ms 10 SURA2.NSN.NASA.GOV ( ) 323 ms 319 ms 294 ms 11 nsn-FIX-pe.sura.net ( ) 294 ms 318 ms 294 ms 12 GSI.NSN.NASA.GOV ( ) 293 ms 318 ms 324 ms 13 NIC.DDN.MIL ( ) 324 ms 321 ms 324 ms Рис.3. Запрос от sun к сетевому информационному центру (NIC – Network Information Center)

Когда датаграмма выходит из сети tuc.noao.edu, она попадает в сеть telcom.arizona.edu. Затем она попадает в сеть Национального агентства по аэронавтике США (NASA Science Internet), nsn.nasa.gov. Маршрутизаторы с TTL равным 6 и 7 находятся в лаборатории Jet Propulsion (JPL). Сеть sura.net (в выводе TTL равно 11) это сеть Исследовательской ассоциации университетов (Southeastern Universities Research Association Network). GSI (TTL равно 12) это Government Systems, Inc., оператор для NIC. RTT для TTL равного 6 (590) почти в два раза больше, чем два другие RTT (234 и 262). Это показывает динамику IP маршрутизации. Подобное может произойти где-нибудь по пути от источника к маршрутизатору если какой-нибудь промежуточный маршрутизатор задержал датаграмму. Однако мы не можем сказать, была ли задержена исходящая датаграмма или возвращающееся ICMP сообщение. RTT для первой попытки с TTL равным 3 (204) меньше, чем RTT для первой попытки с TTL равной 2 (233). Так как каждое полученное RTT является полным временем прохода от посылающего хоста к маршрутизатору.

Опция IP маршрутизации от источника Обычно IP маршрутизация осуществляется динамически, т.е. каждый маршрутизатор принимает решение о том, на какой маршрутизатор следующей пересылки необходимо отправить датаграмму. Приложения не могут управлять этим процессом, поэтому приходится использовать средства, такие как Traceroute, чтобы проследить, как в действительности происходит маршрутизация. Идея, заложенная в маршрутизации от источника, заключается в том, что отправитель сам указывает маршрут по которому пройдет датаграмма. Существует две формы: Жесткая (strict) маршрутизация от источника. Отправитель указывает точный путь, по которому должна пройти IP датаграмма. Если маршрутизатор обнаруживает, что следующая пересылка, указанная в маршрутизации от источника, не является непосредственно подключенной сетью, возвращается ICMP ошибка "маршрутизация от источника невозможна" (source route failed). Свободная (loose) маршрутизация от источника. Отправитель указывает список IP адресов, через который должна пройти IP датаграмма, однако датаграмма может также пройти через другие маршрутизаторы между любыми двумя адресами, указанными в списке.

Traceroute позволяет использовать маршрутизацию от источника. Рис.4. Общий формат опции маршрутизации от источника в IP заголовке В случае маршрутизации от источника мы должны заполнить список IP адресов, перед тем как будет отправлена IP датаграмма, выделяем область для заполнения и инициализируем определенное количество требуемых IP адресов, обычно их количество меньше чем 9. Опции маршрутизации от источника обычно называются "маршрутизацией от источника с записью" (source and record route) (LSRR - свободная и SSRR - жесткая), так как список IP адресов обновляется в процессе того, как датаграмма проходит по маршруту.

Происходит следующее: Отправляющий хост берет из приложения маршрут от источника, удаляет первый пункт (он становится адресом назначения для датаграммы), перемещает все оставшиеся пункты влево на один пункт и помещает исходный адрес назначения на место последнего пункта в списке. Указатель все еще указывает на первый пункт списка (значение указателя равно 4). Каждый маршрутизатор, который обрабатывает датаграмму, проверяет, является ли этот адрес адресом назначения. Если нет, датаграмма обрабатывается как обычная. В этом случае должна быть использована свободная маршрутизация от источника, иначе мы не получим датаграмму. Если маршрутизатор является пунктом назначения и указатель не больше чем длина, в этом случае (1) следующий адрес в списке (куда указывает ptr) становится адресом назначения датаграммы, (2) IP адрес, соответствующий исходящему интерфейсу, замещает собой только что использованный адрес источника, и (3) указатель увеличивается на 4.

Пример traceroute с использованием свободной маршрутизации от источника sun % traceroute -g nic.ddn.mil traceroute to nic.ddn.mil ( ), 30 hops max, 40 byte packets 1 netb.tuc.noao.edu ( ) 256 ms 256 ms 235 ms 2 butch.telcom.arizona.edu ( ) 234 ms 228 ms 234 ms 3 Gabby.Telcom.Arizona.EDU ( ) 234 ms 257 ms 233 ms 4 enss142.UT.westnet.net ( ) 294 ms 288 ms 295 ms 5 t3-2.Denver-cnss97.t3.ans.net ( ) 294 ms 286 ms 293 ms 6 t3-3.Denver-cnss96.t3.ans.net ( ) 293 ms 288 ms 294 ms 7 t3-1.St-Louis-cnss80.t3.ans.net ( ) 294 ms 318 ms 294 ms 8 * t3-1.Chicago-cnss24.t3.ans.net ( ) 318 ms 295 ms 9 t3-2.Cleveland-cnss40.t3.ans.net ( ) 319 ms 318 ms 324 ms 10 t3-1.New-York-cnss32.t3.ans.net ( ) 324 ms 318 ms 324 ms 11 t3-1.Washington-DC-cnss56.t3.ans.net ( ) 353 ms 348 ms 325 ms 12 t3-0.Washington-DC-cnss58.t3.ans.net ( ) 348 ms 347 ms 325 ms 13 t3-0.enss145.t3.ans.net ( ) 353 ms 348 ms 325 ms 14 nsn-FIX-pe.sura.net ( ) 353 ms 348 ms 325 ms 15 GSI.NSN.NASA.GOV ( ) 353 ms 348 ms 354 ms 16 NIC.DDN.MIL ( ) 354 ms 347 ms 354 ms Рис.5. traceroute на nic.ddn.mil со свободной маршрутизацией от источника через NSFNET

Опция -g программы traceroute позволяет нам указать промежуточные маршрутизаторы, которые должны быть использованы при свободной маршрутизации от источника. Эта опция может быть указана до 8 раз. В командной строке мы должны указать IP адрес маршрутизатора вместо его имени. Это происходит потому, что процедура определяющая соответствие между именем и адресом или наоборот, когда задается имя, а возвращается IP адрес, не работает. Функции определения адреса по имени и имени по адресу используют два различных файла в системе DNS (Domain Name System). Вместо первого RTT для TTL равного 8 мы видим в выводе звездочку (*). Это указывает на то, что был отработан тайм-аут и на первую посылку в течении пяти секунд не был получен отклик.

Пример traceroute при использовании жесткой маршрутизации от источника Опция -G в нашей версии traceroute идентична опции -g, описанной ранее, однако она определяет жесткую маршрутизацию от источника вместо свободной. Посмотрим что произойдет, если указан неверный жесткий маршрут от источника. sun % traceroute -G netb -G gateway -G gabby westgate traceroute to westgate ( ), 30 hops max, 40 byte packets 1 netb ( ) 272 ms 257 ms 261 ms 2 gateway ( ) 263 ms 259 ms 234 ms 3 gateway ( ) 263 ms !S * 235 ms !S Рис.6.traceroute с жесткой маршрутизацией от источника, который не работает Здесь необходимо обратить внимание на выражение !S, следующее за RTT для TTL равного 3. Это означает, что программа traceroute получила ICMP сообщение "маршрутизация от источника не сработала«(source route failed). Звездочка во втором RTT для TTL равного 3 указывает на то, что на эту посылку не был получен ответ. Это как раз то что мы ожидали, так как для gateway не существует возможности послать датаграмму непосредственно к gabby.

Причина того, что датаграммы с TTL 2 и 3 пришли именно от gateway, заключается в том, что TTL с номером 2 отправлялась из gateway, когда он получил входящую датаграмму с TTL равным 1. Он определяет, что время жизни (TTL) истекло перед тем, как был обнаружен жесткий маршрут от источника (кстати, неправильный), поэтому и было отправлено ICMP сообщение об истечении времени. Строка с TTL равным 3 получена gateway с входящим TTL равным 2, он просмотрел жесткий маршрут от источника, определил, что он неверен, после чего послал ICMP сообщение о том, что маршрутизация от источника не может быть осуществлена.

Литература: 1.Синди Фейт «TCP/IP» 2.Русский перевод с книги Ричарда Стивенсона «TCP/IP Illustrated» 3.Статьи из Интернета Выполнила: ст-ка гр. СУ-61 Пасека Г.В.