Глава 21. Управление сетями 911

миллисекунд без видимой причины — просто так работают протокол IP и сама операци­ онная система Linux. Но все-таки следует ожидать, что полное время прохождения па­ кетов будет более-менее постоянным, за некоторыми исключениями. Большинство со­ временных маршрутизаторов ограничивает скорость выдачи ответов на ICMP-запросы, т.е. маршрутизатор может задержать ответ на пакет команды ping в связи с общим огра­ ничением трафика протокола ICMP.

Команда ping позволяет задать размер посылаемого эхо-пакета. Если передается па­ кет, размер которого превышает значение MTU для данной сети (в частности, 1500 байт в сети Ethernet), включается режим принудительной фрагментации. Это позволяет вы­ являть ошибки передачи данных в самом кабеле и другие низкоуровневые ошибки, на­ пример проблемы, связанные с перегрузкой сети или виртуальной частной сетью.

В системах семейства Linux желательный размер пакета в байтах задается с помощью флага -s.

# ping -s 1500 cuinfo.cornell.edu

В системах Solaris, HP-UX и AIX достаточно просто указать желательный размер па­

кета в конце команды ping.

# ping cuinfo.cornell.edu 1500

Помните, что даже простая команда вроде ping может повлечь драматические по­ следствия. В 1998 году так называемая атака Ping of Death (Смертельный Ping) вызва­ ла сбой большого количества UNIX- и Windows-систем. Эта атака началась с отправки чрезмерно большого ping-пакета. Когда фрагментированный пакет был собран заново, он заполнил весь буфер получателя и привел к сбою компьютера. Опасность повторения атаки Ping of Death давно устранена, но некоторые изъяны, связанные с использованием утилиты ping, все еще существуют.

Во-первых, сложно отличить неисправность сети от неисправности сервера, поль­ зуясь только этой командой. Потеря эхо-пакетов означает лишь, что что-то работает неправильно.

Во-вторых, успешно выполненная команда ping не позволяет получить информа­ цию о состоянии исследуемого компьютера. Эхо-запросы обрабатываются в стеке про­ токола IP и не требуют, чтобы на зондируемом компьютере выполнялся серверный про­ цесс. Получение ответа гарантирует только то, что компьютер включен и ядро системы функционирует. Для проверки работы отдельных служб, таких как HTTP и DNS, следует применять высокоуровневые средства.

36. Kоманда traceroute: трассировка ip-пакетов

Команда traceroute, написанная Ваном Джейкобсоном (Van Jacobson), позволя­ ет выявлять последовательность шлюзов, через которые проходит IP-пакет на пути к пункту назначения. Эта команда есть во всех современных операционных системах.2 Синтаксис ее вызова прост,

traceroute имя_компьютера

У этой команды очень много параметров, большинство которых в повседневной ра­ боте не применяется. Как обычно, имя_компьютера может быть задано как имя DNS или IP-адрес. Команда выдает список узлов, начиная с первого шлюза и заканчивая пунктом назначения. Например, на нашем компьютере jaguar проверка узла nubark дает следующие результаты.

2 Она есть даже в системе Windows, но в ней она называется tracert (если догадаетесь, поче­ му, получите дополнительные баллы по истории).

Глава 21. Управление сетями 913

% traceroute nubark

traceroute to nubark (192.168.2.10), 30 hops max, 38 byte packets

1 lab-gw (172.16.8.254) 0.840 ms 0.693ms 0.671ms

2 dmz-gw (192.168.1.254) 4.642ms 4.582ms 4.674ms 3 nubark (192.225.2.10) 7.959ms 5.949ms 5.908ms

Эти результаты говорят о том, что для попадания с компьютера jaguar на узел nubark пакеты должны сделать три перехода. Кроме того, они содержат информацию о шлюзах, через которые проходят пакеты. Показано также полное время прохождения пакетов для каждого шлюза — проведено по три замера для каждого перехода. Обычно количество переходов от одного узла Интернет к другому составляет более 15, даже если два сайта расположены через дорогу.

Команда traceroute работает путем записи искусственно заниженного значения в поле TTL (Time То Live — время жизни, или предельное число переходов) отправляемо­ го пакета. Когда пакет приходит на очередной шлюз, его значение TTL уменьшается на единицу. Если шлюз обнаруживает, что значение TTL стало равным нулю, он удаляет пакет и возвращает узлу-отправителю специальное ICMP-сообщение: “Время жизни па­ кета истекло”.

Более подробную информацию об обратном поиске имен в системе DNS можно найти в разделе 17.8.

У первых трех пакетов команды traceroute значение TTL равно 1. Первый шлюз, получивший пакет (в нашем примере это lab-gw), обнаруживает, что его время жиз­ ни истекло. Тогда он удаляет пакет и посылает компьютеру jaguar указанное ICMP- сообщение, в поле отправителя которого записан IP-адрес шлюза. Команда traceroute обращается к службе DNS и по имеющемуся адресу находит имя шлюза.

Для получения данных о следующем шлюзе посылается очередная группа пакетов, поле TTL которых равно 2. Первый шлюз маршрутизирует эти пакеты и уменьшает значение TTL на единицу. Второй шлюз удаляет пакеты и генерирует описанные выше ICMP-сообщения. Этот процесс продолжается до тех пор, пока пакеты не достигнут нужного компьютера; значение TTL при этом будет равно числу переходов.

Большинство маршрутизаторов посылает свои ICMP-сообщения через тот интерфейс, который является “ближайшим” к узлу-отправителю (т.е. имеет наименьшую метрику стоимости). Если, наоборот, запустить команду traceroute на узле-получателе, чтобы узнать маршрут к исходному компьютеру, то, скорее всего, будет получен другой список IP-адресов, соответствующий тому же набору маршрутизаторов. Иногда весь набор шлю­ зов оказывается совершенно другим; такая конфигурация называется асимметричной.

Для каждого значения TTL команда traceroute посылает три пакета, что иногда приводит к интересным результатам. Если промежуточный шлюз распределяет трафик по нескольким маршрутам, то пакеты могут возвращаться разными компьютерами. В та­ ком случае команда traceroute сообщает обо всех полученных ответах.

Рассмотрим пример, в котором посредством команды traceroute определяется маршрут с компьютера в Швейцарии к домену caida.org в суперкомпьютерном центре Сан-Диего (San Diego Supercomputer Center).3

linux$ traceroute caida.org

traceroute to caida.org (192.172.226.78), 30 hops max, 46 byte packets

1 gw-oetiker.init7.net (213.144.138.193) 1.122 ms 0.182 ms 0.170 ms

2 rlzurl.core.init7.net (77.109.128.209) 0.527 ms 0.204 ms 0.202 ms 3 rlfral.core.init7.net (77.109.128.250) 18.279 ms 6.992 ms 16.597 ms

3 Мы удалили несколько цифр в дробной части миллисекунд, чтобы сделать строки короче.

914 Часть II. Работа в сети

4 r1ams1.core.init7.net (77.109.128.154) 19.549 ms 21.855 ms 13.514 ms 5 r1lon1.core.init7.net (77.109.128.150) 19.165 ms 21.157 ms 24.866 ms 6 r1lax1.ce.init7.net (82.19-7.168.69) 158.232 ms 158.224 ms 158.271 ms 7 cenic.laap.net (198.32.146.32) 158.349 ms 158.309 ms 158.248 ms

8 dc-lax-core2—lax-peer1-ge.cenic.net (137.164.46.119) 158.60 ms * 158.71 ms

9 dc-tus-agg1--lax-core2-10ge.cenic.net (137.164.46.7) 159 ms 159 ms 159 ms 10 dc-sdsc-sdsc2—tus-dc-ge.cenic.net (137.164.24.174) 161 ms 161 ms 161 ms 11 pinot.sdsc.edu (198.17.46.56) 161.559 ms 161.381 ms 161.439 ms

12 rommie.caida.org (192.172.226.78) 161.442 ms 161.445 ms 161.532 ms

Эти строки свидетельствуют о том, что пакеты долго путешествовали внутри сети Init Seven. Иногда по именам шлюзов можно догадаться об их географическом местополо­ жении. Сеть Init Seven раскинулась от Цюриха (zur) до Франкфурта (fra), Амстердама (ams), Лондона (lon) и, наконец, до Лос-Анджелеса (lax). В этом месте пакеты достиг­ ли сайта cenic.net, который доставил пакеты на узел caida.org внутри сети супер- компьютерного центра Сан-Диего (sdsc) в городе Ла Хойя (La Jolla)4, шт. Калифорния.

На восьмом переходе вместо одного из значений времени отображается звездочка. Это означает, что на один из отправленных пакетов не был получен ответ. Такая ситуа­ ция может быть вызвана перегрузкой сети, но это не единственное возможное объяс­ нение. Команда traceroute использует низкоприоритетные ICMP-пакеты, которые отбрасываются многими маршрутизаторами, отдающими предпочтение “реальному” трафику. Появление нескольких звездочек в выводе команды traceroute не является причиной для беспокойства.

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

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

Некоторые брандмауэры могут также блокировать исходящие UDP-пакеты, кото­ рые команда traceroute посылает для инициирования ICMP-ответов. В этом случае команда не выдаст никакой полезной информации. Если ваш брандмауэр не дает вы­ полнить команду traceroute, убедитесь, что его конфигурация открывает порт 33434- 33534 и допускает пакеты ICMP ECHO (тип 8).

Медленная передача данных не всегда свидетельствует о неисправности сети. Не­ которые сети действительно имеют большую задержку, особенно если в них использу­ ется технология UMTS/EDGE/GRPS. Ярким примером являются беспроводные сети. Медлительность может быть также следствием перегрузки сети. Определить это можно по нелогичному значению полного времени прохождения пакета.

Иногда можно увидеть символы !N вместо значения времени. Это говорит о том, что соответствующий шлюз вернул сообщение о “недостижимости” сети, т.е. он не знает, куда посылать пакет. Сообщения о “недостижимости” узла или протокола помечаются как !H или !Р соответственно. Шлюз, от которого получено одно из указанных сообще­ ний, является последним в цепочке и обычно имеет проблемы с маршрутизацией (воз-

4 Пригород Сан-Диего. — Примеч. ред.