Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ГОС_ответы.doc
Скачиваний:
35
Добавлен:
27.10.2018
Размер:
21.59 Mб
Скачать

51 Мережі Протокол icmp (формат ехо – запитання /ехо - відповідь и утиліта ping; формат повідомлення про помилку та утиліта traceroute)

Формат эхо-запроса/эхо-ответа и утилита ping

На рис. 19.20 показаны форматы эхо-запроса и эхо-ответа. Они отличаются друг от друга только значением поля типа (нули — для ответа, единицы — для запроса). В поле данных запроса отправитель помещает информацию, которую затем получает в ответе от узла назначения.

Эхо-запрос и эхо-ответ, в совокупности называемые эхо-протоколом, представляют собой очень простое средство мониторинга сети. Компьютер или маршрутизатор посылает по составной сети эхо-запрос, указывая в нем IP-адрес узла, достижимость которого нужно проверить. Узел, получивший эхо-запрос, формирует и отправляет эхо-ответ отправителю запроса. Так как эхо-запрос и эхо-ответ передаются по сети внутри IP-пакетов, то их успешная доставка означает нормальное функционирование всей транспортной системы составной сети.

Рис. 19.20. Формат ICMP-сообщений типа эхо-запрос/эхо-ответ

Во многих операционных системах используется утилита ping, предназначенная для тестирования достижимости узлов. Эта утилита обычно посылает серию эхо-запросов к тестируемому узлу и предоставляет пользователю статистику об утерянных эхо-ответах и среднем времени реакции сети на запросы. Утилита ping выводит на экран сообщения следующего вида обо всех поступивших ответах:

# ping serverl.citmgu.ru

Pinging serverl.citmgu.ru [193.107.2.200] with 64 bytes of data:

Reply from 193.107.2.200: bytes=64 time=256ms TTL = 123

Reply from 193.107.2.200: bytes=64 time=310ms TTL = 123

Reply from 193.107.2.200: bytes=64 time=260ms TTL = 123

Reply from 193.107.2.200: bytes=64 time=146ms TTL = 123

Из приведенной распечатки видно, что в ответ на тестирующие запросы, посланные узлу server1.citmgu.ru, было получено 4 эхо-ответа. Длина каждого сообщения составляет 64 байта. В следующей колонке помещены значения времени оборота (RTT), то есть времени от момента отправки запроса до получения ответа на этот запрос. Как видим, сеть работает достаточно нестабильно — время в последней строке отличается от времени во второй более чем в два раза. На экран выведено также оставшееся время жизни поступивших пакетов.

В зависимости от конкретной реализации утилиты ping, а также ее настроек (ключей) выводимые экранные формы могут отличагься. У утилиты ping обычно имеется несколько ключей, с помощью которых можно установить размер поля данных сообщения, начальное значение поля TTL, количество повторных передач пакетов, флаг DF.

В том случае, когда за установленное время тайм-аута ответы не приходят или протокол ICMP сообщает об ошибках, утилита ping выводит на экран соответствующие диагностические сообщения.

Формат сообщения об ошибке и утилита traceroute

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

Когда маршрутизатор не может передать или доставить IP-накет, он отсылает узлу, отправившему этот пакет, сообщение о недостижимости узла назначения. В поле типа помещается значение 3, а в поле кода — значение из диапазона 0-15, уточняющее причину, по которой пакет не был доставлен. Следующие за полем контрольной суммы 4 байт заголовка не используются и заполняются нулями.

Рис. 19.21. Формат ICMP-сообщения об ошибке — недостижимости узла назначения

Помимо причины ошибки, указанной в заголовке, в поле данных ICMP-сообщения всегда помещается заголовок IP и первые 8 байт данных того IP-пакета, который вызвал ошибку. Эта информация позволяет узлу-отправителю точнее установить причину ошибки, так как все протоколы стека TCP/IP, использующие для передачи своих сообщений IP-пакеты, содержат наиболее важную для анализа информацию в первых 8 байт своих сообщений. В частности, ими вполне могут оказаться первые 8 байт заголовка TCP или UDP, в которых содержится информация, идентифицирующая приложение, пославшее потерянный пакет. Следовательно, при разработке приложения можно предусмотреть встроенные средства реакции на сообщения о недоставленных пакетах.

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

Как было показано на примере утилиты ping, ICMP-сообщения эффективно используются для мониторинга сети. В частности, сообщения об ошибке истечения тайм-аута лежат в основе работы другой популярной утилиты traceroute для Unix, имеющей в Windows 2000 название tracert. Эта утилита позволяет проследить маршрут до удаленного хоста, определить RTT, IP-адрес и доменное имя для каждого промежуточного маршрутизатора (если это имя зарегистрировано в обратной зоне службы DNS). Такая информация полезна для локализации маршрутизатора, на котором обрывается путь пакета к удаленному хосту.

Утилита traceroute осуществляет трассировку маршрута путем посылки обычных IP-пакетов с адресом назначения, являющимся конечной точкой изучаемого маршрута. Суть метода трассировки состоит в том, что значение TTL первого отправляемого пакета установлено равным 1. Когда протокол IP первого маршрутизатора принимает этот пакет, то он в соответствии со своим алгоритмом уменьшает значение TTL на 1 и получает 0. Маршрутизатор отбрасывает пакет с нулевым временем жизни и возвращает узлу-источнику ICMP-сообщение об ошибке истечения тайм-аута вместе с заголовком IP и первыми 8 байтами потерянного пакета.

Получив ICMP-сообщение о причине недоставки пакета, утилита traceroute запоминает адрес первого маршрутизатора (который извлекает из заголовка IP-пакета, несущего ICMP-сообщение) и вычисляет для него RTT. Затем traceroute посылает следующий IP-пакет, но теперь со значением TTL, равным 2. Этот пакет благополучно проходит первый маршрутизатор, но «умирает» на втором, о чем немедленно отправляется аналогичное ICMP-сообщение об ошибке истечения тайм-аута. Утилита traceroute запоминает адрес и время для второго маршрутизатора и т. д. Такие действия выполняются с каждым маршрутизатором вдоль маршрута вплоть до узла назначения.

Мы рассмотрели работу утилиты traceroute весьма схематично, но и этого достаточно, чтобы оценить изящество идеи, лежащей в основе ее работы.

Ниже приведена копия экранной формы, выведенной утилитой tracert (Windows) при трассировке хоста ds.internic.net [198.49.45.29]:

1 311 ms 290 ms 261 ms 144.206.192.100

2 281 ms 300 ms 271 ms 194.85.73.5

19 451 мс 461 мс 460 мс attbcstoll.bbnplanet.net [206.34.99.38]

20 501 мс 460 мс 481 мс shutdown.ds.internic.net [198.49.45.29]

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

Далее идут IP-адрес и доменное имя (если оно имеется) маршрутизатора. Видно, что почти все интерфейсы маршрутизаторов поставщиков услуг Интернета зарегистрированы в службе DNS, а первые два, относящиеся к локальным маршрутизаторам, — нет.

Еще раз подчеркнем, что время, указанное в каждой строке, это не время прохождения пакетов между двумя соседними маршрутизаторами, а время, за которое пакет проделывает путь от источника до соответствующего маршрутизатора и обратно. Так как ситуация в Интернете с загрузкой маршрутизаторов постоянно меняется, то время достижимости маршрутизаторов не всегда нарастает монотонно, а может изменяться достаточно произвольным образом.

52 Мережі Причини підміни адрес, традиційна технологія NAT

Трансляция сетевых адресов

Маршрутизация в составной сети осуществляется на основе тех адресов назначе-

назначения, которые помещены в заголовки пакетов. Как правило, эти адреса остаются

неизменными с момента их формирования отправителем до момента поступле-

поступления на узел получателя. Однако из этого правила есть исключения. Например,

в широко применяемой сегодня технологии трансляции сетевых адресов (Net-

(Network Address Translation, NAT) предполагается продвижение пакета во внешней

сети (в Интернете) на основании адресов, отличающихся от тех, которые исполь-

используются для маршрутизации пакета во внутренней (корпоративной) сети.

Причины подмены адресов

Одной из наиболее популярных причин использования технологии NAT являет-

является дефицит IP-адресов. Если по каким-либо причинам предприятию, у которого

имеется потребность подключения к Интернету, не удается получить у постав-

поставщика услуг необходимого количества глобальных IP-адресов, то оно может при-

прибегнуть к технологии NAT. В этом случае для адресации внутренних узлов ис-

используются специально зарезервированные для этих целей частные адреса. Мы

уже рассказывали о них в главе 17.

Для того чтобы узлы с частными адресами могли связываться между собой через

Интернет или с узлами, имеющими глобальные адреса, необходимо использо-

использовать технологию NAT.

Технология NAT также оказывается полезной, когда предприятие из соображений

безопасности желает скрыть адреса узлов своей сети, чтобы не дать возможности

злоумышленникам составить представление о структуре и масштабах корпоратив-

корпоративной сети, а также о структуре и интенсивности исходящего и входящего трафиков.

Традиционная технология NAT

Технология трансляции сетевых адресов имеет несколько разновидностей, наи-

наиболее популярная из которых — традиционная технология NAT - позволяет уз-

узлам из частной сети прозрачным для пользователей образом получать доступ к

узлам внешних сетей. Подчеркнем, что в данном варианте NAT решается про-

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

Направление сеанса в данном случае определяется положением инициатора:

если обмен данными инициируется приложением, работающем на узле внутрен-

внутренней сети, то сеанс называется исходящим, несмотря на то, что в его рамках в сеть

могут поступать данные извне1.

Идея технологии NAT состоит в следующем. Пусть сеть предприятия образует

тупиковый домен, узлам которого присвоены частные адреса (рис. 20.7). На мар-

маршрутизаторе, связывающем сеть предприятия с внешней сетью, установлено

программное обеспечение NAT. Это NAT-устройство динамически отображает

набор частных адресов {IP*} на набор глобальных адресов {IP}, полученных

предприятием от поставщика услуг и присвоенных внешнему интерфейсу мар-

маршрутизатора предприятия.

1 Традиционная технология NAT в виде исключения допускает сеансы обратного направ-

направления, заранее выполняя статическое взаимно однозначное отображение внутренних

и внешних адресов для некоторого ограниченного набора узлов.

Рис. 20.7. Схема действия традиционной технологии NAT

Важным для работы NAT-устройства является правило распространения маршрут-

маршрутных объявлений через границы частных сетей. Объявления протоколов маршру-

маршрутизации о внешних сетях «пропускаются» пограничными маршрутизаторами во

внутренние сети и обрабатываются внутренними маршрутизаторами. Обратное

утверждение неверно — маршрутизаторы внешних сетей не получают объявле-

объявлений о внутренних сетях, объявления о них отфильтровываются при передаче на

внешние интерфейсы. Поэтому внутренние маршрутизаторы «знают» маршруты

ко всем внешним сетям, а внешним маршрутизаторам ничего не известно о су-

существовании частных сетей.

Традиционная технология NAT подразделяется на технологии базовой трансляции

сетевых адресов (Basic Network Address Translation, Basic NAT) и трансляции

сетевых адресов и портов (Network Address Port Translation, NAPT). В техноло-

технологии Basic NAT для отображения используются только IP-адреса, а в технологии

NAPT — еще и так называемые транспортные идентификаторы, в качестве кото-

которых чаще всего выступают TCP- и UDP-порты.

Базовая трансляция сетевых адресов

Если количество локальных узлов, которым необходимо обеспечить выход во

внешнюю сеть, меньше или равно имеющегося количества глобальных адресов,

то для каждого частного адреса гарантировано однозначное отображение на гло-

глобальный адрес. В каждый момент времени количество внутренних узлов, кото-

которые получают возможность взаимодействовать с внешней сетью, ограничивается

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

трансляции является не столько решение проблемы дефицита адресов, сколько

обеспечение безопасности.

Частные адреса некоторых узлов могут отображаться на глобальные адреса ста-

статически. К таким узлам можно обращаться извне, используя закрепленные за

ними глобальные адреса. Соответствие внутренних адресов внешним задается

таблицей, поддерживаемой маршрутизатором или другим устройством (напри-

(например, брандмауэром), на котором установлено программное обеспечение NAT.

В нескольких тупиковых доменах могут быть совпадающие частные адреса. На-

Например, в сетях А и В на рис. 20.8 для внутренней адресации применяется один

и тот же блок адресов 10.0.1.0/24.

Рис. 20.8. Базовая трансляция сетевых адресов для исходящих сеансов

В то же время адреса внешних интерфейсов обеих сетей A81.230.25.1/24,

181.230.25.2/24 и 181.230.25.3/24 в сети А и 185.127.125.2/24, 185.127.125.3/24

185.127.125.4/24 в сети В) уникальны глобально, то есть никакие другие узлы

в составной сети их не используют. В данном примере в каждой из сетей толь-

только три узла имеют возможность «выхода» за пределы сети своего предприятия.

Статическое соответствие частных адресов этих узлов глобальным адресам зада-

задано в таблицах пограничных устройств обеих сетей.

Когда узел 10.0.1.4 сети А посылает пакет хосту 10.0.1.2 сети В, то он помещает

в заголовок пакета в качестве адреса назначения глобальный адрес 185.127.125.3/24.

Узел-источник направляет пакет своему маршрутизатору R1 по умолчанию, ко-

которому известен маршрут к сети 185.127.125.0/24. Маршрутизатор передает пакет

на пограничный маршрутизатор R2, которому также известен маршрут к сети

185.127.125.0/24. Перед отправкой пакета протокол NAT, работающий на данном

пограничном маршрутизаторе, используя таблицу отображения, заменяет в поле

адреса источника частный адрес 10.0.1.4 соответствующим ему глобальным адре-

адресом 181.230.25.1/24. Когда пакет после путешествия по внешней сети поступает

на внешний интерфейс NAT-устройства сети В, глобальный адрес назначения

185.127.125.3/24 преобразуется в частный адрес 10.0.1.2. Пакеты, передаваемые

в обратном направлении, проходят аналогичную процедуру трансляции адресов.

Заметим, что в описанной операции не требуется участия узлов отправителя

и получателя, то есть она прозрачна для пользователей.