Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Технологии виртуальных частных сетей. Учебное пособие.pdf
Задача 1. Настройте политику IKE (ISAKMP), которая использует аутентификацию пиров на основе PKI.
Задача 2. Создайте профиль ISAKMP и свяжите его с VPN. Этот вариант
применяется, если имеется более одной точки доверия, и существует требование связать конкретный удалённый пир VPN с определённой точкой доверия
(сертификатом ЦС).
Задача 3. Настройте аутентификацию удалённых пиров на основе сертификатов, чтобы они ассоциировались только с конкретными виртуальными сетями. Это
т вариант рекомендуется в большинстве сценариев.
5.20. СЦЕНАРИЙ КОНФИГУРАЦИИ
Предстоящий набор задач настройки включает в себя настройку маршрутизатора Cisco IOS для установки сеанса IKE с другим маршрутизатором с использованием следующих параметров:
− в сеансе IKE будет использована аутентификация на основе подпи-
сей RSA;
− в сеансе IKE используется 128-битное шифрование AES и группа
DH 14 для обмена ключами.
Задача 1 включает в себя настройку политики IKE с методом аутентификации RS
Router(config)# crypto isakmp policy 10
Router(config-isakmp)# authentication rsa-sig
Router(config-isakmp)# encr aes
Router(config-isakmp)# group 14
A – rsa-sig. В примере ниже показано использование команды:
71
6. GET VPN
Технология Cisco Group Encrypted Transport Virtual Private Network (GET
VPN) – это решение, позволяющее легко развёртывать сложную, избыточную и
полноcвязную сеть VPN.
Полноcвязные VPN-сети обычно сложны с точки зрения масштабируемости и управляемости. Такие типы сетей с большим количеством сайтов обычно
не используются из-за их сложности. В этой главе пойдёт речь об основных
принципах технологии GET VPN, о том, как планировать развёртывание, как
настраив
доступность сети GET VPN.
GET VPN обеспечивают масштабируемую, без установления соединения, безтуннельную защиту передачи данных, которая использует существующую инфраструктуру маршрутизации. Несмотря на то, что GET VPN может использоваться поверх сети Multiprotocol Label Switching (MPLS), IP, Frame Relay и
ATM, это идеальное криптографическое решение для MPLS VPN, которое требует межсайтового шифрования.
не требует создания туннелей. Исключая необходимость создания туннелей
«точка–точка», сети филиалов могут масштабироваться и поддерживать сетевые функции, необходимые для качественной передачи голосовых и видеопотоков, такие как качество обслуживания (QoS), маршрутизация и многоадресная рассылка. GET VPN обеспечивают новую, основанную на стан
модель безопасности, которая использует концепцию «доверенных» членов
группы. Надёжные маршрутизаторы-участники используют общую модель
безопасности, которая не зависит от использования туннельных соединений
IPsec «точка–точка».
IP и MPLS. MPLS VPN, которые используют GET, обеспечивают высокую дос-
тупность, управляемость и экономичность при соблюдении требований к защите передачи данных. GET VPN обеспечивают гибкость, позволяющую предприятиям управлять собственной безопасностью пов
луг или только частично использовать услуги шифрования, предоставляемые
оператором. GET VPN упрощают построение больших сетей уровня Layer 2
или MPLS, которые нуждаются в частично или полносвязной топологии.
Servers), также известные как серверы ключей (KS) и члены группы (group
members), являются двумя ключевыми компонентами, которые составляют ар-
хитектуру GET VPN. Сервер ключей аутентифицирует всех членов группы, выполняет управление доступом к домену GET VPN, создаёт и обеспечивает ключ
групповой аутентификации в качестве ассоциаций безопасности (SA – Security
Association) для членов группы. Члены группы обеспечивают защиту передаваемых данных в модели site-to-site (m
ать и проверять серверы ключей GET VPN, и как реализовать высокую
Начиная с версии программного обеспечения Cisco IOS Release 12.4 (11) T,
С внедрен
ием GET VPN Cisco предлагает новую категорию VPN, которая
дартах IPsec
GET VPN можно развернуть в различных топологиях WAN, включая сети
ерх сети WAN поставщика ус-
6.1. АУТЕНТИФИКАЦИЯ ПИРОВ
Контроллер группы/серверы ключей (GCKS – Group Controller/Key
ember-to-member).
72
Серверы ключей распространяют ключи и политики для всех зарегистрированных и аутентифицированных маршрутизаторов, которые являются членами группы. Распределение ключей и управление ими упрощаются благодаря
централизованному распределению ключей и политик.
Все передаваемые данные между сервером ключей и членами группы зашифровываются и защищаются с использованием протокола Internet Exchange
Exchange (IKE) Group Domain of Interpretation (GDOI).
IKE GDOI – это протокол, основанный на ст
андарте Internet Security
Association and Key Management Protocol (ISAKMP), который обеспечивает
безопасную передачу данных внутри группы. GET VPN используют IKE GDOI
в качестве группового механизма.
IKE GDOI поддерживает использование двух видов ключей: ключа шифрования трафика (TEK – Traffic Encrypting Key) и ключа шифрования ключа
(KEK – Key Encrypting Key):
− TEK – ключ, который используется для защиты трафика между чле-
нами группы;
− KEK – ключ, который используется для защиты ключей (во время
обновления ключевой информации) между сервером ключей и членами группы.
TEK расп
ространяется среди всех членов группы сервером ключей. Члены группы используют TEK для связи с другими членами группы и для создания и проверки пакетов IPsec. KEK также распространяется среди членов группы, которые в свою очередь используют его для дешифрования входящих сообщений ключевой информации от сервера ключе
й.
Когда получено сообщение о регистрации, сервер ключей генерирует информацию, содержащую политику повторного ключа (KEK) и новые IPsec SA
(множественные атрибуты TEK, политика шифрования трафика, информация о
времени жизни, источнике и получателе трафика, который необходимо защитить, и индекс параметров безопасности (SPI – Security Parameter Index), который связан с каждым TEK). Затем вновь создаваемые IPsec SA отправляются
ам группы. Сервер ключей поддерживает таблицу, которая содержит
член
IP-адрес каждого члена группы и его групповую ассоциацию. Когда регистрируется новый член группы, сервер ключей добавляет новый IP-адрес в связанную с ним группу.
6.2. ОБМЕН ТРАФИКОМ В GET VPN
Члены группы GET VPN, у которых есть действительные IPsec SA, предполагают, что трафик, который они шифруют, может быть расшифрован другим легитимным членом группы GET VPN. В традиционной многоадресной
реализации передачи данных отправитель не знает, кто является потенциальным получателем. Используя независимую от протокола многоадресную рассылку – Protocol Independent Multicast – Sparse-Mode (PIM-SM), маршрутизатор
отправляет многоадресный трафик в настроенную «точку рандеву» (RP – rendezvous point). RP поддерживает список получателей многоадресной группы.
С помо
щью GET VPN отправитель предполагает, что легитимные члены
группы получают TEK с сервера групповых ключей. Член группы шифрует
73
данные многоадресной передачи, сохраняет заголовок и пакет коммутируется
на маршрутизаторе. Репликация пакета многоадресной передачи выполняется в
ядре на основе IP-адреса источника и многоадресной группы, которая сохраняется в пакете многоадресной передачи.
Защищённый одноадресный пакет плоскости данных похож на пакет
многоадресной рассылки. При защите плоскости данных получатель не знает,
какие могут быть потенциальные источники шифрованного трафика. Получатель пр
едполагает, что легитимные члены группы получили TEK от группового
сервера ключей. Получатель аутентифицирует члена группы тогда, когда он
способен расшифровать пакет данных.
6.3. СЕРВИСЫ БЕЗОПАСНОСТИ
GET VPN обеспечивают те же преимущества обеспечения безопасности,
что и IPsec. Эти параметры безопасности включают решение обеспечения конфиденциальности данных (с использованием криптографических алгоритмов
шифрования, таких как AES [Advanced Encryption Standard] или 3DES [Triple
Data Encryption Standard]), целостность данных и аутентификацию (с использованием алгоритмов аутентификации HMAC [Hash Message Authentication Code],
таких как SHA-1 [Secure Hash Algorithm-1] HMAC или MD5 [Message Digest 5]
HMAC), а также проприетарный механизм защиты от повторов, основанный на
времени (вместо использования системы с порядковыми н
омерами). Стандартный метод порядковых номеров не может использоваться в виртуальных частных сетях, поскольку синхронизация счётчиков порядковых номеров при
большом количестве пиров не представляется возможной.
Алгоритм шифрования AES является рекомендуемым алгоритмом для
использования в сетях GET VPN. Из-за возможного наличия большого количества членов группы VPN, использующих одни и те же (групп
овые) сеансовые
ключи и довольно короткий вектор инициализации (IV – Initialization Vector)
3DES, использование 3DES в GET VPN не рекомендуется.
Обратите внимание, что протокол сетевого времени (NTP) не требуется в
GET VPN (если, конечно, не используется аутентификация на основе сертификатов), поскольку члены группы используют проприетарное псевдовремя вместо стандартного времени для создания и проверки временных меток.
GDOI является базовым стандартом для GET VPN, как определено в
RFC 3547. GDOI определяет протокол управления ключами, основанный на
IKE/ISAKMP. Он использует те же принципы, что и IKE/ISAKMP для генерации симметричных ключей шифрования, но использует два ключа – KEK и
TEK. Этот протокол управления ключами является расширением IKE/ISAKMP
и использует порт UDP 848. Одно существенное различие заключается в том,
что GDOI IKE SA не требует задержки между член
чального установления соединения, но они могут быстро истечь после того, как
член группы прошёл аутентификацию на сервере ключей и получил групповую
74
6.4. АРХИТЕКТУРА УПРАВЛЕНИЯ КЛЮЧАМИ
ами группы после первона-
политику. Второе главное отличие заключается в том, что сеансы GDOI IKE
не устанавливаются между всеми пирами в VPN, а только между каждым членом группы и сервером ключей (или несколькими ключевыми серверами при
резервировании).
Ещё одна заметная разница заключается в том, что все члены группы используют один и тот же набор ключей сеанса для защиты сет
евого трафика. Это
более эффективно по сравнению с традиционными VPN-сетями IPsec, в которых каждая пара пиров имеет собственный набор IPsec SA, которые используются только между этими двумя пирами.
6.5. МЕТОДЫ ПЕРЕСОЗДАНИЯ КЛЮЧЕЙ
GET VPN используют сообщения rekey для обновления своих IPsec SA
(сеансовых ключей) за пределами сеансов IKE. Когда истекает срок действия
IPsec SA группы, на сервере ключей генерируется одно сообщение с ключом
для определённой группы. Распространение сообщения rekey не требует создания новых сеансов IKE. GET поддерживает повторную отправку сообщения rekey c помощью одноадресной и многоадресной рассылки.
Если какая-либо часть сети не поддерживает многоадресную рассылку,
механизм передачи одноадресной рассылки должен испо
странения сообщения rekey для всех членов группы. Сервер ключей отправит
отдельный ключ для каждого члена группы, и член группы должен ответить
серверу ключей сообщением подтверждения. Сервер ключей будет повторять
передачу ключей до тех пор, пока не получит подтверждение от члена группы.
Если после трёх сообщений rekey не удаётся пол
учить ответ от члена группы,
сервер удаляет члена группы.
Сервер ключей поддерживает список зарегистрированных членов группы
в базе данных и отслеживает количество сообщений rekey, которые были отправлены, и подтверждений, полученных от каждого члена группы. Эта база
данных чрезвычайно полезна для устранения неполадок, возникших с конкретным член
ом группы.
Если корпоративная сеть поддерживает многоадресную рассылку, рекомендуется использовать многоадресную отправку сообщения rekey, поскольку
она более масштабируема.
Ниже приводятся некоторые общие рекомендации, которые следует учитывать в отношении отправки rekey-сообщений:
льзоваться для распро-
− если большинство членов группы могут принимать только одноад-
ресную рассылку, используйте отправку одноадресных сообщений rekey;
− если большинство членов группы способны принимать многоадрес-
ную рассылку, и вс
я корпоративная сеть способна реализовывать многоадрес-
ную рассылку, используйте отправку групповых сообщений rekey.
Когда сервер ключей отправляет многоадресные сообщения rekey членам
группы, он отправляет одиночный пакет многоадресной передачи в ядро, и ядро реплицирует пакет для каждого члена группы многоадресной рассылки. Поскольку многоадресные сообщения rekey не требуют подтверждения, соо
бще-
75
ния rekey будут повторно передаваться 2 или 3 раза в течение периода пересоздания ключа. Использование многоадресных сообщений rekey для очень больших сред является более эффективным и масштабируемым решением, поскольку оно использует репликацию многоадресной передачи, обеспечиваемую
ядром. Следовательно, это рекомендуемый метод пересоздания ключей. Многоадресные сообщения rekey также снижает нагрузку на сервер, резко сокращая
количеств
о сообщений, которые он должен обрабатывать.
Когда ключевой сервер использует одноадресные сообщения rekey, то он
генерирует сообщения rekey только для нескольких членов группы за раз и гарантирует, что все члены группы получат сообщение rekey для нового SA до
истечения срока действия старой SA. Это помогает уменьшить вероятность
проблем с задержкой. Кроме того, когда члены группы получают сообщени
е
rekey с сервера ключей, член группы отправляет зашифрованное подтверждение на ключевой сервер, используя ключ, полученный как часть сообщения rekey. Этот процесс постоянно обновляет список активных членов группы и
обеспечивает отправку сообщений с ключами только активным членам группы.
Количество попыток повторной передачи и интервал повторной передачи
дополнительно настраиваются. Как было указано ранее, ключевой сервер удалит член
а группы, если сервер не сможет получить подтверждение все 3 раза.
Член группы должен полностью перерегистрироваться с сервером ключей после того, как истечёт срок действия его IPsec SA, чтобы получать сообщения с
ключами. Если член группы не получает сообщение rekey до истечения срока
действия TEK, он перерегистрируется с сервер
ом ключей до истечения срока
действия активной IPsec SA.
Крайне важно, чтобы члены группы синхронизировали удаление старых
SA и установку новых SA. По мере того, как создаются новые SA после получения сообщения rekey, исходящие пакеты данных по-прежнему шифруются с
использованием старых SA, но входящие пакеты дешифруются с использованием как старых, так и новых SA в течение определённого пери
ода времени.
После определённого количества времени (T1) исходящие пакеты зашифровываются с использованием новых SA, тогда как входящие пакеты всё ещё дешифруются с использованием как старых, так и новых SA в течение определённого периода времени. В течение следующего интервала (T2) старые SA
удаляются, а новые SA шифруют и дешифруют трафик. Для T1 и T2 устанавли-
ся значения до 30 секунд.
вают
6.6. ИНКАПСУЛЯЦИЯ ТРАФИКА
Преимущество GET VPN заключается в том, что эта технология использует существующую инфраструктуру маршрутизации, а не добавляют оверлейных сетей на основе туннелей, как традиционный IPsec. На рисунке 6.1 показано, как пакеты данных GET VPN сохраняют исходный IP-адрес источника и
адреса получателя. Это позволяет организациям использовать существующую
информацию маршрутизации уровня 3, которая может снизить неэффективность многоадресной репликации и повысить производительность сети.
76
Рис. 6.1. Инкапсуляция GET VPN
Шифрование многоадресных пакетов с сохранением IP-адреса необходимо для
сохранения информации (S, G) (Source, Multicast Group; источник, многоадресная группа), так что репликация многоадресных пакетов в ядрах может основываться на исходной (S, G) информации.
6.7. ПРЕИМУЩЕСТВА И ОГРАНИЧЕНИЯ GET VPN
GET VPN имеет следующие преимущества:
− очень масштабируемое решение, поскольку при добавлении членов
группы в полносвязную сеть конфигурация возрастает незначительно;
− обеспечивает масштабируемую поддержку многоадресного трафика.
GET VPN также имеет следующие ограничения:
− VPN-адреса должны быть маршрутизируемы в транспортной сети.
Это связано с использованием оригинального IP-заголовка, и в большинстве
случаев поэтому невозможно использование GET VPN в Интернет
е;
− компрометация одного узла имеет большие последствия, потому что
члены группы имеют сеансовые ключи;
− ключевые серверы должны быть доступны во время повторных гене-
раций ключей и регистрации для операций всех элементов сети.
6.8. ПЛАНИРОВАНИЕ РАЗВЁРТЫВАНИЯ IOS GET VPN
Для успешного развёртывания GET VPN требуется собрать информацию
о среде, а затем принять решения о развёртывании.
Необходимо определить и проанализировать следующие входные параметры при развёртывании GET VPN:
− при использовании существующих устройств убедитесь, что обору-
дование и программное обеспечение на маршрутизаторах можно использовать
77
для выполнения криптографических операций, и что текущий выпуск программного обеспечения поддерживает технологию GET VPN;
− определите требования безопасности для развёртывания защиты
данных (алгоритмы, длины ключей и время жизни ключей);
− тщательно определите потоки трафика, требующие защиты с помо-
щью GET VPN. Некоторые типы трафика должны быть переданы в открытом
виде;
− определите, нужна ли высокая доступность реализуемого решени
я,
и убедитесь, что существует подходящая транспортная сеть и имеется избыточное оборудование.
6.9. ЗАДАЧИ РАЗВЁРТЫВАНИЯ
Основные задачи развёртывания внедрения GET VPN таковы.
Задача 1. Настройте сеансы IKE между каждым членом GET и сервером
ключей.
Задача 2. Настройте политику защиты трафика IPsec на сервере ключей
GET VPN.
Задача 3. Настройте членов GET VPN для регистрации в группе GET
VPN.
6.10. ВАРИАНТЫ РАЗВЁРТЫВАНИЯ
GET VPN требует, чтобы решения принимались на основе сетевых требований и возможностей. Для пиринговой аутентификации IKE выберите использование предварительно разделяемых ключей (PSK) или инфраструктуры открытого ключа (PKI). Предварительно разделяемые ключи проще настроить, но
такой режим в IPsec не обеспечивает поддержку динамически адресуемых членов группы. Высокая доступность может быть достигнута за счёт использования нескольких серверов ключей. Но такой вариа
нт увеличивает накладные
расходы на конфигурацию устройств. Локальные политики должны настраиваться при использовании протоколов динамической маршрутизации или внутриполосных протоколов управления.
6.11. РУКОВОДСТВО ПО РАЗВЁРТЫВАНИЮ
Ниже приведены три основных правила, которые следует учитывать при
реализации GET VPN:
− используйте GET VPN для масштабируемого, межсетевого полно-
связного соединения для большого количества сайтов;
− для внедрения GET VPN в сети Интернет, во всех сетях должны быть
использованы маршрутизируемые IP-адреса;
− отсутствует проблема масштабируемости при развёртывании с ис-
пользованием предварительно разделённых ключей, поскольку требуется только ограниченное к
оличество сеансов IKE (каждый член группы для каждого
ключевого сервера). Другие критерии, такие как требования безопасности,
должны приниматься во внимание при выборе между PSK и PKI.
78
Сервер ключей GET VPN является важной частью архитектуры GET
VPN. Большая часть конфигурации GET VPN выполняется именно на этом сервере. Некоторые элементы конфигурации:
− проверка подлинности членов группы и контроль доступа;
− политика защиты трафика (определение параметров IPsec SA);
− политика пересоздания ключей (одноадресная или многоадресная
рассылка, время жизни ключей, повторные передачи).
Эти элементы конфигурации используются всеми членами групп
ы, если
они не переопределены локальной политикой, настроенной для определённого
члена группы.
Выполните следующую последовательность конфигурации, чтобы на-
строить сервер ключей GET VPN:
Задача 1 (необязательная). Настройте политику IKE. Можно использовать
политику IKE по умолчанию.
Задача 2. Сгенерируйте/настройте учётные данные для всех членов группы.
Задача 3. Создайте или выберите существующие ключи RSA на сервере
ключей для аутентификации пересоздания ключе
й.
Задача 4. Настройте политику защиты трафика.
Задача 5. Включите и настройте функцию сервера ключей GET VPN.
Задача 6 (необязательная). Настройте политику пересоздания ключей
(rekey).
Задача 7. Создайте криптографическую карту GET VPN и примените её
на интерфейсе сервера ключей. Это позволяет серверу ключей прослушивать
запросы регистрации членов группы и распространять настроенную политику
защиты трафика.
Две задачи настройки являются не
обязательными:
1) настройка политики IKE без ограничений. Возможно, потребуется
настроить политику IKE с более высокими параметрами безопасности, чем те,
которые указаны в политике по умолчанию;
2) настройка политики пересоздания ключей для использования одно-
адресной пересылки, поскольку по умолчанию используется многоадресная
рассылка. Эта задача необходима, если транспортная сеть не поддерживает
многоадресную рассылку.
На рисунке 6.2 по
казан сценарий конфигурации, используемый для про-
цесса конфигурирования.
Конфигурационная последовательность включает полную конфигурацию
маршрутизатора сервера ключей со следующей политикой:
− политика IKE, которая использует аутентификацию по предваритель-
но разделяемым ключам для пиров и группу DH 14 для первоначального обмена
ключами. Все остальные параметры IKE будут оставлены по умолчанию;
− в политике защиты трафика сервера ключей будут определены адре-
са источников и получателей из диапазона 10.0.0.0/8, а также шифро
вание AES
128-бит и алгоритм SHA-1 HMAC;
− GET VPN должен использовать одноадресные rekey-сообщения, ко-
торые будут аутентифицироваться с помощью пары ключей RSA, которая
должна быть сгенерирована на сервере ключей для этой цели.
79
Рис. 6.2. Схема топологии для сети GET VPN
Задача 1 состоит в том, чтобы при необходимости создать политику IKE с
помощью глобальной команды crypto isakmp policy. В примере ниже показана
политика IKE, определяющая подписи RSA для аутентификации и группу 14
Диффи–Хеллмана для защиты процесса обмена ключами:
Router(config)# crypto isa kmp policy 10
Router(config-isakmp)# authentication pre-share
Router(config-isakmp)# group 14
Вторая задача настройки сервера ключей заключается в настройке учёт-
ных данных для проверки подлинности. В качестве метода аутентификации будут использоваться предварительно разделяемые ключи. Основной режим IKE
использует уникальный PSK для каждого пира, привязанного к определённому
IP-адресу. В примере ниже показаны соответствующие команды:
Router(config)# crypto isa kmp key ad73asmdkfl902380amadfjkas 172.17.2.4
Router(config)# crypto isa kmp key akjsdfljfdasdfu2389872jh32 172.17.0.1
В задаче 3 создаются ключи, которые будут использоваться для повтор-
ной аутентификации. Чтобы использовать избыточные серверы ключей, сгенерированные ключи должны быть экспортируемыми, чтобы их можно было импортировать на другие серверы ключей. В примере ниже показан процесс генерирования ключей. Обратите внимание, что в сети GET VPN на всех серверах
ключей должны иметь одни и те же пары ключей:
80