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

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

Смена произошла по совокупности причин. Несколько клиентов из managed-сопровождения начали активно пересаживать сотрудников на 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 - это один раз при настройке, потом всё работает само.