Мигрируем клиентский VPN с PPTP на IKEv2/IPsec через strongSwan: встроенный клиент Windows 10 работает без лишнего ПО

PPTP мы поддерживали долго - дольше, чем, честно говоря, следовало. Протокол из 1999 года с MSCHAPv2, который ломается атакой за считанные часы на обычном железе. Но клиенты его любили: настройка на три клика, работает из коробки, не надо ничего ставить. Аргумент понятный, даже если технически он слабый.

Смена произошла по совокупности причин. Несколько клиентов из сопровождения начали активно пересаживать сотрудников на Windows 10, и там PPTP стал ощутимо капризничать - то зависает на согласовании, то корпоративный антивирус блокирует GRE. Параллельно один из клиентов явно поставил вопрос про безопасность: аудитор в отчёте написал «PPTP - deprecated, замените». Вот тут мы и занялись.

Почему IKEv2, а не L2TP/IPsec или OpenVPN

L2TP/IPsec тоже встроен в Windows и выглядит как следующий шаг. Но у него своя история: двойная инкапсуляция (L2TP поверх IPsec), настройка сложнее, pre-shared key в большинстве инсталляций - что тоже не идеал. OpenVPN требует установки клиента, а значит, каждая новая машина - это либо групповая политика, либо звонок в поддержку.

IKEv2 в сравнении выглядит аккуратнее: нативная поддержка в Windows 7 SP1 и выше, сертификатная аутентификация, MOBIKE - это расширение, которое позволяет переключаться между сетями без пересоздания туннеля (актуально для ноутбуков, которые гуляют между Wi-Fi и LTE). На сервере ставим strongSwan - он под Linux хорошо отработан, конфигурация понятная, пакет есть во всех основных дистрибутивах.

Что развернули

Схема получилась стандартная: strongSwan на отдельной виртуалке Debian 8, сертификаты от собственного CA (Let's Encrypt для VPN не подходит - там нужен Server Authentication EKU специфичный образом). Пользователи аутентифицируются по логину и паролю через EAP-MSCHAPv2 - это проще для жизни, чем выдавать каждому клиентский сертификат, хотя сертификатная схема надёжнее.

Серверный сертификат - ключевой момент. strongSwan должен отдавать сертификат, которому доверяет Windows. Для этого root CA нужно занести в Windows Trusted Root Certification Authorities - через GPO это делается в несколько минут для всего домена. Без этого шага клиент Windows 10 будет падать с невнятной ошибкой при подключении.

Основной конфиг /etc/ipsec.conf в сокращении:

conn ikev2-vpn
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    dpdaction=clear
    dpddelay=300s
    rekey=no
    left=%any
    leftid=vpn.example.com
    leftcert=server-cert.pem
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    right=%any
    rightid=%any
    rightauth=eap-mschapv2
    rightsourceip=10.10.10.0/24
    rightdns=10.0.0.1
    rightsendcert=never
    eap_identity=%identity
    ike=aes256-sha256-modp2048!
    esp=aes256-sha256!

forceencaps=yes - важная деталь. Она принудительно включает NAT-T (UDP 4500), что помогает при прохождении через корпоративные файрволы, которые любят блокировать ESP напрямую. В корпоративных сетях без этого флага туннель часто не устанавливается.

Пользователей добавляем в /etc/ipsec.secrets:

vpn.example.com : RSA server-key.pem
alice : EAP "пароль"
bob   : EAP "пароль"

На сервере дополнительно настраиваем NAT для VPN-подсети и ip_forward - стандартная история для любого VPN-сервера.

Клиент Windows 10 - без стороннего ПО

Именно здесь приятный сюрприз. Встроенный VPN-клиент Windows 10 умеет IKEv2 нативно. Пользователь создаёт подключение в «Параметры - Сеть - VPN», выбирает IKEv2, вводит адрес сервера, логин и пароль - всё. Никакого стороннего клиента, никакой установки пакетов.

Можно развернуть подключение через PowerShell и GPO для всего домена:

Add-VpnConnection -Name "Corp VPN" `
    -ServerAddress "vpn.example.com" `
    -TunnelType "IKEv2" `
    -AuthenticationMethod "EAP" `
    -EncryptionLevel "Required" `
    -PassThru

После применения политики подключение появляется у пользователя автоматически - остаётся только ввести пароль при первом подключении. Именно этот момент и определил ответ на вопрос «заметят ли пользователи переезд»: не заметили. Одно нажатие на подключение, окошко с паролем - готово.

Что не обошлось без возни

Сертификаты и EKU. Windows-клиент очень строго проверяет Extended Key Usage серверного сертификата - там должен быть OID 1.3.6.1.5.5.7.3.1 (Server Authentication). Если CA генерирует сертификаты без этого OID или с неправильной цепочкой - соединение падает с ошибкой 13801 («IKE authentication credentials are unacceptable»). Пришлось перевыпустить сертификат с явным указанием EKU.

MTU и фрагментация. Первые несколько дней после миграции был периодический симптом: туннель поднимается, пинги ходят, а крупные пакеты (например, открытие большой страницы в корпоративной системе) подвисают. Классика MTU-проблем в туннелях. Решили через ip link set dev ipsec0 mtu 1400 и добавление правила iptables для корректировки MSS - после этого симптом ушёл.

macOS и iOS. Поскольку несколько сотрудников клиента работают с Mac и iPhone, проверили и там. IKEv2 тоже встроен: на iOS это «Настройки - VPN - Добавить конфигурацию VPN - IKEv2», на macOS аналогично через системные настройки. EAP-MSCHAPv2 поддерживается. Работает - без установки Cisco AnyConnect или чего-то подобного.

Где сейчас

На двух клиентах PPTP выключен, IKEv2/IPsec работает. Третий клиент переходит в декабре - там чуть сложнее, потому что есть несколько удалённых сотрудников на Windows 7, где нужно убедиться что обновления до SP1 и выше везде стоят.

PPTP на этих инфраструктурах оставим в выключенном состоянии ещё пару месяцев, на случай если всплывёт какое-то устройство, которое не перевели. Потом уберём насовсем.

Итог пока рабочий: strongSwan оказался вменяемым в настройке, клиент Windows 10 не требует никакого дополнительного ПО, пользователи переехали без лишних вопросов в поддержку. Возня с сертификатами и MTU - это один раз при настройке, потом всё работает само.