В настоящей статье я попробовал в максимально доступном и сжатом виде описать что такое IKEv2, FlexVPN и как это реализовано в IOS маршрутизаторов Cisco. Для наилучшего понимания содержания, нужно чтобы читателя, на момент ознакомленимя с нижеприведенным текстом, не пугали такие слова как VPN, IPSec, ISAKMP, ISAKMP Profile и т.д. Кроме того, желательно иметь хорошее представление о том, как настраиваются различные типы VPN с использованием VTI интерфейсов (или GRE over IPSec) на оборудовании Cisco, поскольку статья в значителной степени опирается на знание этих вопросов.
Предисловие
Сразу нужно акцентировать внимание, что не надо думать, что IKEv2 является чем-то совсем новым, сложным для понимания и полностью меняет всю концепцию построения VPN-сетей. IKE(как 1 так и 2) призваны лишь для того чтобы обеспечить ESP (ну или AH, если кому-то нужно) необходимой ключевой информацией, нужной указанным протоколам для непосредственной защиты данных. Сам же ESP, его режимы работы (tunnel/transport) и все связанные понятия не меняются.
Коротко об основных особенностях и отличиях IKEv2 от своего предшественника
Тезисно перечислю наиболее значимые на мой взгляд вещи:
1. Оба протокола работают по UDP/500(4500 в случае с NAT-T), но между собой несовместимы, т.е. не получится так, чтобы на одном конце туннеля был IKEv1, а на другом – IKEv2. При этом один и тот же роутер может терминировать на себе и IKEv2 и IKEv1 туннели одновременно. В заголовках IKEv1 и 2 достаточно различий для того, чтобы роутер смог определить с чем имеет дело, несмотря на одни и те же порты.
2. В IKEv2 больше нет таких понятий как aggressive/main mode, что является одним из аспектов, делающих протокол более простым для понимания.
3. В IKEv2 термин фаза1 заменен на IKE_SA_INIT (обмен двумя сообщениями, обеспечивающий согласование протоколов шифрования/хеширования и генерацию DH ключей), а фаза2 – на IKE_AUTH (тоже два сообщения, реализующие непосредственно аутентификацию пиров и генерацию ключей для ESP). Обмен данными в IKE_AUTH всегда зашифрован с помощью SA, сформированными IKE_SA_INIT. Isakmp SA теперь называются ikev2 sa, а ipsec sa — Child SA.
4. в IKEv2 метод аутентификации между пирами больше не согласовывается автоматически и не привязан к тем или иным политикам IKEv2. Т.е. если раньше в IKEv1 каждой isakmp policy была строка authentication, где указывалось, каков будет тип аутентификации, в случае если будет выбрана именно эта policy, то теперь метод аутентификации задается вручную и явно определяется что вот с этим пиром будет аутентификация по сертификатам, а вот с этим – по pre-shared key. Кроме того, в IKEv2 стала возможна ассимметричная аутентификация. Т.е. можно сделать так, что эндпоинт A будет аутентифицировать эндпоинт B по сертификатам, в то время как B будет аутентифицировать A по pre-shared ключу. Или же А аутентифицирует B с помощью pre-shared key1, в то время как B аутентифицирует A с помощью pre-shared key2. Возможны и другие варианты, в т.ч. аутентификация с использованием различных методов EAP.
5. Mode Config (то, что в ikev1 называлось phase 1.5 и используется для настройки удаленных подключений RAVPN/EasyVPN), NAT-T и keepalives теперь непосредственно описаны в спецификации протокола и являются его неотъемлемой частью. Раньше же эти вещи реализовывались вендорами по своему по мере необходимости.
6. в IKEv2 добавился дополнительный механизм защиты control-plane (services plane) от DoS атак. Суть его в том, что прежде чем отвечать на каждый запрос в установлении защищенного соединения (IKE_SA_INIT) IKEv2 VPN-шлюз шлет источнику такого запроса запроса некий cookie, и ждет, что тот ответит тем же. Если источник ответил – отлично, можно начинать с ним генерацию DH. Если же источник не отвечает (в случае с DoS атакой так и происходит, — это по сути сравнимо с TCP SYN flood attack), VPN-шлюз просто забывает о нем. Без этого механизма, при каждом запросе IKE_SA_INIT IKEv2 от кого угодно VPN-шлюз бы пытался сгенерировать DH ключ (что, как известно, весьма ресуроемкий процесс) и вскоре бы остался с убитой (пусть временно) control-plane.
Что такое FlexVPN?
FlexVPN — это фреймворк, реализющий IKEv2 в IOS маршрутизаторов Cisco. Т.е. это IKEv2+IPSec в синтаксисе команд IOS. Не более того.
Основная фишка, FlexVPN (ключевое слово Flex – Flexible), которую Cisco позиционирует как отличительную особенность FlexVPN, это то, что одна и та же конфигурация VPN-шлюза позволяет цеплять к нему разные типы туннелей – Remote Access, Site-to-Site, etc. Хотя, на мой взгляд, той же (ну или почти той же) flexibility можно добиться и в традиционной IKEv1 настройке, если использовать VTI интерфейсы. Ну да ладно, это все мое ИМХО.
Далее разберем сейчас разберем как выглядит синтаксис FlexVPN, какие комнды он использует, что они означают, для чего нужны, как соотносятся с аналогичными командами в IKEv1.
Синтаксис FlexVPN в части настройки IKEv2
Итак, основные (и, ИМХО, все) компоненты IKEv2 в Cisco IOS, это:
1. Proposal
2. Policy
3. Keyring
4. Profile
Далее о каждом по порядку.
Proposal
IKEv2 proposal пределяет какие алгоритмы будут задействованы для установления/защиты IKE_SA_INIT фазы. По сути своей – это аналог crypto isakmp policy в IKEv1, хотя и не в полной мере.
Выглядит так:
crypto ikev2 proposal PROP_1 encryption aes-cbc-256 aes-cbc-128 3des group 14 5 2 integrity sha 256 sha1 md5
Первое отличие от isakmp policy в том, что в один proposal можно засунуть сразу несколько алгоритмов/длины ключей шифрования/DH/хеширования. Второе отличие, о чем упоминалось ранее – нет строки authentication, поскольку теперь аутентификация – это отдельный вопрос. Третье отличие – proposal не является самостоятельной частью конфига и должен быть помещен в policy.
Policy
IKEv2 Policy – это контейнер для proposal, и не только. Тут сначала пример, а потом поясню:
crypto ikev2 policy POLICY_1 match vrf VRF1 match address local 203.0.113.10 proposal PROP_1
Как видно, policy ссылается на proposal. Но, кроме этого, она добавляет возможность выбрать тот или иной proposal в зависимости от того, 1) в каком VRF находится интерфейс, к которому подключается удаленный пир; 2) к какому локальному адресу подключается удаленный пир. Если сравнить это crypto isakmp policy в IKEv1, то там crypto isakmp policy были глобальными для всех подключений. В принципе отсутствовала возможность сделать так, что для части пиров могут быть использваны только policy 1,2,3 а для другой части 4.5.6. Тут такая возможность есть, хотя и не уверен, что в этом есть большая практическая польза. Но, тем не менее…
Таким образом, еще раз подчеркну:
Crypto ikev2 policy + crypto ikev2 proposal в IKEv2 выполняют ту же роль, что и crypto isakmp policy в IKEv1.
Keyring
IKEv2 Keyring – это репозиторий, в котором хранятся pre-shared ключи. Очевидно, что keyring используется и имеет смысл только если выбран метод аутентификации по pre-shared ключам. В случае, если для аутентификации используется PKI, нужно настраивать не keyring, a Trustpoint. Если провести аналогию с IKEv1, там в самом простом случае для задания pre-shared ключей использовалась такая конструкция:
crypto isakmp key cisco address x.x.x.x 255.255.255.0
Т.е. pre-shared ключи были самостоятельными элементами конфигурации, каждый сам по себе. В IKEv2 же появился своеобразный контейнер, keyring, благодаря чему конфиг выглядит более структурированным, + добавляются некоторые дополнительные возможности.
Пример того, как может выглядеть keyring vpn-шлюза, установленного в HQ, для взаимодействия с двумя удаленными площадками (в отсутствии глубоких навыков рисования таблиц в html, вставил в виде картинки):
Profile
IKEv2 profile лежит в основе FlexVPN и является основной его составляющей. Он определяет «политику» удаленного доступа к VPN-шлюзу. По своему назначению IKEv2 profile – полностью аналогичен IKEv1 isakmp profile в Cisco IOS или tunnel-group (connection profile) если вспомнить ASA, но имеет больше возможностей и более гибок в настройке. Это своеобразный репозиторий параметров, которые не согласовываются участниками VPN-взаимодействия автоматически, а определяются статически. Какие именно функции он выполняет? В процессе установки VPN-соединения, а в частности IKE_INIT_SA VPN-шлюзу нужно знать (цифры в скобках — это не ссылки на список использованной литературы, а ссылки на строки конфига, приведенного ниже):
1. Как аутентифицировать подключающийся пир (PKI? Pre-shared keys?). В IKEv2 тип аутентификации, как я раньше упоминал, – not negotiated, и должен быть явно определен. Во FlexVPN для этого используется ikev2 profile (1).
2. Каковы должны быть параметры dead-peer detection (DPD). В IKEv2 таймеры DPD также не согласовываются автоматически, а задаются вручную в настройках ikev2 profile (2) (хотя могут быть определены глобально).
3. Какой keyring должен быть использован для аутентификации удаленного пира в случае с аутентификацией по pre-shared ключам – это тоже параметр ikev2 profile (3).
4. Какой trustpoint использовать для аутентификации удаленного пира, в случае с PKI-аутентификацией – тоже параметр ikev2 profile (4).
5. Как представить себя удаленному пиру, что выбрать в качестве собственного IKEv2_ID – тоже параметр ikev2 profile (5).
6. В какой iVRF – поместить трафик, после того, как он будет расшифрован (VRF-aware IPSec) – параметр ikev2 profile (6).
Пример IKEv2 профиля:
crypto ikev2 profile profile_name
   match local_address|certificate map|FVRF|IKEv2_ID of remote peer
   authentication {local|remote {rsa-sig|pre-share|ecdsa-sig}} (1)
   dpd interval retry-interval {on-demand|periodic} (2)
   identity local {address|dn|email|fqdn|key-id} (5)
   keyring name (3)
   ivrf name (6)
   pki trustpoint label [sign | verify] (4)
   virtual-template number
Т.е. профиль IKEv2 определяет множество параметров VPN-подключения. И таких профилей в конфигурации может быть множество, и каждый может определять различных набор параметров, в зависимости от того, кто/что подключается к шлюзу (или к кому подключается шлюз). И вот это «в зависимости» определяется директивой match (директив match в одном профиле может быть несколько).
Например, имеем два профиля:
crypto ikev2 profile PROFILE1 match identity remote address 1.1.1.1 далее следует набор параметров профиля PROFILE1 crypto ikev2 profile PROFILE2 match identity remote fqdn remotepeer2.someorg.com далее следует набор параметров профиля PROFILE2
С такой настройкой, когда удаленный пир с Src IP = 1.1.1.1 подключится к локальному шлюзу, к нему (пиру) будут применены параметры, описанные в PROFILE1. Когда к локальному шлюзу подклчючится пир с fqdn=remotepeer2.someorg.com – к нему будут применены параметры, описанные в PROFILE2.
Здесь нужно подвести невидимую черту обязательно сказать, что на этом месте все, что называется IKEv2 в контексте натройки протокола средствами IOS, заканчивается и больше ничего нового не будет. А, можно сделать черту видимой. Вот она:
Что дальше?
Так вот, эти четыре продемонстрированные выше конструкции (policy,proposal,keyring,profile) определяют настройку того, что в IKEv1 называлось phase1. В IKEv2 — это IKE_SA_INIT, но суть абсолютно та же.
Что делать после того, как IKE_SA_INIT настроены? Правильно. Нужно настроить профиль IPSec, определить какой трафик будет ходить через тунель (proxy-ACL или тунельный интерфейс — VTI, где за это отвечает маршрутизация), т.е. выполнить то, что в IKEv1 называлось настройками второй фазы. Эта часть настроек в IKEv1 и в IKEv2 абсолютно идентична. Как выглядит конфиг целиком, приведу ниже на простом примере.
Чтобы совсем не думать
Необходимо упомянуть, что FlexVPN в IOSпо дефолту преднастроен так, что требует минимум действий со стороны администратора для быстрой настройки VPN, если администратору не сильно хочется/лень вникать как все это работает и выполнять какие-то умные настройки. Для этого предназначены так называемые smart-defaults. Smart-defaults – это заранее сконфигурированные дефолтные ikev2 proposal/policy/profile, ipsec profile, etc. Объективно smart-defaults могут быть весьма полезны и имеют право на существование. Зачем постоянно вбивать одни и те же настройки, если они уже есть в конфиге? Посмотреть на них можно выполнив команду sh run all | s crypto. Вывод команды будет примерно такой (часть вывода опущена за ненадобностью):
crypto ikev2 proposal default encryption aes-cbc-256 aes-cbc-192 aes-cbc-128 integrity sha512 sha384 sha256 sha1 md5 group 5 2 crypto ikev2 policy default matchfvrf any proposal default crypto ikev2 natkeepalive 0 crypto ikev2 diagnose error 50 crypto ikev2 dpd 0 0 periodic crypto ikev2 limit max-in-negotation-sa 40 crypto ikev2 limit max-sa 0 crypto ikev2 window 5 crypto ikev2 fragmentation mtu 576 crypto ipsec transform-set default esp-aes esp-sha-hmac mode transport crypto ipsec profile default set security-association lifetime kilobytes 4608000 set security-association lifetime seconds 3600 no set security-association idle-time no set security-association replay window-size
Т.е. видно, что в конфиге по дефолту настроеные и IKEv2 proposal и IKEv2 policy, и IPSec transform-set и IPSec profile. Причем сконфигурированы они так, что высший приоритет имеют наиболее серьезные алгоритмы, что нас вполне устраивает. Естественно, что наибольшую предсказуемость работы VPN обеспечит только ручная настройка всех параметров, но как last-resort — могут быть использованы и дефолтные.
Пример
Дальше рассмотрим достаточно простой пример Site-to-Site VPN с pre-shared аутентификацией. Топология выглядит так:
Нужно настроить IPSec/IKEv2 тунель между маршрутизаторами Site1Router и Site2Router и обеспечить взаимную доступность лупбеков каждого из маршрутизаторов через туннель с использованием динамического протокола муршрутизации.
Конфиг каждого из роутеров в данном случае будет таким:
В данном примере конфиг имеющий отношение к настройке IKEv2 и IPSec выделен цветом. В примере задействованы те самые smart-defaults (см. вывод sh run all выше — т.е. можно просто взять и мысленно дорисовать эти настройки к конфигу каждого роутера), которые задают параметры по умолчанию для IKEv2 policy/proposal, IPSec transform-set. IPSec profile тоже используется дефолтный. В конфиге он ссылается на профиль ikev2 и вешается на туннельный интерфейс для его защиты. В результате конфиг получается довольно компактный и легко читаемый. Как видно из примера, настройка всего, что в IKEv1 имело отношение ко 2 фазе, аналогична таковой в IKEv1. Т.е. создается такой же crypto ipsec transform set (тут взят дефолтный), этот transform-set вместе с ikev2 профилем привязывается к ipsec профилю, ipsec-профиль вешается на интерфейс, работающий в режиме ipsec ipv4 (VTI).
Некоторые команды show
После того, как туннель успешно установился, посмотрим вывод некоторых команд:
Site1Router#sh crypto ipsec sa
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 10.1.12.1
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 10.1.23.3 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 1680, #pkts encrypt: 1680, #pkts digest: 1680
#pkts decaps: 1678, #pkts decrypt: 1678, #pkts verify: 1678
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 10.1.12.1, remote crypto endpt.: 10.1.23.3
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1/0
current outbound spi: 0x31A6B95A(833010010)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0xE6E9033F(3874030399)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 11, flow_id: 11, sibling_flags 80000040, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4268866/1723)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x31A6B95A(833010010)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 12, flow_id: 12, sibling_flags 80000040, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4268866/1723)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
Вывод sh crypto ipsec sa такой же, как если бы мы настраивали традиционный Ikev1, поскольку ESP все равно, кто для него подготавливает ключевую информацию — IKEv2 или IKEv1. Далее:
Site1Router#sh crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 10.1.12.1/500 10.1.23.3/500 none/none READY
Encr: AES-CBC, keysize: 256, Hash: SHA512, DH Grp:5, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/12375 sec
CE id: 1003, Session-id: 2
Status Description: Negotiation done
Local spi: 1625F2D9751CC54F Remote spi: B9C9990767BC0006
Local id: 10.1.12.1
Remote id: 10.1.23.3
Local req msg id: 2 Remote req msg id: 6
Local next msg id: 2 Remote next msg id: 6
Local req queued: 2 Remote req queued: 6
Local window: 5 Remote window: 5
DPD configured for 0 seconds, retry 0
NAT-T is not detected
Cisco Trust Security SGT is disabled
Initiator of SA : No
Тут уже видим специфичную для IKEv2 информацию — использованные алгоритмы шифрования/хеширования/DH группы. Видно также что IKEv2 профиль не был привязан к специфичным VRF (поскольку использовались smart-default). Видно, что инициатором соединения был Site2Router.
Далее:
Site1Router#sh crypto engine connections active
Crypto Engine Connections ID Type Algorithm Encrypt Decrypt LastSeqN IP-Address 11 IPsec AES+SHA 0 223 223 10.1.12.1 12 IPsec AES+SHA 222 0 0 10.1.12.1 1003 IKEv2 SHA512+AES256 0 0 0 10.1.12.1
Тут опять ничего нового. Имеем два unidirectional IPSec SA (строки, начинающиеся с 11 и 12) и один bidirectional IKEv2 SA.
Вывод sh crypto isakmp sa, как и ожидается, ничего не показывает:
Site1Router#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA dst src state conn-id status
Ну вот как-то так. Надеюсь, весь этот текст не оказался слишком запутанным или слишком поверхностным, и будет кому-то полезен.
Автор: Andrew119
