Архитектура и стандартизация сетей 14 страница

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

Особенностью протокола ICMP является функциональное разнообразие решаемых задач, а следовательно, и связанных с этим сообщений. Все типы сообщений имеют один и тот формат (рис. 17.22), однако интерпретация полей существенно зависит от того, к какому типу относится сообщение.

Рис 17.22. Формат ICMP-сообщения

Заголовок ICMP-сообщения состоит из 8 байт:

• тип (1 байт) — числовой идентификатор типа сообщения;
• код (1 байт) — числовой идентификатор, более тонко дифференцирующий тип ошибки;
• контрольная сумма (2 байта) — подсчитывается для всего ICMP-сообщения.

На рис. 17.23 показана таблица основных типов ICMP-сообщений. Эти сообщения можно разделить на две группы (помеченные на рисунке условными символами):

• сообщения об ошибках;
• сообщения запрос-ответ.

Сообщения типа запрос-ответ связаны в пары: эхо-запрос — эхо-ответ, запрос маски - ответ маски, запрос времени - ответ времени. Отправитель сообщения-запроса всегда рассчитывает на получение соответствующего сообщения-ответа.

Рис. 17.23. Типы и коды ICMP-сообщений

Сообщения, относящиеся к группе сообщений об ошибках, конкретизируются уточняющим кодом. На рисунке показан фрагмент таблицы кодов для сообщения об ошибке недостижимости узла назначения, имеющей тип 3. Из таблицы мы видим, что это сообщение может вызвано различными причинами, такими как неверный адрес сети или узла (код 0 ), отсутствием на конечном узле-адресате необходимого протокола прикладного уровня (код 2 — «протокол недостижим») или открытого порта UDP/TCP (код 3 — «порт недостижим»). Узел (или сеть) назначения может быть также недостижим по причине временной неработоспособности аппаратуры или из-за того, что маршрутизатор не имеет данных о пути к сети назначения. Всего таблица содержит 15 кодов. Аналогичные таблицы кодов существуют и для других типов сообщений об ошибках.

Утилита traceroute

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

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

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

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

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

Получив ICMP-сообщение о причине недоставки пакета, утилита traceroute запоминает адрес первого маршрутизатора (который извлекает из заголовка IP-пакета, несущего IСМР-сообщение).

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

Далее приведена копия экранной формы, выведенной утилитой traceroute (FreeBSD) при трассировке хоста google.com [198.49.45.29]:

traceroute: Warning: google.com has multiple addresses; using 74.125.232.20

traceroute to google.com (74.125.232.20), 64 hops max, 40 byte packets

1 zeus (192.168.252.1) 0.264 ms 0.271 ms 0.245 ms

2 217.66.30.11 (217.66.30.11) 1.579 ms 1.339 ms 1.858 ms

3 ip129.16.173.217.kzn.tbt.ru (217.173.16.129) 5.982 ms 6.447 ms 5.858 ms

4 81.16.123.165 (81.16.123.165) 5.984 ms 5.718 ms 5.736 ms

5 74.125.49.74 (74.125.49.74) 23.719 ms 23.947 ms 23.597 ms

6 74.125.49.73 (74.125.49.73) 23.354 ms

81.16.122.190 (81.16.122.190) 23.441 ms 23.582 ms

7 * * *

8 74.125.232.20 (74.125.232.20) 23.653 ms 25.801 ms 23.849 ms

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

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

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

Утилита ping

А сейчас давайте рассмотрим представителей другой группы ICMP-сообщений эхо-запросы и эхо-ответы и поговорим об использовании этих сообщений в известной утилите ping.

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

Формат эхо-запроса и эхо-ответа показан на рис. 17.25. Поле типа для эхо-ответа равно 0, для эхо-запроса — 8; поле кода всегда равно 0 и для запроса, и для ответа. В байтах 5 и 6 заголовка содержится идентификатор запроса, в байтах 7 и 8 — порядковый номер. В поле данных эхо-запроса может быть помещена произвольная информация, которая в соответствии с данным протоколом должна быть скопирована в поле данных эхо-ответа.

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

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

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

PING google.com (74.125.232.16): 56 data bytes

64 bytes from 74.125.232.16: icmp_seq=0 ttl=57 time=22.706 ms

64 bytes from 74.125.232.16: icmp_seq=1 ttl=57 time=22.649 ms

64 bytes from 74.125.232.16: icmp_seq=2 ttl=57 time=22.759 ms

64 bytes from 74.125.232.16: icmp_seq=3 ttl=57 time=35.097 ms

64 bytes from 74.125.232.16: icmp_seq=4 ttl=57 time=22.601 ms

64 bytes from 74.125.232.16: icmp_seq=5 ttl=57 time=22.586 ms

Трансляция адресов и настройка очередей

При применении технологии трансляции сетевых адресов (Network Address Translation, NAT) администратор сети в состоянии расширить доступное адресное пространство путем определения так называемых внутренних (частных) адресов (private addresses) и последующего преобразования их в открытые (public addresses) адреса. Технология NAT становится очень полезной в случае, когда организации, имеющей крупную распределенную сеть, выделяют ограниченный: блок зарегистрированных адресов, например одну сеть класса С. При этом администратор может провести дробление одной сети класса С на множество небольших, например при помощи технологии VLSM. Другой путь — попытаться получить новые открытые адреса от интернет-провайдера, что не всегда получается.

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

· 10.0.0.0-10.255.255.255/8

· 172.16.0.0-172.31.255.255/12

· 192.168.0.0-192.168.255.255/16

Любая организация вправе без ограничений использовать эти адреса без предварительной регистрации. Очевидно, что при таком подходе множество, организаций смогут их задействовать в своих частных сетях. Но эти организации должны понимать, что узловые маршрутизаторы в Интернете не будут маршрутизировать их трафик, связанный с такими адресами. Для работы с указанными адресными блоками при выделении подсетей, применении технологии VLSM и т.п. все оговоренные правила и подходы сохраняются. На практике ввиду абсолютной доступности этих блоков администратору сети редко приходится выделять подсети — гораздо проще задействовать еще одну сеть целиком, несмотря на большую избыточность.

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

Следует отметить, что адресная схема протокола IP имеет ограниченный набор возможных уникальных адресов, и в настоящее время становится все труднее получить большое количество открытых адресов ввиду ужесточения контроля над их распределением. На помощь приходит технология NAT, позволяющая при необходимости производить трансляцию частных адресов в открытые и обратно. Разработано множество аппаратных и программных решений, обеспечивающих технологию NAT. Эту технологию поддерживают известные программные комплексы Checkpoint Firewall-1, операционная система Windows 2000 с приложением RRAS (Routing and Remote Access Service), маршрутизаторы Cisco Systems. Установленные на границе сети маршрутизаторы Cisco Systems могут выполнять динамическую трансляцию частных адресов в открытые, тем самым, разрешая устройствам частной сети полноценно взаимодействовать с Интернетом. При этом для внутренних устройств подобная трансляция остается полностью прозрачной.

Администратор сети может настроить маршрутизатор для управления пулом открытых адресов, в котором адресов меньше, чем внутренних устройств сети, имеющих соединение с Интернетом. Маршрутизатор с настроенным пулом адресов будет динамически, по мере необходимости, выделять адреса для сеансов, а затем освобожденные адреса возвращать обратно в пул доступных адресов. При этом наиболее интересной особенностью с точки зрения безопасности является то, что устройства в Интернете работают с открытыми адресами из пула маршрутизатора и не имеют представления о том, что взаимодействие с ними осуществляется с частных адресов. Рассмотрим на примере общую схему работы технологии NAT (рис. 6.1).

В приведенной на рис. 6.1 сети хосту с частным адресом 192.168.3.1 необходимо взаимодействие с Интернетом, в частности с сервером. Администратор сетти предварительно настроил технологию NAT на маршрутизаторе. В результате схема трансляции будет работать следующим образом.

1. Хост передает трафик, адресованный находящемуся в Интернете серверу. Так как хост не знает маршрута к серверу, трафик посылается маршрутизатору по умолчанию (он один в этом примере). На данном этапе адрес отправителя трафика — 192.168.3.1, и он является частным адресом в блоке 192.168.3.0 /24. Маршрутизатор, получая пакеты от хоста, обнаруживает, что последний принадлежит частной сети и, следовательно, необходима трансляция адресов. Для этоо маршрутизатор просматривает настроенный пул открытых адресов и выбирает доступный адрес (193.125.203.1), который заменит собой адрес отправителя.

Адрес получателя 193.125.203.1

Адрес получателя 192.168.3.1

2. После замены адресов маршрутизатор передает пакеты в Интернет. Эти пакеты маршрутизируются узловыми маршрутизаторами до получения пакета сервером.

3. Сервер после обработки пакетов отвечает по адресу 193.125.203.1, не задаваясь о том, что действительный адрес хоста, работающего с ним, совершенно другой. Ответы сервера маршрутизируются в Интернете и в финале поступают на граничный маршрутизатор, который хранит в своей памяти информацию о выполненном преобразовании.

4. Граничный маршрутизатор после получения пакетов с адресом получателя 193.125.203.1 вновь выполняет трансляцию адресов, но теперь уже меняет адрес получателя на 192.168.3.1, и передает пакеты далее во внутреннюю сеть. Следует отметить, что хотя в рассматриваемом примере сеть 192.168.3.0. напрямую подключена к маршрутизатору (считаем, что по протоколу Ethernet) на практике между граничным маршрутизатором и хостом могут присутствовать и другие маршрутизаторы, формирующие распределенную внутреннюю сеть организации. Из-за того что граничный маршрутизатор сначала выполнял трансляцию и только после этого приступил к выполнению функции маршрутизации пакета, для промежуточных маршрутизаторов трансляция адрес будет заметна.

Рис. 6.1. Общая схема работы технологии NAT

Граничный маршрутизатор содержит таймер неактивности (idle timer),который в течение определенного времени отслеживает момент, после которого хост перестает посылать пакеты в Интернет. Тогда маршрутизатор вернет 193.125.203.1 в пул свободных адресов. При необходимости администратор может настраивать значение этого таймера.

Для рассмотренного примера настройка маршрутизатора может быть следующий:

iр nat pool name 193.125.203.1 193.125.203.254 prefix-length 24

ip nat inside source 2 pool name overload

!

interface serial0

ip nat outside

!

interface ethernet0

ip nat inside

!

access-list 2 permit 192.168.3,0 0.0.0.255

Первая команда (ip nat pool name 193.125.203.1 193.125.203.254 prefix-length 24) создает адресный пул для реализации технологии NAT — так называемые внутренние глобальные адреса (inside global addresses). Адресный пул содержит 254 адреса, начиная со 193.125.203.1 и заканчивая 193.125.203.254. Эти адреса являются зарегистрированными открытыми адресами в Интернете. Именно этими 254 адресами маршрутизатор будет впоследствии заменять внутренние адреса частной сети (так называемые inside local addresses). Данный пул именованный, его имя — name. Следующая команда (ip nat inside source 2 pool name overload) настраивает маршрутизатор на выполнение трансляции внутренних частных адресов, которые соответствуют списку доступа с номером 2. При этом используется предварительно созданный пул с именем name. Трафик, который не соответствует списку доступа с номером 2, не подвергается трансляции адресов, а маршрутизируется без всяких изменений.

Если в рассмотренном примере не выполнять трансляцию адресов, то маршрутизатор будет передавать трафик с адресами отправителей из частной сети 192.168.3.0/24 в Интернет, и трафик дойдет до получателя. Важно только указать корректный адрес получателя. Но обратно пакеты уже не поступят — узловые маршрутизаторы будут игнорировать маршруты в частные сети. На этом факте часто строятся атаки типа DoS, когда атакующий должен указать только корректный адрес получателя, абсолютно не заботясь об адресе отправителя.

Во второй команде ключевое слово overload говорит маршрутизатору, что он может использовать один открытый адрес для представления множества хостов с частными адресами. Такая возможность рассматривается как разновидность мультиплексирования. Подобные средства могут потребоваться в случае, когда пул открытых адресов исчерпается из-за большого количества активных сеансов. При мультиплексировании маршрутизатор будет задействовать уникальные номера портов протоколов TCP/UDP для выделения множества внутренних хостов. Учитывая, что для каждого адреса протокола IP доступно более 4 000 портов этих протоколов, теоретически можно поддерживать до 10 000 внутренних хостов на один публичный IP-адрес, хотя практический лимит будет достигнут быстрее.

Если задействовать ключевое слово overload, можно создать пул адресов, состоящий только из одного открытого адреса. Этот адрес может быть также назначен одному из интерфейсов маршрутизатора.

Команда ip nat outside, вводимая в режиме конфигурирования для интерфейса Serial0, указывает маршрутизатору, что данный интерфейс подключен к глобальной сети (чаще всего это сеть Интернет). Соответственно, команда ip nat для интерфейса Ethernet0 указывает маршрутизатору на внутреннюю сеть — иными словами, на расположение хостов, для которых предполагается трансляция адресов.

Последняя команда (access-list 2 permit 192.168.3.0 0.0.0.255) создает список доступа с номером 2, определяющий устройства, для которых требуется выполнять трансляцию. Маршрутизатор идентифицирует пакеты, покидающие внутреннюю сеть и входящие в нее, посредством сравнения адресов отправителе списком доступа. Если найдено совпадение (то есть, найден адрес отправителя в сети 192.168.3.0 с маской 255.255.255.0), то маршрутизатор выделяет открытый адрес из пула адресов с именем name, транслирует адреса и передает пакет в интернет.

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

При использовании динамической маршрутизации во внутренней сети следует настроить фильтр маршрутов таким образом, чтобы избежать рассылки внутренних маршрутов в Интернет.

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

Router(config)#ip nat inside source static 192.168.3.251 193.125.203.111

Эта команда формирует постоянное соответствие внутреннего адреса 168.3.251 устройства, находящегося во внутренней сети, с открытым адресом 193.125.203.111.

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

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

Выбор технического решения зависит от множества факторов. Предположим, что интернет-провайдер выделил организации сеть класса С 193.125.203.0/24 и по договору самостоятельно выполняет управление маршрутизатором (это может быть маршрутизаторы производства таких компаний, как 3Com или Nortel). Кроме того, учитывая выскоий интерес к семейству технологий xDSL, вероятно применение устройства, совмещающего в себе функциональные возможности маршрутизатора и модема, предназначенного для работы по медным проводам выделенных линий. Но и здесь сохраняется необходимость трансляции адресов, и одним из решений может быть установка выделенного защитного экрана, который помимо фильтрации трафика поддерживает технологию NAT.

В качестве примера рассмотрим программный продукт GuardianPro v5 компании NetGuard, работающий под управлением операционной системы Windows. На рис. 6.2 показана функциональная схема фрагмента сети с использованием этого продукта.

Рис. 6.2. Использование защитного экрана с поддержкой технологии NAT

В рассматриваемом примере за маршрутизатором провайдера установлен защитный экран, представляющий собой сервер на базе платформы Intel с операционной системой Microsoft Windows. Сервер содержит две сетевые платы, которые подключены ко внутренней сети и к сети, непосредственно связанной с Интернетом. Так как во внутренней сети используются частные адреса, то на защитном экране необходимо настроить технологию NAT. Следует отметить, что начальная настройка технологии NAT имеет много общего с настройкой маршрутизатора, и при этом большинство программных защитных экранов предоставляют Удобный графический интерфейс, в то время как при настройке маршрутизатора Cisco Systems администратор ограничен командной строкой.

Поиск по сайту: