IKEv2 на Cisco IOS 12.4T: перестроили site-to-site VPN и перестали следить за туннелями

Клиент - торговая компания, три офиса в разных городах. VPN между площадками работал на Cisco ISR, IKEv1, ISAKMP с pre-shared keys. Схема стандартная, работала несколько лет, но доставляла головную боль в определённых ситуациях: туннели иногда зависали в полуживом состоянии, dead peer detection не всегда успевал их сбрасывать, и тогда трафик уходил в никуда до тех пор, пока кто-нибудь не замечал и не делал clear crypto isakmp вручную.

Поддержка IKEv2 появилась в Cisco IOS 12.4(20)T - это достаточно свежий трейн, вышел в конце прошлого года. Мы давно смотрели на него, но не торопились: новый протокол на продуктивной инфраструктуре без острой необходимости трогать не хочется. Острая необходимость появилась в марте, когда один из туннелей за неделю три раза завис и его пришлось поднимать руками. Решили перейти.

Чем IKEv2 отличается от IKEv1 на практике

IKEv1 согласовывает туннель в две фазы: ISAKMP SA (фаза 1) и IPsec SA (фаза 2). Количество round-trip при этом варьируется в зависимости от режима - main mode делает шесть пакетов, aggressive mode три, но с компромиссами по безопасности. IKEv2 убрал эту двухфазность. Есть один обмен IKE_SA_INIT (два пакета) и IKE_AUTH (два пакета) - и туннель готов. Итого четыре пакета против шести в лучшем случае.

Это звучит как незначительная деталь, но при нестабильных WAN-каналах каждый лишний round-trip - это ещё одна точка отказа. Меньше пакетов для согласования - выше вероятность, что туннель поднимется с первой попытки.

Важнее для нас было другое: DPD в IKEv2 встроен в протокол как первоклассный механизм, а не прикручен сбоку как в IKEv1. В IKEv1 dead peer detection - это расширение, которое каждый вендор реализовывал немного по-своему, и поведение при потере пира могло отличаться. В IKEv2 liveness check - часть спецификации. Если пир не отвечает - сессия считается мёртвой и сбрасывается. Без двусмысленности.

Как переходили

На стороне Cisco конфигурация IKEv2 выглядит иначе, чем IKEv1. Вместо crypto isakmp policy - crypto ikev2 proposal и crypto ikev2 policy. Профиль туннеля теперь crypto ikev2 profile, а не crypto isakmp profile. Структура параметров та же - алгоритмы шифрования, хеши, DH-группы - но синтаксис другой, и скопировать старый конфиг не выйдет.

Делали поочерёдно по каждой паре офисов. Схема была такая:

• Готовим новый конфиг на обеих сторонах, проверяем на стенде (у нас есть пара ISR в лабе).
• Переводим в maintenance window - поздно вечером, трафика между офисами почти нет.
• Убираем старый crypto map, применяем новый с IKEv2.
• Проверяем show crypto ikev2 sa и show crypto ipsec sa - туннель должен быть established.
• Ждём 15-20 минут, прогоняем пинги и несколько тест-запросов к ресурсам через туннель.

Первая пара офисов прошла чисто. На второй паре столкнулись с тем, что один из маршрутизаторов был на IOS 12.4(15)T, который IKEv2 не поддерживает - пришлось сначала обновить образ. Это заняло дополнительный час, но в окно уложились.

Что изменилось

Прошло около двух недель с момента перехода. Наблюдения пока такие:

• Туннели не зависали ни разу. Это не окончательный вывод - двух недель мало для статистики - но за предыдущий месяц было три инцидента, а сейчас тихо.
• DPD работает предсказуемо. Специально проверяли: отключали интерфейс на одной стороне, смотрели, через сколько маршрутизатор на другой стороне почистит SA. В IKEv1 это иногда занимало несколько минут с непонятными промежуточными состояниями. С IKEv2 сессия сбрасывается по таймауту чисто, без артефактов.
• Время поднятия туннеля сократилось. Сложно дать точную цифру - нагрузка и задержки на WAN варьируются - но субъективно туннель выходит в established быстрее.
• Конфигурация стала читаемее. IKEv2 profile явно связывает параметры аутентификации, proposal и match-критерий в одном месте. Старый конфиг с ISAKMP был разбросан по нескольким секциям, и разобраться что к чему - отдельное упражнение.

Где споткнулись

Pre-shared keys в IKEv2 на Cisco конфигурируются в crypto ikev2 keyring, а не через crypto isakmp key. Синтаксис немного неочевидный при первом знакомстве - peer задаётся по адресу или маске, ключ внутри блока peer. Если работаете с несколькими туннелями к разным адресам - нужно аккуратно структурировать keyring, иначе легко запутаться.

Второй момент - crypto ikev2 profile нужно явно привязать к crypto ipsec profile, который в свою очередь используется в tunnel interface или crypto map. Цепочка длиннее, чем в IKEv1, и если что-то не привязано - туннель просто не поднимается без внятного сообщения об ошибке. debug crypto ikev2 помогает, но вывод объёмный.

Что дальше

Третья пара площадок у клиента пока остаётся на IKEv1 - там стоит более старое железо, которое потребует обновления IOS перед переходом. Запланировали на следующий месяц.

По части сопровождения инфраструктуры переход на IKEv2 интересен прежде всего тем, что снижает количество ручных вмешательств: меньше зависших туннелей - меньше ночных звонков. Это, пожалуй, главный аргумент в пользу перехода, если VPN работает на достаточно свежем IOS и железе его поддерживает.