Cisco GET VPN — новая технология от Cisco, призванная обеспечить безопасность туннелей через провайдерские соединения, обладающая рядом полезных особенностей. Ее описанию, особенностям и настройке и посвящена эта статья.
Начнем по традиции с постановки задачи. Классическая топология представляет собой несколько филиалов, соединенных с помощью провайдерской сети.
Требуется соединить сети за филиалами между собой. Наиболее распространенное решение — 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 с помощью полученного общего ключа.
На рисунке видно, что исходный заголовок ничем не заменяется, отсюда ограничение по использованию в Интернет.
За синхронизацию и обновление ключей отвечают сервера ключей (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. Общий для KS и GM.
Настраиваем роутеры на получение сертификатов от CA. Это тема для отдельной небольшой статьи, поэтому в дальнейшем я буду считать, что сертификаты мы получили. Единственным замечанием будет необходимость делать ключи на KS как exportable, поскольку они должны быть одинаковы для всех COOP KS.
Этап 2. Привычным образом настраиваем crypto isakmp policy. Я опишу политику с использованием PKI, для pre-shared все аналогично.
Несколько замечаний.
1) Cisco рекомендует использовать AES, как наилучший по соотношению криптостойкость/ресурсы процессора. Напомню, что по умолчанию, для isakmp policy аутентификация rsa-sig, поэтому строчка с ней не появляется в конфиге.
2) Рекомендованное значение для rekey — 1200 с. Cisco рекомендует делать его в диапазоне 15-30 минут, с дефолтом в 20.
Этап 3. Самая серьезная часть.
3.1. Настройка KS
Создаем gdoi — группу.
Далее, задаем идентификатор группы. Должен быть одинаковый у всех KS и GM
Идентифицируем наш роутер как KS
Настраиваем смену IPSec ключей (именно их, а не ISAKMP) раз в сутки
Задаем схему повторной передачи при смене ключей (бывают двух видов: два раза с интервалом 60с или три раза с интервалом 40с)
Настраиваем аутентификацию.
Здесь getvpn-export-general — наши ключи, полученные от CA.
Далее задаем, каким способом обновлять ключи, unicast или multicast.
Далее собственно настраиваем group IPSec SA:
Привязываем профиль IPSec
Определяем, что шифровать
Здесь я позволю себе остановиться подробнее. Дело в том, что для традиционных p2p IPSec -туннелей принято описывать интересный трафик наиболее конкретным образом. например, для туннеля между R1 и R2 мы бы написали на R1:
Поскольку в GET VPN концов туннелей множество, то и таких записей получится очень много. Поэтому Cisco рекомендует максимально суммаризовать ACE. Например в нашем случае лучше всего записать ACL 199 так:
Это приведет к значительному сокращению числа SA.
Далее настраиваем TBAR (защита от повторов, основанная на временном окне)
И задаем адрес, с которого будем управлять сменой ключей.
3.2. Настройка GM.
Здесь все значительно проще, фактически нам нужно указать, какой группе мы принадлежим (с помощью identity number) и KS этой группы.
Этап 4.
4.1. Настройка KS.
На KS необходимо создать настройки, которые будут спущены GM.
4.2 Настройка GM
Надо привязать группу GET VPN к криптокарте.
Этап 5.Оставим для еще одной статьи, если тема заинтересует :) Раз заинтересовала — давайте рассмотрим. Как уже упоминалось, мы можем сконфигурировать несколько KS, один из которых будет основным, а другие — подхватывать его функции при падении.
Итак, чтобы настроить COOP KS нужно следующее:
С ключами, я думаю все знакомы.
Генерируем exportable ключи:
Экспортируем их:
И импортируем на всех COOP KS:
Обязательно включаем ISAKMP keepalive, чтобы они могли обнаружить смерть друг друга
Заходим в нашу группу
Включаем избыточность:
Назначаем приоритет (сервер с высшим приоритетом будет primary, если приоритеты равные — primary будет KS c наибольшим IP адресом)
И указываем ему всех остальных KS
И настроим таймеры:
Timeout refresh — интервал, с которым primary KS шлет сообщения остальным. По умолчанию, 20с
Timeout periodic — если в течение этого времени secondary KS не получает refresh сообщения, он информирует все остальные KS о проблемах с primary.
Retransmit — количество сообщений от secondary KS всем остальным KS при не получении сообщения от primary. По умолчанию, отправляется 2 сообщения, после чего KS переопределяют свои роли.
По традиции, несколько замечаний.
В заключение остается только повесить наш crypto map на интерфейс и учесть дополнительные затраты на заголовок:
Таким образом, подводя итоги:
Опять-таки не претендую на полноту изложения. За кадром остались и настройка COOP KS, и поддерживаемые модели роутеров и много еще чего. Если тема заинтересует — рассмотрим глубже, а пока разрешите на этом откланяться :)
Более подробно, можно прочитать здесь: GET VPN Design and Implementation Guide
UPD 1. Спасибо за ценные замечания quickshooter и Fedia
Подкопаев Илья, инструктор
Начнем по традиции с постановки задачи. Классическая топология представляет собой несколько филиалов, соединенных с помощью провайдерской сети.
Требуется соединить сети за филиалами между собой. Наиболее распространенное решение — 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 с помощью полученного общего ключа.
На рисунке видно, что исходный заголовок ничем не заменяется, отсюда ограничение по использованию в Интернет.
За синхронизацию и обновление ключей отвечают сервера ключей (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 можно разбить на несколько этапов:
- Конфигурация PKI (опционально)
- Конфигурация IKE Phase 1
- Конфигурация GDOI группы
- Конфигурация IPSec profile на KS и crypto map на GM
- Конфигурация 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.13.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.
Итак, чтобы настроить COOP KS нужно следующее:
- Необходимо сконфигурировать RSA ключи на основном KS и экспортировать оба ключа (частный и публичный) на все COOP KSs.
- Необходимо настроить собственно 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 2Timeout refresh — интервал, с которым primary KS шлет сообщения остальным. По умолчанию, 20с
Timeout periodic — если в течение этого времени secondary KS не получает refresh сообщения, он информирует все остальные KS о проблемах с primary.
Retransmit — количество сообщений от secondary KS всем остальным KS при не получении сообщения от primary. По умолчанию, отправляется 2 сообщения, после чего KS переопределяют свои роли.
По традиции, несколько замечаний.
- COOP KS рассылают свои сообщения на порт UDP 848, при этом в сообщениях содержится информация о всех GM и политиках. Сообщение растет с увеличением числа GM и потребует фрагментации. Для того, чтобы KS нормально обрабатывали такие сообщения, возможно придется увеличить системный буфер:
buffers huge size 65535 - COOP KS должны иметь одинаковую конфигурацию GET VPN. Это не происходит автоматически.
- COOP KS могут регистрироваться друг на друге еще и как GM.
В заключение остается только повесить наш crypto map на интерфейс и учесть дополнительные затраты на заголовок:
ip tcp adjust-mss 1360Таким образом, подводя итоги:
- Мы имеем новую технологию, позволяющую шифровать соединения между офисами.
- Основная область применения — повышение конфиденциальности MPLS VPN.
- Достоинства — нативная поддержка spoke-to-spoke соединений, высокая масштабируемость и поддержка мультикастов.
- Недостатки — прямое следствие из отсутствия туннелей — ограниченная до невозможности работа через public Internet.
- Особенностью является наличие общих IPSec ключей, позволяющих всем членам группы расшифровывать сообщения, посланные другими членами этой группы.
Опять-таки не претендую на полноту изложения. За кадром остались и настройка COOP KS, и поддерживаемые модели роутеров и много еще чего. Если тема заинтересует — рассмотрим глубже, а пока разрешите на этом откланяться :)
Более подробно, можно прочитать здесь: GET VPN Design and Implementation Guide
UPD 1. Спасибо за ценные замечания quickshooter и Fedia
Подкопаев Илья, инструктор