Технические заметки.
На полях сетевых сражений.
Пояснение
вторник, 23 сентября 2014 г.
DPD, Dead Peer Detection.
crypto isakmp keepalive
Итак, DPD или Dead Peer Detection, что же это такое? Как видно из названия, это механизм обнаружения неработающего пира в рамках IKE и IPSec . Но механизм признаться чудной.
DPD был призван решить проблему периодических keepalive, которые при значительном числе spoke роутеров могут вызвать проблемы на центральных VPN-хабах. Да и вообще, это как-то не комильфо и требует внимания к интервалам keepalive запросов.
Стандартизированный в RFC 3706 протокол обнаружения «залипших» пиров, избавлен от этого недостатка и в сути своей непериодичен и асинхронен. А всё потому, что главным критерием определения нерабочего пира является собственно простой установленной IPSec сессии.
Но как это работает?
Следует принять во внимание, что достижение threshold интервала не является необходимым для старта DPD процесса. В RFC по этому поводу сказано следующее: «an entity can initiate a DPD exchange if it has sent outbound IPSec traffic, but not received any inbound IPSec packets in respons». Или, в переводе на русский язык: «процесс обнаружение «залипшего» соседа может начаться если один из участников отправляет пакеты, но не получает ничего в ответ, т.е. до достижения threshold интервала».
Это имеет довольно большое значение для работы в условиях нестабильных каналов. Если мы хотим ослабить реакцию на кратковременные падения линка, улучшив таким образом сходимость, то нам следует не увеличивать threshold интервал, а поднять значение retry-interval. Ведь в случае большой сетевой активности DPD процесс может начаться раньше.
Так-же стоит обращать внимание на данные настройки при организации site-to-site vpn между организациями. Т.к. поведение DPD меняется от вендора к вендору и от платформы к платформе. Например, в Cisco IOS нельзя полностью выключить DPD, лишь перевести в односторонний режим, в котором роутер будет только отвечать на внешние R-U-THERE запросы. А вот Cisco ASA данные keepalive можно отключать совсем.
IPSec всемогущий
История вопроса
Изначально VPN планировался только для организации канала между мини-роутером родителей и домашним «подкроватным» сервером, по совместительству выступающим в роли маршрутизатора.
Спустя небольшой промежуток времени к этой компании из двух устройств добавился Keenetic.
Но единожды начав, остановиться оказалось сложно, и вскоре на схеме появились телефоны и ноутбук, которым захотелось скрыться от всевидящего рекламного ока MT_Free и прочих нешифрованных WiFi-сетей.
Потом у всеми любимого РКН наконец-то окреп банхаммер, которым он несказанно полюбил прилюдно размахивать во все стороны, и для нейтрализации его заботы о простых смертных пришлось поддержать иностранный IT-сектор приобрести VPS за рубежом.
К тому же некоей гражданке, внешне напоминающей Шапокляк, всюду бегающей со своим ридикюлем Пакетом и, вероятно, считающей что «Кто людям помогает — тот тратит время зря. Хорошими делами прославиться нельзя», захотелось тайком подглядывать в чужой трафик и брать его на карандаш. Придется тоже защищаться от такой непрошенной любви и VPN в данном случае именно то, что доктор прописал.
Подведем небольшой итог. Нужно было подобрать решение, которое в идеале способно закрыть сразу несколько поставленных задач:
Обзор существующих решений
Коротко пройдемся по тому что есть сейчас:
Дедушка Ленин всех протоколов. Умер, «разложился на плесень и на липовый мёд».
Кто-то, кроме одного провайдера, это использует?
Проект развивается. Активно пилится. Легко создать туннель между двумя пирами, имеющими статический IP. В остальных случаях на помощь всегда готовы придти костыли, велосипеды с квадратными колёсами и синяя изолента, но это не наш путь.
Приступаем к настройке
Определившись с решением приступаем к настройке. Схема сети в моем случае имеет следующий вид (убрал под спойлер)
ipsecgw.example.com — домашний сервер, являющийся центром сети. Внешний IP 1.1.1.1. Внутренняя сеть 10.0.0.0/23 и еще один адрес 10.255.255.1/30 для установки приватной BGP-сессии с VPS;
mama — Linux-роутер на базе маленького беззвучного неттопа, установленный у родителей. Интернет-провайдер выдает динамический IP-адрес. Внутренняя сеть 10.0.3.0/24;
keenetic — маршрутизатор Keenetic с установленным модулем IPSec. Интернет-провайдер выдает динамический IP-адрес. Внутренняя сеть 10.0.4.0/24;
road-warriors — переносные устройства, подключающиеся из недоверенных сетей. Адреса клиентам выдаются динамически при подключении из внутренного пула (10.1.1.0/24);
rkn.example.com — VPS вне юрисдикции уважаемого РКН. Внешний IP — 5.5.5.5, внутренний адрес 10.255.255.2/30 для установки приватной BGP-сессии.
Первый шаг. От простого к сложному: туннели с использованием pre-shared keys (PSK)
На обоих Linux-box устанавливаем необходимые пакеты:
На обоих хостах открываем порты 500/udp, 4500/udp и разрешаем прохождение протокола ESP.
Правим файл /etc/strongswan/ipsec.secrects (на стороне хоста ipsecgw.example.com) и вносим следующую строку:
На второй стороне аналогично:
В данном случае в качестве ID выступает вымышленный адрес элестронной почты. Больше информации можно подчерпнуть на официальной вики.
Секреты сохранены, движемся дальше.
На хосте ipsecgw.example.com редактируем файл /etc/strongswan/ipsec.conf:
Аналогично редактируем на удаленном пире /etc/strongswan/ipsec.conf:
Если сравнить конфиги, то можно увидеть что они почти зеркальные, перекрёстно поменяны местами только определения пиров.
Директива auto = route заставляет charon установить ловушку для трафика, подпадающего в заданные директивами left/rightsubnet (traffic selectors). Согласование параметров туннеля и обмен ключами начнутся немедленно после появления трафика, попадающего под заданные условия.
На сервере ipsecgw.example.com в настройках firewall запрещаем маскарадинг для сети 10.0.3.0/24. Разрешаем форвардинг пакетов между 10.0.0.0/23 и 10.0.3.0/24 и наоборот. На удаленном узле выполняем аналогичные настройки, запретив маскарадинг для сети 10.0.0.0/23 и настроив форвардинг.
Рестартуем strongswan на обоих серверах и пробуем выполнить ping центрального узла:
Нелишним будет так же убедиться что в файле /etc/strongswan/strongswan.d/charon.conf на всех пирах параметр make_before_break установлен в значение yes. В данном случае демон charon, обслуживающий протокол IKEv2, при выполнении процедуры смены ключей не будет удалять текущую security association, а сперва создаст новую.
Шаг второй. Появление Keenetic
Приятной неожиданностью оказался встроенный IPSec VPN в официальной прошивке Keenetic. Для его активации достаточно перейти в Настройки компонентов KeeneticOS и добавить пакет IPSec VPN.
Готовим настройки на центральном узле, для этого:
Правим /etc/strongswan/ipsec.secrects и добавляем PSK для нового пира:
Правим /etc/strongswan/ipsec.conf и добавляем в конец еще одно соединение:
Со стороны Keenetic настройка выполняется в WebUI по пути: Интернет → Подключения →
Другие подключения. Всё довольно просто.
Если планируется через тоннель гонять существенные объемы трафика, то можно попробовать включить аппаратное ускорение, которое поддерживается многими моделями. Включается командой crypto engine hardware в CLI. Для отключения и обработки процессов шифрования и хеширования при помощи инструкций CPU общего назначения — crypto engine software
После сохранения настроек рестрартуем strongswan и даём подумать полминуты Keenetic-у. После чего в терминале видим успешную установку соединения:
Шаг третий. Защищаем мобильные устройства
После чтения стопки мануалов и кучи статей решено было остановиться на связке бесплатного сертификата от Let’s Encrypt для проверки подлинности сервера и классической авторизации по логину-паролю для клиентов. Тем самым мы избавляемся от необходимости поддерживать собственную PKI-инфраструктуру, следить за сроком истечения сертификатов и проводить лишние телодвижения с мобильными устройствами, устанавливая самоподписанные сертификаты в список доверенных.
Устанавливаем недостающие пакеты:
Получаем standalone сертификат (не забываем предварительно открыть 80/tcp в настройках iptables):
После того как certbot завершил свою работу мы должны научить Strongswan видеть наш сертификат:
Перезапускаем Strongswan и при вызове sudo strongswan listcerts мы должны видеть информацию о сертификате:
После чего описываем новое соединение в ipsec.conf:
Не забываем отредактировать файл /etc/sysconfig/certbot указав, что обновлять сертификат тоже будем как standalone, внеся в него CERTBOT_ARGS=»—standalone».
Так же не забываем включить таймер certbot-renew.timer и установить хук для перезапуска Strongswan в случае выдачи нового сертификата. Для этого либо размещаем простенький bash-скрипт в /etc/letsencrypt/renewal-hooks/deploy/, либо еще раз редактируем файл /etc/sysconfig/certbot.
Перезапускаем Strongswan, включаем в iptables маскарадинг для сети 10.1.1.0/24 и переходим к настройке мобильных устройств.
Android
Устанавливем из Google Play приложение Strongswan.
Запускаем и создаем новый
Сохраняем профиль, подключаемся и, спустя секунду, можем не переживать о том, что кто-то сможет подсматривать за нами.
Windows
Windows актуальных версий приятно удивил. Вся настройка нового VPN происходит путем вызова двух командлетов PowerShell:
И еще одного, в случае если Strongswan настроен на выдачу клиентам IPv6 адреса (да, он это тоже умеет):
Часть четвертая, финальная. Прорубаем окно в Европу
Насмотревшись провайдерских заглушек «Сайт заблокирован по решению левой пятки пятого зампрокурора деревни Трудовые Мозоли Богозабытского уезда» появилась и жила себе одна маленькая неприметная VPS (с благозвучным доменным именем rkn.example.com) в тысяче километров от обезьянок, любящих размахивать банхаммером и блокировать сети размером /16 за раз. И крутилось на этой маленькой VPS прекрасное творение коллег из NIC.CZ под названием BIRD. Птичка первой версии постоянно умирала в панике от активности обезьянок с дубинками, забанивших на пике своей трудовой деятельности почти 4% интернета, уходя в глубокую задумчивость при реконфиге, поэтому была обновлена до версии 2.0.7. Если читателям будет интересно — опубликую статью по переходу с BIRD на BIRD2, в котором кардинально изменился формат конфига, но работать новая вервия стала намного быстрее и нет проблем с реконфигом при большом количестве маршрутов. А раз у нас используется протокол динамической маршрутизации, то должен быть и сетевой интерфейс, через который нужно роутить трафик. По умолчанию IPSec интерфейсов не создает, но за счет его гибкости мы можем воспользоваться классическими GRE-туннелями, которые и будем защищать в дальнейшем. В качестве бонуса — хосты ipsecgw.example.com и rkn.example.com будут аутентифицировать друга друга, используя самообновляемые сертификаты Lets Encrypt. Никаких PSK, только сертификаты, только хардкор, безопасности много не бывает.
Считаем что VPS подготовлена, Strongswan и Certbot уже установлены.
На хосте ipsecgw.example.com (его IP — 1.1.1.1) описываем новый интерфейс gif0:
Зеркально на хосте vps.example.com (его IP — 5.5.5.5):
Поднимаем интерфейсы, но поскольку в iptables нет правила, разрешающего GRE-протокол, трафик ходить не будет (что нам и надо, поскольку внутри GRE нет никакой защиты от любителей всяких законодательных «пакетов»).
Готовим VPS
Первым делом получаем еще один сертификат на доменное имя rkn.example.com. Создаем симлинки в /etc/strongswan/ipsec.d как описано в предыдущем разделе.
Правим ipsec.secrets, внося в него единственную строку:
На стороне хоста ipsecgw.example.com тоже добавляем в ipsec.conf в секцию setup параметр strictcrlpolicy = yes, включающий строгую проверку CRL. И описываем еще одно соединение:
Конфиги почти зеркальные. Внимательный читатель мог сам уже обратить внимание на пару моментов:
/rkn.example.com.pem, после чего при помощи scp перекрестно копируем их между серверами в расположения, указаные в конфиге
Не забываем настроить файрвол и автообновление сертификатов. После перезапуска Strongswan на обоих серверах, запустим ping удаленной стороны GRE-туннеля и увидим успешную установку соединения. На VPS (rkn):
И на стороне хоста ipsecgw
Туннель установлен, пинги ходят, в tcpdump видно что между хостами ходит только ESP. Казалось бы можно радоваться. Но нельзя расслабляться не проверив всё до конца. Пробуем перевыпустить сертификат на VPS и…
Шеф, всё сломалось
Начинаем разбираться и натыкаемся на одну неприятную особенность прекрасного во всём остальном Let’s Encrypt — при любом перевыпуске сертификата меняется так же ассоциированный с ним закрытый ключ. Изменился закрытый ключ — изменился и открытый. На первый взгляд ситуация для нас безвыходная: если даже открытый ключ мы можем легко извлечь во время перевыпуска сертификата при помощи хука в certbot и передать его удаленной стороне через SSH, то непонятно как заставить удаленный Strongswan перечитать его. Но помощь пришла откуда не ждали — systemd умеет следить за изменениями файловой системы и запускать ассоциированные с событием службы. Этим мы и воспользуемся.
Создадим на каждом из хостов служебного пользователя keywatcher с максимально урезанными правами, сгенерируем каждому из них SSH-ключи и обменяемся ими между хостами.
На хосте ipsecgw.example.com создадим каталог /opt/ipsec-pubkey в котором разместим 2 скрипта.
На VPS (хосте rkn.example.com) аналогично создаем каталог с тем же именем, в котором тоже создаем аналогичные скрипты, изменяя только название ключа. Код, чтобы не загромождать статью, под
sudo vi /opt/ipsec-pubkey/pubkey-copy.sh
Скрипт pubkey-copy.sh нужен для извлечения открытой части ключа и копирования его удаленному хосту во время выпуска нового сертификата. Для этого в каталоге /etc/letsencrypt/renewal-hooks/deploy на обоих серверах создаем еще один микроскрипт:
Половина проблемы решена, сертификаты перевыпускаются, публичные ключи извлекаются и копируются между серверами и пришло время systemd с его path-юнитами.
На сервере ipsecgw.example.com в каталоге /etc/systemd/system создаем файл keyupdater.path
Аналогично на VPS хосте:
И, напоследок, на каждом сервере создаем ассоциированную с данным юнитом службу, которая будет запускаться при выполнении условия (PathChanged) — изменении файла и его закрытии его после записи. Создаем файлы /etc/systemd/system/keyupdater.service и прописываем:
Не забываем перечитать конфигурации systemd при помощи sudo systemctl daemon-reload и назначить path-юнитам автозапуск через sudo systemctl enable keyupdater.path && sudo systemctl start keyupdater.path.
Как только удаленный хост запишет файл, содержащий публичный ключ, в домашний каталог пользователя keywatcher и файловый дескриптор будет закрыт, systemd автоматически запустит соответствующую службу, которая скопирует ключ в нужное расположение и перезапустит Strongswan. Туннель будет установлен, используя правильный открытый ключ второй стороны.
Можно выдохнуть и наслаждаться результатом.
Вместо заключения
Как мы только что увидели чёрт IPSec не так страшен, как его малюют. Всё, что было описано — полностью рабочая конфигурация, которая используется в настоящее время. Даже без особых знаний можно настроить VPN и надежно защитить свои данные.
Конечно за рамками статьи остались моменты настройки iptables, но и сама статья уже получилась и без того объемная и про iptables написано много.
Есть в статье и моменты, которые можно улучшить, будь-то отказ от перезапусков демона Strongswan, перечитывая его конфиги и сертификаты, но у меня не получилось этого добиться.
Впрочем и рестарты демона оказались не страшны: происходит потеря одного-двух пингов между пирами, мобильные клиенты тоже сами восстанавливают соединение.
Надеюсь коллеги в комментариях подскажут правильное решение.
Настойка можжевельника: готовим Juniper SRX. Часть 2: IPSec
На схеме видим центральный офис и подключенную к нему ноду — это может быть как филиал, так и какой-то удаленный заказчик/клиент, для связи с которыми требуется защищенное соединение. Разумеется, их может быть несколько (об этом ниже). Способ связи при этом нам абсолютно не важен: хоть Интернет, хоть «темное волокно» — данные все равно нужно шифровать, чтобы свести к нулюминимуму риск их утечки. И чем выше стойкость шифра и совершенней способ фильтрации, тем целее будут нервы администратора (как вы, наверное, знаете, сисадмин, как и любая замкнутая система, всегда стремится к состоянию покоя).
Главным отличием ipsec от того же шифрованного ovpn или pptp является гораздо более высокая степень устойчивости ко взлому, а также гораздо более широкая степень унификации и распространенности. Связать две железки site-to-site, если нужен канал с шифрованием, через ipsec гораздо проще, нежели поднимать между ними ppp-соединение. Потому что ipsec умеют почти все роутеры умнее домашней мыльницы (есть и специальные VPN-шлюзы), а вот с ppp-соединениями всегда возможны нюансы. А для подключения удаленных сотрудников можно применить комбинацию этих решений, типа Cisco Anyconnect или L2tp/ipsec — с их помощью можно создать защищенное соединение непосредственно с клиентского устройства, а не с роутера.
Процесс установления защищенного туннеля состоит из двух фаз: сначала устройства «узнают» друг друга с помощью IKE и договариваются об используемом типе шифрования, контроле целостности и аутентификации, после чего переходят ко второй фазе.
На втором этапе строится основной туннель для данных (при этом соединение, поднятое в первой фазе, используется для обновления SA).
Подробнее про IPSec можно прочитать, например в седьмом выпуске СДСМ, мы же займемся практикой.
IPSec VPN (в нашем случае мы рассматриваем только туннельный режим site-to-site) в Juniper SRX бывает двух видов: Policy based и Routed based. Отличия между ними можно почитать в официальной Juniper KB на английском.
Я буду использовать в своем примере свою HA-пару Juniper SRX, про которую можно почитать вот тут. Там же есть конфигурация интерфейсов (на схеме интерфейсы тоже подписаны).
1. Policy based VPN
Проще всего в конфигурации, и нужен, когда, например, требуется связать две сети друг с другом. При этом нет перекрытия сетей друг с другом и не используется NAT.
Настраивается, в общем-то, элементарно (комментарии в самом конфиге). Я подразумеваю, что читатель представляет, что такое IPSec, и хотя бы раз его настраивал.
Такая схема эффективна, например, для связи с одним мелким филиалом через Интернет. При этом обе сети видят друг друга абсолютно прозрачно. В общем-то, это аналог обычного cisco-like ipsec без лишних приукрашиваний или усложнений. Заметное отличие — разрешающих политик нужно две, а не одна, иначе не заработает.
2. Route-based
Гораздо интересней с Route-based. При этом используется специальный туннельный интерфейс, соответственно, получаем возможность делать NAT (dst, src, static), организовывать схемы hub-and-spoke и т.д. Аналогом будет IPSec VTI и, отчасти, DMVPN (заявлена реализация hub-and-spoke, но сравнить с DMVPN не представляется возможным, потому что SRX всего один стоит только в HQ).
В схему выше добавим одно условие: все адреса нашей локалки будут транслироваться в один. Допустим, 192.168.100.100. Делается это обычно затем, чтобы не превращать acl на стороне заказчика в лютую портянку.
Будем считать, что на удаленную сторону влиять мы можем крайне ограниченно (сменить PSK или уточнить параметры криптотуннеля, но не более того).
Но что делать, если доступ нужно получить больше чем к одному серверу на удаленной стороне? На каждую пару source/destination необходим отдельный vpn-инстанс. К счастью, только он. Все остальные параметры (policy/proposal/gateway) можно оставить прежними.
Обратите внимание: unit остается тот же, мы просто добавляем к нему еще один vpn-туннель. А вот если понадобится построить ipsec-туннель с другим клиентом, то логичней будет выделить его в отдельный unit.
Ну а теперь добавляем policy и NAT. Т.к. st0.1 у нас в отдельной зоне, то policy мы строим не в untrust, а в VPN.
Security-policy в таком виде создается исключительно для тестов! В дальнейшем доступ должен быть ограничен в соответствии с требованиями безопастности.
Если нужен доступ только «в одну сторону», то «обратную» policy создавать необязательно.
SA устанавливаются, пакетики бегают, канал работает.
На этом все. Удачи в настройке!
IKEv2 и Flex VPN средствами Cisco IOS. Синтаксис и логика работы
В настоящей статье я попробовал в максимально доступном и сжатом виде описать что такое IKEv2, FlexVPN и как это реализовано в IOS маршрутизаторов Cisco. Для наилучшего понимания содержания, нужно чтобы читателя, на момент ознакомленимя с нижеприведенным текстом, не пугали такие слова как VPN, IPSec, ISAKMP, ISAKMP Profile и т.д. Кроме того, желательно иметь хорошее представление о том, как настраиваются различные типы VPN с использованием VTI интерфейсов (или GRE over IPSec) на оборудовании Cisco, поскольку статья в значителной степени опирается на знание этих вопросов.
Предисловие
Коротко об основных особенностях и отличиях 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
Далее о каждом по порядку.
IKEv2 proposal пределяет какие алгоритмы будут задействованы для установления/защиты IKE_SA_INIT фазы. По сути своей – это аналог crypto isakmp policy в IKEv1, хотя и не в полной мере.
Выглядит так:
Первое отличие от isakmp policy в том, что в один proposal можно засунуть сразу несколько алгоритмов/длины ключей шифрования/DH/хеширования. Второе отличие, о чем упоминалось ранее – нет строки authentication, поскольку теперь аутентификация – это отдельный вопрос. Третье отличие – proposal не является самостоятельной частью конфига и должен быть помещен в policy.
IKEv2 Policy – это контейнер для proposal, и не только. Тут сначала пример, а потом поясню:
Как видно, 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.
IKEv2 Keyring – это репозиторий, в котором хранятся pre-shared ключи. Очевидно, что keyring используется и имеет смысл только если выбран метод аутентификации по pre-shared ключам. В случае, если для аутентификации используется PKI, нужно настраивать не keyring, a Trustpoint. Если провести аналогию с IKEv1, там в самом простом случае для задания pre-shared ключей использовалась такая конструкция:
Т.е. pre-shared ключи были самостоятельными элементами конфигурации, каждый сам по себе. В IKEv2 же появился своеобразный контейнер, keyring, благодаря чему конфиг выглядит более структурированным, + добавляются некоторые дополнительные возможности.
Пример того, как может выглядеть keyring vpn-шлюза, установленного в HQ, для взаимодействия с двумя удаленными площадками (в отсутствии глубоких навыков рисования таблиц в html, вставил в виде картинки):
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
   dpd interval retry-interval
   identity local
   keyring name (3)
   ivrf name (6)
   pki trustpoint label [sign | verify] (4)
   virtual-template number
Т.е. профиль IKEv2 определяет множество параметров VPN-подключения. И таких профилей в конфигурации может быть множество, и каждый может определять различных набор параметров, в зависимости от того, кто/что подключается к шлюзу (или к кому подключается шлюз). И вот это «в зависимости» определяется директивой match (директив match в одном профиле может быть несколько).
Например, имеем два профиля:
С такой настройкой, когда удаленный пир с 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. Вывод команды будет примерно такой (часть вывода опущена за ненадобностью):
Т.е. видно, что в конфиге по дефолту настроеные и 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
Вывод sh crypto ipsec sa такой же, как если бы мы настраивали традиционный Ikev1, поскольку ESP все равно, кто для него подготавливает ключевую информацию — IKEv2 или IKEv1. Далее:
Site1Router#sh crypto ikev2 sa detailed
Тут уже видим специфичную для IKEv2 информацию — использованные алгоритмы шифрования/хеширования/DH группы. Видно также что IKEv2 профиль не был привязан к специфичным VRF (поскольку использовались smart-default). Видно, что инициатором соединения был Site2Router.
Site1Router#sh crypto engine connections active
Тут опять ничего нового. Имеем два unidirectional IPSec SA (строки, начинающиеся с 11 и 12) и один bidirectional IKEv2 SA.
Вывод sh crypto isakmp sa, как и ожидается, ничего не показывает:
Site1Router#sh crypto isakmp sa
Ну вот как-то так. Надеюсь, весь этот текст не оказался слишком запутанным или слишком поверхностным, и будет кому-то полезен.
