antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 14 Февраль , 2010

Cisco GET VPN — новая технология от Cisco, призванная обеспечить безопасность туннелей через провайдерские соединения, обладающая рядом полезных особенностей. Ее описанию, особенностям и настройке и посвящена эта статья.

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

image

Требуется соединить сети за филиалами между собой. Наиболее распространенное решение — IPSec и в частности — DMVPN. Который кроме всего прочего, является туннельной технологией и позволяет использовать публичные Internet каналы. Недостатком такого решения является то, что сеть строится по принципу hub-n-spoke, а туннели spoke-to-spoke устанавливаются по необходимости, что не совсем удобно.

Другим распространенным вариантом является MPLS VPN, который хотя и позволяет построить легко масштабируемую сеть, не обеспечивает требуемую в некоторых случаях конфиденциальность. Cisco GET VPN разработана в большей степени именно для MPLS VPN сетей, позволяя обеспечить шифрование передаваемых данных без ущерба для масштабируемости и достижимости spoke-to-spoke.

Кроме того, сама по себе технология GET VPN не осуществляет туннелирования, т.е. замены заголовка, что практически сводит на нет ее применимость при передаче данных через интернет, поскольку подавляющее большинство хостов во внутренних сетях используют частные IP адреса. В случае же MPLS VPN таких проблем не возникает за счет использования провайдером VPNv4 расширения.

Общие понятия.
В дальнейшем я предполагаю, что читатель знаком с технологией и терминологией IPSec.

Новшеством GET VPN является введение понятия «доверенной группы«, все члены которой разделяют одну и ту же IPSec SA (security association). Это позволяет любому члену группы (GM, group member) расшифровать трафик, зашифрованный любым другим GM. Кроме того, поскольку расшифровать наше сообщение может каждый GM, мы можем рассылать мультикасты.

Для всех GM определяются одни и те же ключи шифрования. Реализуется это с помощью протокола GDOI (Group Domain of Interpretation). Используется два различных ключа: один для шифрования данных, другой для шифрования контрольных сообщений. Пакет, который требуется передать, инкапсулируется ESP с помощью полученного общего ключа.

image

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

За синхронизацию и обновление ключей отвечают сервера ключей (KS, key servers). Все политики шифрования, используемые протоколы, «интересный» трафик, таймеры и т.п. настраиваются на KS и распространяются по всем GM. GM сначала аутентифицируются в IKE Phase 1, а затем получают необходимые данные от KS во время регистрации. Другими словами, на GM настраиваются только параметры IKE Phase 1 и KS. Остальное он получает автоматически.

Кроме того, поскольку KS фактически становится точкой отказа для всей сети, предусмотрена возможность создания нескольких KS, называемые COOP KS(cooperative KS), с возможностью подхватывать функции в режиме холодного резерва.

Переходим от терминологии к собственно настройке GET VPN на Cisco IOS.

Настройка.

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

Конфигурацию GET VPN можно разбить на несколько этапов:

  1. Конфигурация PKI (опционально)
  2. Конфигурация IKE Phase 1
  3. Конфигурация GDOI группы
  4. Конфигурация IPSec profile на KS и crypto map на GM
  5. Конфигурация COOP KS (опционально)

Этап 1. Общий для KS и GM.
Настраиваем роутеры на получение сертификатов от CA. Это тема для отдельной небольшой статьи, поэтому в дальнейшем я буду считать, что сертификаты мы получили. Единственным замечанием будет необходимость делать ключи на KS как exportable, поскольку они должны быть одинаковы для всех COOP KS.

Этап 2. Привычным образом настраиваем crypto isakmp policy. Я опишу политику с использованием PKI, для pre-shared все аналогично.

crypto isakmp policy 10
encr aes
lifetime 1200
group 2

Несколько замечаний.
1) Cisco рекомендует использовать AES, как наилучший по соотношению криптостойкость/ресурсы процессора. Напомню, что по умолчанию, для isakmp policy аутентификация rsa-sig, поэтому строчка с ней не появляется в конфиге.
2) Рекомендованное значение для rekey — 1200 с. Cisco рекомендует делать его в диапазоне 15-30 минут, с дефолтом в 20.

Этап 3. Самая серьезная часть.
3.1. Настройка KS
Создаем gdoi — группу.
crypto gdoi group getvpn

Далее, задаем идентификатор группы. Должен быть одинаковый у всех KS и GM
identity number 1234

Идентифицируем наш роутер как KS
server local

Настраиваем смену IPSec ключей (именно их, а не ISAKMP) раз в сутки
rekey lifetime seconds 86400

Задаем схему повторной передачи при смене ключей (бывают двух видов: два раза с интервалом 60с или три раза с интервалом 40с)
rekey retransmit 40 number 3

Настраиваем аутентификацию.
rekey authentication mypubkey rsa getvpn-export-general
Здесь getvpn-export-general — наши ключи, полученные от CA.

Далее задаем, каким способом обновлять ключи, unicast или multicast.
rekey transport unicast

Далее собственно настраиваем group IPSec SA:
sa ipsec 1

Привязываем профиль IPSec
profile GETVPN_PROFILE

Определяем, что шифровать
match address ipv4 199

Здесь я позволю себе остановиться подробнее. Дело в том, что для традиционных p2p IPSec -туннелей принято описывать интересный трафик наиболее конкретным образом. например, для туннеля между R1 и R2 мы бы написали на R1:
access-list 199 permit ip 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255

Поскольку в GET VPN концов туннелей множество, то и таких записей получится очень много. Поэтому Cisco рекомендует максимально суммаризовать ACE. Например в нашем случае лучше всего записать ACL 199 так:
access-list 199 permit ip 10.0.0.0 0.0.255.255 10.0.0.0 0.0.255.255
Это приведет к значительному сокращению числа SA.

Далее настраиваем TBAR (защита от повторов, основанная на временном окне)
replay time window-size 5

И задаем адрес, с которого будем управлять сменой ключей.
address ipv4 192.168.1.1

3.2. Настройка GM.
Здесь все значительно проще, фактически нам нужно указать, какой группе мы принадлежим (с помощью identity number) и KS этой группы.
crypto gdoi group getvpn
identity number 1234
server address ipv4 192.168.1.1

Этап 4.
4.1. Настройка KS.
На KS необходимо создать настройки, которые будут спущены GM.
crypto ipsec transform-set GETVPN_SET esp-aes esp-sha-hmac
crypto ipsec profile GETVPN_PROFILE
set security-association lifetime seconds 7200
set transform-set GETVPN_SET

4.2 Настройка GM
Надо привязать группу GET VPN к криптокарте.
crypto map getvpn-map 10 gdoi
set group getvpn

Этап 5.  Как уже упоминалось, мы можем сконфигурировать несколько KS, один из которых будет основным, а другие — подхватывать его функции при падении.
Итак, чтобы настроить COOP KS нужно следующее:

  1. Необходимо сконфигурировать RSA ключи на основном KS и экспортировать оба ключа (частный и публичный) на все COOP KSs.
  2. Необходимо настроить собственно redundancy

С ключами, я думаю все знакомы.
Генерируем exportable ключи:
Primary_KS(config)#crypto key generate rsa general-keys label getvpn-keys modulus 1024 exportable

Экспортируем их:
Primary_KS(config)#crypto key export rsa getvpn-keys pem terminal 3des Ci$co

И импортируем на всех COOP KS:
COOP_KS(config)# crypto key import rsa getvpn-keys pem exportable terminal Ci$co

Далее настройка KS.

Обязательно включаем ISAKMP keepalive, чтобы они могли обнаружить смерть друг друга
сrypto isakmp keepalive 15 periodic

Заходим в нашу группу
crypto gdoi group getvpn
server local

Включаем избыточность:
redundancy

Назначаем приоритет (сервер с высшим приоритетом будет primary, если приоритеты равные — primary будет KS c наибольшим IP адресом)
local priority 100

И указываем ему всех остальных KS
peer address ipv4 192.168.2.1
peer address ipv4 192.168.3.1

И настроим таймеры:
protocol timeout refresh 20
protocol timeout periodic 30
protocol retransmit 2

Timeout refresh — интервал, с которым primary KS шлет сообщения остальным. По умолчанию, 20с
Timeout periodic — если в течение этого времени secondary KS не получает refresh сообщения, он информирует все остальные KS о проблемах с primary.
Retransmit — количество сообщений от secondary KS всем остальным KS при не получении сообщения от primary. По умолчанию, отправляется 2 сообщения, после чего KS переопределяют свои роли.

По традиции, несколько замечаний.

  1. COOP KS рассылают свои сообщения на порт UDP 848, при этом в сообщениях содержится информация о всех GM и политиках. Сообщение растет с увеличением числа GM и потребует фрагментации. Для того, чтобы KS нормально обрабатывали такие сообщения, возможно придется увеличить системный буфер:
    buffers huge size 65535
  2. COOP KS должны иметь одинаковую конфигурацию GET VPN. Это не происходит автоматически.
  3. COOP KS могут регистрироваться друг на друге еще и как GM.

В заключение остается только повесить наш crypto map на интерфейс и учесть дополнительные затраты на заголовок:
ip tcp adjust-mss 1360

Таким образом, подводя итоги:

  1. Мы имеем новую технологию, позволяющую шифровать соединения между офисами.
  2. Основная область применения — повышение конфиденциальности MPLS VPN.
  3. Достоинства — нативная поддержка spoke-to-spoke соединений, высокая масштабируемость и поддержка мультикастов.
  4. Недостатки — прямое следствие из отсутствия туннелей — ограниченная до невозможности работа через public Internet.
  5. Особенностью является наличие общих IPSec ключей, позволяющих всем членам группы расшифровывать сообщения, посланные другими членами этой группы.

Опять-таки не претендую на полноту изложения. За кадром остались и поддерживаемые модели роутеров, и много еще чего. Если тема заинтересует — рассмотрим глубже, а пока разрешите на этом откланяться 🙂

Более подробно, можно прочитать здесь: GET VPN Design and Implementation Guide

Илья Подкопаев, инструктор

 

Метки: , ,
Опубликовано: Безопасность cisco , Маршрутизаторы и коммутаторы

 

One Response to “Cisco Group Encrypted Transport Virtual Private Network (GET VPN)”

comment rss - Trackback

  1. flider:

    Статья перемещена в Рубрики «Безопасность» и «Маршрутизаторы»

    Лучше сразу проставлять рубрики и метки.

    СУВЖ,Администратор

» Оставить комментарий

Вы должны войти чтобы прокомментировать.