Использование информационных технологий для построения сетей связи крупных корпораций

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

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

Рисунок 13.1 - Схема проектируемой корпоративной сети
Основой для предоставления инфокоммуникационных услуг является технология построения динамической многоточечной виртуальной частной сети (Dynamic Multipoint Virtual Private Network, DMVPN). Эта технология разработана компанией Cisco для построения масштабируемых защищенных VPN сетей. Cisco DMVPN имеет централизованную архитектуру, однако позволяет филиалам напрямую обмениваться друг с другом данными, например при использовании VoIP соединений между площадками, но не требует организации постоянного туннеля между ними. Таким образом, архитектура решения на рис.13.2 подразумевает создание топологии типа «звезда» (hub and spoke) c возможностью организации прямых соединений между удаленными офисами при необходимости (spoke to spoke).

 

Рисунок 13.2 - Архитектура модели DMVPN

           

 

 

Основными элементами модели DMVPN являются следующие технологии:Multipoint Generic Routing Encapsulation (mGRE) с протоколом NHRP (Next Hop Resolution Protocol); Psec; протокол динамической маршрутизации.

Общий алгоритм работы DMVPN облака имеет следующий вид.

1. Каждый spoke строит постоянный GRE/IPsec туннель до hub-маршрутизатора, но не до других spoke-маршрутизаторов. Они регистрируются как клиенты на NHRP сервере (который является Hub-ом).

2. Когда spoke-маршрутизатору необходимо послать пакет в сеть, располагающуюся за другим spoke-маршрутизатором, он запрашивает через протокол NHRP его публичный адрес.

3. После этого spoke-маршрутизатор может установить динамический GRE/IPsec туннель с маршрутизатором назначения, поскольку знает его адрес.

4. Динамический spoke-to-spoke туннель строится на основе mGRE интерфейса.

5. Когда передача трафика между этими сетями прекращается, туннель удаляется.

Рассмотрим основные элементы данной технологии.

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

    Протокол общей инкапсуляции маршрутов (Generic Routing Encapsulation – GRE) – это протокол, который может быть использован для передачи других протоколов-пассажиров, в том числе широковещательных и многоадресных сообщений (см. рис. 13.3).

Рисунок 13.3. – Использование GRE в качестве протокола инкапсуляции

        

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

В архитектуре DMVPN используется mGRE интерфейс, который представляет собой интерфейс типа «один ко многим» (one to many) для создания множества «hub and spoke» туннелей. При этом IP адрес назначения туннеля не описывается, а определяется динамически с использованием протокола NHRP. Таким образом, на центральном маршрутизаторе требуется описание одного туннельного интерфейса в рамках DMVPN облака для всех удаленных маршрутизаторов.

Заголовок протокола mGRE на 4 байта длиннее, чем обычный GRE заголовок. Дополнительные 4 байта представляют собой значение туннельного ключа, который используется для того, чтобы отличать различные mGRE интерфейсы в пределах одного маршрутизатора. Туннельные ключи позволяют маршрутизаторам иметь несколько mGRE интерфейсов для связи с несколькими DMVPN облаками, что необходимо для построения отказоустойчивых сетевых структур. Структура расширенного заголовка протокола GRE (RFC 2890) представлена на рисунке 13.4 и имеет следующие поля:

- флаг С (Cheksum Present) равен 1, если в заголовке присутствует поле контрольной суммы;

- флаг K (Key Present) равен 1, если в заголовке присутствует поле туннельного ключа;

- флаг S (Sequence Number Present) равен 1, если в заголовке присутствует поле порядкового номера;

- поле Ver (Номер версии) всегда равно 0;

- поле Protocol Type (Тип протокола) содержит описание протокола-пассажира, для IPv4 значение поля равно 47;

- поле Cheksum (Контрольная сумма) содержит контрольную сумму всех элементов GRE заголовка вместе с полезной информацией пакета;

- поле Key (Ключ) содержит туннельный ключ, описанный выше;

- поле Sequence Number (Порядковый номер) используется получателем для определения порядка, в котором пакеты передавались от отправителя.

 

Рисунок 13.4 - Формат расширенного GRE заголовка

 

1.

2.

3.

3.1.

       Структура, которую образует DMVPN с возможностью организации spoke-to-spoke туннелей, является сетью с множественным доступом, не поддерживающей множественную рассылку (NBMA – Non-Broadcast Multiple Access Network). Множественный доступ определяется использование mGRE туннелей, когда в рамках одного DMVPN облака все маршрутизаторы находятся в пределах одной IP сети. Но в силу того, что объединение данного сегмента происходит через виртуальный туннельный интерфейса, а инкапсулированный трафик проходит через публичную WAN сеть, прохождение широковещательных пакетов обеспечить не возможно. При этом внутри GRE пакета многоадресные сообщения успешно передаются между сегментами сети. Примером NBMA сетей являются сети Frame-Relay.

    В NBMA сетях не работает протокол ARP (Address Resolution Protocol), так как его работа основана на широковещательных пакетах. Его функцию, связанную с преобразованием адресов сетевого уровня в адреса канального уровня выполняет протокол NHRP. С помощью NHRP система, подсоединенная к NBMA сети, динамически получает NBMA-адрес другой системы, которая является частью этой сети, позволяя этим системам взаимодействовать друг с другом напрямую, минуя промежуточные узлы. В случае работы NHRP в сетях DMVPN происходит преобразованием внутреннего адреса туннельного интерфейса (VPN адрес) в публичный IP адрес (NBMA адрес).

    В протоколе предусмотрены три основные функции: регистрация, разрешение и перенаправление. Функция регистрации позволяет NHRP-клиентам (удаленные маршрутизаторы) регистрироваться на NHRP-сервере (центральный маршрутизатор) для построения таблицы соответствия VPN и NBMA адресов. Функция разрешения (resolution) позволяет двум NHRP-клиентам в NBMA сети динамически получать NBMA-адрес друг друга. Функция перенаправления позволяет центральному маршрутизатору перенаправлять пакеты, предназначенные другому spoke-маршрутизатору, тем самым инициируя процесс создания прямого spoke-to-spoke туннеля. Процесс передачи трафика по DMVPN сети между spoke маршрутизаторами представлен на рисунке 13.5.

                       

Рисунок 13.5 - Процесс построения spoke-to-spoke туннеля

 

Spoke-источник, получив IP пакет, направляет его маршрутизатору-получателю через Hub. Hub-маршрутизатор, получив данный пакет, направляет его через туннельный интерфейс получателю, а в сторону маршрутизатора-источника отправляет сообщение NHRP Redirect (1). Spoke-источник, получив это сообщение, формирует ответное сообщение NHRP Resolution Request в сторону маршрутизатора-получателя (2). Получив данное сообщением, маршрутизатор-получатель строит spoke-to-spoke туннель и отправляет по нему сообщение NHRP Resolution Reply (3). На рисунке так же показано формирования трех таблица, используемых для пересылки пакетов. Таблица NHRP mapping содержит записи NHRP кэша. Таблица CEF Adjacency строится на основе NHRP кэша и содержит информацию о NBMA адресе соседних маршрутизаторов. Таблица CEF Forwarding Information Base (FIB) использует для быстрой пересылки пакетов и строится на основе таблицы маршрутизации и таблицы CEF Adjacency.

Динамические NHRP записи имеют конечное время жизни, определяемое специальным таймером. После истечения этого таймера данные должны быть запрошены заново с помощью сообщений NHRP Resolution Request/Reply, в противном случае данная запись удаляется.

    Описанный принцип пересылки пакетов в DMVPN может влиять на качество передаваемого VoIP трафика. При анализе задержек, присутствующих между офисами компании, необходимо учитывать время, вносимое процессом шифрования. Согласно [8] это время составляет в среднем 2 мс для однократного процесса шифрование/дешифровки. Другой фактор, влияющий на вариацию задержки – это различные маршруты прохождения пакетов при инициализации spole-to-spoke туннеля. Так, до момента создания данного туннеля трафик проходит маршрут spoke-hub-spoke, а после – напрямую. При этом если туннель был создан до начала RTP сессии – такая проблема не возникает. Процесс создание туннеля занимает менее 1 секунды, а вызванная данным процессом вариация задержки может быть компенсирована анти-джитерным буфером, если разница в задержке не превышаем 50-100 мс. В случае, если на сети имеет место сценарий, когда разница в задержке слишком велика (например, если два участвующих spoke расположены географически близко друг к другу и при этом далеко от центрального маршрутизатора), то необходимо принимать меры для того, чтобы организованный spoke-to-spoke туннель не удалялся, например, с помощью механизмов IP SLA.

    Отдельно стоит отметить особенности работы QOS в архитектуре DMVPN. Поскольку spoke-to-spoke являются динамическими, то никакие политики QOS для них не применимы. Такие политики должны применяться непосредственно на физическом интерфейсе. При этом, полоса пропускания каналов должна быть выделена на основе требований конкретных приложений и ограничена соответствующими значения в политике QOS. Так же должна быть рассчитано количество голосовых соединений между всеми элементами системы, а данное количество должно быть ограничено механизмом Location-based Call Admission Control (CAC). Механизм CAC может запретить или направить по другому маршруту инициированный вызов через WAN если, если вся полоса пропускания на источнике или получателе уже была выделена другим вызовам, при этом существующие вызовы будут обслуживаться без ухудшения качества связи. В случае, если данный механизм использоваться не будет, то, при поступлении вызова полоса пропускания которого превысит выделенную, произойдет перегрузка и, что приведет к потерям и, как следствие, к ухудшению качества связи на всех, уже инициированных вызовах.

 

Набор протоколов IPsec

    Набор протоколов IPsec (IP security – система защиты на уровне IP) реализует механизм защищенной передачи данных в сетях IP, обеспечивая конфиденциальность, целостность и достоверность данных, передаваемых через незащищенные сети. IPsec обеспечивает следующие возможности в сетях связи:

- конфиденциальность данных - отправитель имеет возможность шифровать пакеты перед их отправкой в сеть;

- получатель данных имеет возможность аутентифицировать сообщающиеся с ним стороны и пакеты, посылаемые этими сторонами, чтобы быть уверенным в том, что данные не были изменены в пути;

- получатель данных имеет возможность аутентифицировать источник получаемых пакетов;

- получатель данных может обнаружить и отвергать воспроизведенные пакеты, не допуская их фальсификации и проведения атак «внедрения посредника» («man in the middle»).

Фундаментальной концепцией технологии IPsec является концепция Ассоциаций Защиты (Security Association – SA). Она представляет собой согласованную политику или способ обработки данных, обмен которыми предполагается между двумя сообщающимися сторонами. Одной из составляющих такой политики может быть алгоритм, используемый для шифрования данных. Соединение SA является симплексным, поэтому для взаимодействия сторон необходимо установить два соединения.

Протокол IKE (Internet Key Exchange – обмен Интернет-ключами) является гибридным протоколом, обеспечивающим сервис аутентификации сторон IPSec, согласование параметров SA, а также выбор ключей для алгоритмов шифрования. Протокол IKE в свою очередь опирается на протоколы ISAKMP (Internet Security Association and Key Management Protocol – протокол управления ассоциациями и ключами защит в сети Интернет) и Oakley, которые применяются для управления процессом создания и обработки ключей шифрования, используемых в преобразованиях IPsec. Алгоритм работы технологии IPsec представлен на рисунке 14.1 и состоит из следующих этапов [9].

1) Начало процесса IPSec. Трафик, которому требуется шифрование в соответствии с политикой защиты, согласованной сторонами, начинает IKE-процесс. На этом этапе определяется, какой трафик подлежит шифрованию, какие функции и алгоритмы могут быть использованы.

2) Первая фаза IKE. Цель данный фазы – организовать безопасный канал между сторонами (ISAKMP туннель) для ведения переговоров о параметрах IPsec SA. Параметры данного туннеля определяются политикой ISAKMP. Выполняются следующие действия:

- аутентификация и защита идентификационной информации узлов;

- проверка соответствий политик IKE SA узлов для безопасного обмена ключами;

- обмен Диффи-Хеллмана, в результате которого у каждого узла будет общий секретный ключ;

- cоздание безопасного канала для второй фазы IKE.

3) Вторая фаза IKE. Ее задачей является создание IPsec туннеля, через выполнение следующих функций:

- согласуются параметры IPsec SA по защищаемому IKE SA каналу, созданному в первой фазе IKE;

- устанавливается IPsec SA;

- периодически осуществляется пересмотр IPsec SA, чтобы убедиться в её безопасности.

4) Передача данных. Происходит обмен данным между сообщающимися сторонами, который основывается на параметрах и ключах, хранимых в базе данных SA (SAD – Security Association Database).

5) Завершение работы туннеля IPsec. SA IPsec завершают свою работу либо в результате их удаления, либо по причине превышения предельного времени их существования.

В качестве методов защиты данных в технологии IPsec предусмотрены два протокола. Протокол AH (Authentication Header) – протокол защиты, обеспечивающий аутентификацию и сервис выявления воспроизведения. Протокол AH действует как цифровая подпись и гарантирует, что данные в пакете IP не будут несанкционированно изменены. Этот протокол не обеспечивает сервис шифрования данных и может быть использован самостоятельно или совместно с протоколом ESP. Протокол ESP (Encapsulating Security Payload) – протокол защиты, обеспечивающий конфиденциальность и защиту данных, используется для шифрования полезной нагрузки IP пакетов. В рамках протокола ESP может так же обеспечиваться аутентификация пакетов с помощью необязательного поля аутентификации EPS-HMAC. Главное различие между аутентификацией ESP и AH заключается в области их охвата пакета. ESP не защищает поля заголовка IP, если работает в транспортном режиме, а AH защищает весь исходный IP пакет.

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

Заголовок ESP содержит поле SPI (Security Parameters Index) длиной 4 байта, которое, вместе с IP адресом получателя и протоколом безопасности (ESP), определяет защищенное виртуальное соединение для данного пакета (SA). Поле Sequence Number (4 байта) служит от защиты от повторной передачи. ESP Initialization Vector используется для начала процесса расшифровки в алгоритмах с режимом шифрования цепочки блоков.

           

 

Рисунок 14.1 - Формат пакета IPsec over mGRE

 

       Поле ESP Authentication Trailer содержит значение проверки целостности данных (ICV) и код проверки подлинности сообщения, которые используются для подтверждения легитимности отправителя и целостности данных. ESP Trailer содержит поля Next Header (1 байт), определяющее протокол высшего уровня (TCP/UDP), и Padding Length (1 байт), указывающее длину поля заполнения. Поле заполнения используется для выравнивания длины ESP Trailer и ESP Authentication Trailer до полных 32 бит.