IPsec/IKEv2 на strongSwan: мигрируем site-to-site с OpenVPN

OpenVPN у нас появился в районе 2008 года и с тех пор прижился намертво. Удобен в настройке, кросс-платформенный, работает поверх TCP/443 когда надо - в общем, универсальный инструмент. Проблемы начались, когда клиентская сеть выросла до нескольких площадок с постоянными туннелями и к ним добавились Windows-ноутбуки разъездных сотрудников.

Два болевых момента проявились почти одновременно.

Первый - производительность. Site-to-site туннели на OpenVPN работают в user-space, и это ощущается при шифровании большого трафика между площадками. Канал между офисами утилизируется, а CPU на шлюзах уходит в потолок при активных передачах файлов или резервном копировании через туннель.

Второй - Windows. Чтобы подключить Windows 7 к OpenVPN, нужно поставить клиент. Звучит несерьёзно, но на практике это: дистрибутив нужно где-то хранить, раскатывать через GPO или вручную, поддерживать версии. Часть пользователей работает на корпоративных ноутбуках с ограниченными правами, и установка дополнительного ПО превращается в задачу для ИТ. А главное - Windows 7 и 8 умеют IKEv2 из коробки, встроенный клиент без лишнего софта.

Начали смотреть в сторону IPsec. IKEv2 - второе поколение протокола обмена ключами, появился в 2005 году в RFC 4306. По сравнению с IKEv1 - заметно проще в реализации, надёжнее восстановление после разрыва соединения (MOBIKE), нормально работает за NAT. strongSwan 5.x, ветка которого началась в 2012 году, поддерживает IKEv2 полноценно и активно развивается.

Почему именно strongSwan

На Linux для IPsec есть несколько вариантов: Openswan (уже давно без активной разработки), Libreswan (форк Openswan), strongSwan. Потыкав в каждый, остановились на strongSwan по нескольким причинам.

• Документация - по IKEv2 у strongSwan она внятная, есть примеры под конкретные сценарии.
• Активная разработка - коммиты идут регулярно, Issues разбираются.
• Плагинная архитектура - можно включить только нужное, не тащить лишнее.
• Поддержка EAP - для road warrior через Windows-клиент это важно, можно аутентифицировать через MSCHAPv2 или EAP-TLS.

Site-to-site: как настраивали

Первый туннель подняли между двумя Linux-шлюзами - это самый простой случай, аутентификация через PSK или сертификаты X.509. Выбрали сертификаты: PSK с несколькими площадками превращается в управленческий кошмар.

Схема с сертификатами выглядит так:

Площадка A (strongSwan 5.1)  <-- IKEv2/IPsec -->  Площадка B (strongSwan 5.1)
       |                                                      |
   LAN A: 10.1.0.0/24                               LAN B: 10.2.0.0/24

Конфигурация в /etc/ipsec.conf для площадки A:

conn site-b
    keyexchange=ikev2
    left=%defaultroute
    leftid=@site-a.example.com
    leftcert=site-a-cert.pem
    leftsubnet=10.1.0.0/24
    right=<IP площадки B>
    rightid=@site-b.example.com
    rightcert=site-b-cert.pem
    rightsubnet=10.2.0.0/24
    ike=aes256-sha256-modp2048!
    esp=aes256-sha256!
    auto=start

Восклицательный знак после параметров шифрования - это строгий режим: не согласовывать ничего кроме указанного. Без него strongSwan может договориться на что попало, если на другой стороне либеральная конфигурация.

Запустили, подняло туннель за несколько секунд. ipsec statusall показывает активные SA и детали согласования - значительно информативнее чем дебажить OpenVPN через логи.

Производительность

IPsec работает в kernel space - это принципиальное отличие от OpenVPN. Шифрование AES на современных CPU с AES-NI инструкциями обрабатывается аппаратно, нагрузка на ядро при шифровании заметно ниже. На практике: при активной передаче между площадками CPU на шлюзах перестал быть узким местом. Дать точные цифры не буду - измерения делали в рабочей сети в не самых контролируемых условиях, но разница ощутимая.

Windows 7/8 без клиента

Вот где IKEv2 берёт своё. В Windows 7 и 8 встроен клиент IKEv2, настраивается через стандартные «Сетевые подключения» или PowerShell. Для road warrior через EAP-MSCHAPv2 пользователь вводит логин и пароль - привычный сценарий, никакого дополнительного ПО.

На стороне strongSwan для этого нужен charon с плагином eap-mschapv2 и правильный profiling сертификата сервера - Extended Key Usage должен содержать Server Authentication. Нюанс с Windows: он проверяет EKU и откажется подключаться если сертификат его не содержит. Половину первого дня потратили на выяснение именно этого.

Раскатать конфигурацию на Windows-машины можно через GPO - профиль VPN задаётся XML-файлом, который импортируется скриптом. Это решает проблему ручной настройки.

Что не так просто

Отладка IPsec требует привычки. ipsec stroke loglevel charon 3 выдаёт подробный лог переговоров IKE, но разобраться в нём с первого раза непросто - протокол многошаговый, состояния несколько. Для OpenVPN достаточно включить verb 5 и всё понятно. Здесь нужно знать что искать.

NAT traversal работает, но добавляет UDP-инкапсуляцию (порт 4500) - это надо учитывать на файрволе. Несколько раз туннель не поднимался из-за того что 4500/UDP был закрыт на промежуточном оборудовании.

И последнее - interoperability. Cisco ASA, Juniper SRX, MikroTik - у всех своя интерпретация IKEv2. Переговоры с оборудованием не под нашим контролем иногда требуют подбора параметров. Помогает строгий режим с явным указанием алгоритмов с обеих сторон.

Текущий статус

Site-to-site туннели у одного клиента переведены на IKEv2/strongSwan, работает около месяца без нареканий. Road warrior на Windows через EAP настроен и используется. OpenVPN с инфраструктуры не убрали - часть road warrior сценариев остаётся на нём, особенно с нестандартными OS. На сопровождении планируем постепенно переводить новые инсталляции на IKEv2, старые - по ситуации.