Windows Server RRAS: разворачиваем VPN-сервер IKEv2 с нуля

MAATRIX

Если у вас уже есть Windows Server и не хочется тянуть на него сторонний VPN-софт — в системе давно встроено всё необходимое. Роль Routing and Remote Access (RRAS) умеет поднимать полноценный IKEv2-сервер без единого стороннего пакета, а IKEv2 при этом остаётся одним из немногих протоколов, которые нативно поддерживаются iPhone, iPad и Android без установки клиентских приложений. Ниже — весь путь от чистой установки роли до рабочего конфига, с командами PowerShell и типичными граблями.

Почему RRAS и почему именно IKEv2

RRAS — это роль сервера, существующая в Windows Server с незапамятных времён (изначально как "Routing and Remote Access Service" ещё в NT4/2000), и с годами она обросла поддержкой современных протоколов. Сегодня через неё можно поднять PPTP, L2TP/IPsec, SSTP и IKEv2. Первые два за 2026 год всерьёз рассматривать не стоит — PPTP небезопасен, L2TP/IPsec капризен к NAT. SSTP хорош тем, что маскируется под HTTPS и живёт на 443-м порту, но он завязан на TLS-туннель и слабо переносит переключения сети. Для наших целей IKEv2 — разумный компромисс:

• нативная поддержка в Windows 10/11, macOS, iOS и Android без сторонних приложений;
• быстрый пересбор туннеля после потери связи (реконнект за доли секунды, а не пересоздание сессии с нуля);
• поддержка MOBIKE (Mobility and Multihoming Protocol) — клиент может переключиться с Wi-Fi на мобильную сеть без разрыва VPN-сессии, просто меняется IP-адрес в уже установленной SA. Для ноутбука, который то на Wi-Fi в офисе, то в кафе, то в роуминге — это ощутимая разница по сравнению с протоколами, требующими пересогласования при смене адреса.

Если вам нужен туннель "точка-точка" для сайт-ту-сайт связи или доступа к офису с одного устройства — присмотритесь к WireGuard, у него проще конфиг и меньше накладных расходов; сравнение подходов есть в статье про установку WireGuard на Windows Server. Но если нужен именно многопользовательский корпоративный VPN с центральным управлением через встроенные средства Windows — RRAS с IKEv2 остаётся рабочим вариантом без установки чего-либо стороннего.

Что нужно до начала настройки

Проверьте набор условий — большая часть проблем с IKEv2 на RRAS возникает именно из-за того, что что-то из этого списка пропустили:

• Windows Server 2019 или 2022 (в 2025 подойдёт и 2025, разница в интерфейсе минимальна), присоединение к домену не обязательно — standalone-сервер работает штатно.
• Статический публичный IPv4-адрес на внешнем интерфейсе. Без статики сертификат и клиентские профили придётся пересобирать при каждой смене адреса.
• DNS-имя, указывающее на этот IP (A-запись, например vpn.example.com). IKEv2 умеет работать и по голому IP, но сертификат на имя — правильнее и проще для клиентов.
• Проброшены (или открыты, если сервер напрямую в интернете) порты UDP 500 и UDP 4500 — это порты IKE и NAT-T соответственно.
• Роль сервера должна свободно раздавать пул внутренних адресов клиентам — заранее выделите диапазон, не пересекающийся с локальной сетью сервера (например, 10.20.30.0/24, если у сервера адрес в другой подсети).

Дальше всё делаем по шагам: сертификат → роль RRAS → политика IKEv2 → фаервол → клиенты.

Сертификат сервера

IKEv2 в режиме, который понимают все мобильные клиенты (аутентификация сервера по сертификату + пользователя по EAP), требует, чтобы клиент доверял сертификату сервера. Тут два пути.

Публичный сертификат (Let's Encrypt). Самый практичный вариант для сервера с реальным доменным именем — тогда не нужно вручную ставить корневой сертификат на каждое клиентское устройство, потому что публичные CA уже есть в системном доверенном хранилище любой ОС. Получить сертификат можно через win-acme (wacs.exe):

# Скачать win-acme и распаковать, затем:
.\wacs.exe --target manual --host vpn.example.com --validationmode http-01 --store certificatestore --certificatestore My

После выпуска сертификат окажется в хранилище Cert:\LocalMachine\My, откуда RRAS сможет его забрать.

Внутренний CA / самоподписанный. Если у вас есть корпоративный Active Directory Certificate Services — выпускайте через шаблон "Computer" с расширенным использованием ключа Server Authentication (OID 1.3.6.1.5.5.7.3.1). Без AD CS можно сгенерировать самоподписанный:

New-SelfSignedCertificate -Type Custom -Subject "CN=vpn.example.com" `
  -KeyUsage DigitalSignature,KeyEncipherment `
  -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.1") `
  -CertStoreLocation Cert:\LocalMachine\My -KeyExportPolicy Exportable

Минус самоподписанного — корневой сертификат придётся вручную экспортировать и импортировать в доверенные корни на каждом клиентском устройстве, иначе Windows и мобильные клиенты будут ругаться на недоверенный сертификат при подключении. Для 2-3 устройств это терпимо, для флота телефонов сотрудников — лучше Let's Encrypt.

Проверьте, что в Subject или Subject Alternative Name сертификата указано именно то DNS-имя, на которое будут подключаться клиенты — несовпадение имени в SAN и адреса подключения ломает проверку на большинстве мобильных клиентов.

Установка роли RRAS

Ставим роль через PowerShell — быстрее, чем через Server Manager, и легче повторить на другом сервере:

Install-WindowsFeature -Name RemoteAccess -IncludeManagementTools
Install-WindowsFeature -Name Routing -IncludeManagementTools

После установки роль нужно включить именно как VPN-сервер (а не как DirectAccess или маршрутизатор):

Install-RemoteAccess -VpnType Vpn

Либо через графическую консоль: Server Manager → Tools → Routing and Remote Access, правый клик по имени сервера → *Configure and Enable Routing and Remote Access* → выбрать *Custom configuration* → отметить *VPN access*. Мастер попросит перезапустить службу RemoteAccess — соглашайтесь.

На этом этапе сервер уже технически "VPN-сервер", но без ограничения на IKEv2 он будет слушать все протоколы сразу (PPTP, L2TP, SSTP, IKEv2). Это стоит поправить следующим шагом.

Настройка политики IKEv2 и пула адресов

Задаём криптографические параметры туннеля и явно ограничиваем протокол до IKEv2, чтобы не оставлять открытыми устаревшие PPTP/L2TP:

Set-VpnServerConfiguration -TunnelType IKEv2 `
  -AuthenticationTransformConstants SHA256128 `
  -CipherTransformConstants AES256 `
  -EncryptionMethod AES256 `
  -IntegrityCheckMethod SHA256 `
  -DHGroup Group14 `
  -PFSgroup PFS2048 `
  -SALifeTimeSeconds 28800 -MMSALifeTimeSeconds 86400

Аутентификация пользователей — через EAP (для сертификатов и MFA) либо MS-CHAPv2 (проще, работает на локальных учётных записях Windows или через NPS). Для базового сценария с локальными пользователями:

Set-VpnAuthProtocol -UserAuthProtocolAccepted EAP,MSCHAPv2

Если сертификат сервера уже в хранилище, привяжите его к RRAS через GUI: свойства сервера в rrasmgmt.msc → вкладка *Security* → *SSL Certificate Binding* → выбрать нужный сертификат по имени.

Пул адресов для клиентов задаётся там же, вкладка *IPv4* → *Static address pool* — укажите диапазон, не пересекающийся с продакшн-сетью (например, 10.20.30.10 – 10.20.30.200). Через PowerShell для базовых сценариев проще всего это тоже сделать мастером — командлеты для статического пула у RRAS менее стабильны между билдами, чем GUI-настройка.

Если клиентам нужен выход в интернет через сервер (полный туннель, а не только доступ к внутренней сети) — включите NAT на внешнем интерфейсе:

netsh routing ip nat install
netsh routing ip nat add interface "Ethernet" mode=full

где "Ethernet" — имя внешнего сетевого адаптера сервера, через который идёт исходящий трафик в интернет.

Фаервол и сетевые правила

RRAS сама открывает нужные правила Windows Firewall при включении роли, но на арендованном сервере часто стоит дополнительный фильтр от провайдера или NSG в облачной панели — там правила придётся добавить руками. Минимальный набор:

Если сервер находится за NAT самого провайдера (актуально для некоторых виртуальных площадок) — убедитесь, что проброс идёт именно на UDP 500 и 4500, а не только на 500: часть клиентов (особенно за собственным NAT) сразу переходит на NAT-T через 4500, и без проброса этого порта туннель не поднимется вовсе, хотя первое согласование пройдёт нормально. Подробный разбор правил фаервола для туннелей на Windows Server — в статье про настройку фаервола под туннель.

Отдельно стоит проверить, что встроенный Windows Defender Firewall не блокирует сам процесс svchost.exe, обслуживающий IKEEXT — если после установки роли что-то не открывается, первым делом смотрите правила для службы IKE and AuthIP IPsec Keying Modules.

Подключение клиентов

На Windows профиль можно добавить командой:

Add-VpnConnection -Name "Office-IKEv2" -ServerAddress "vpn.example.com" `
  -TunnelType IKEv2 -EncryptionLevel Maximum -AuthenticationMethod EAP `
  -RememberCredential -SplitTunneling

Уберите -SplitTunneling, если нужен полный туннель через сервер, а не только доступ к внутренним ресурсам.

На iOS и macOS: *Настройки → VPN → Добавить конфигурацию → IKEv2*, указать адрес сервера, remote ID (обычно совпадает с CN сертификата) и данные для входа. Если использовался публичный сертификат Let's Encrypt — дополнительных действий не требуется, система доверяет ему автоматически. С самоподписанным сертификатом сначала нужно установить корневой сертификат через профиль конфигурации (Apple Configurator или отправкой .mobileconfig).

На Android нативная поддержка IKEv2 ограничена версией системы и прошивкой — на части устройств потребуется приложение strongSwan для явного указания сертификата и типа аутентификации, даже если формально протокол в системе заявлен.

Именно на этом шаге проявляется MOBIKE: если сервер и клиент его поддерживают (для RRAS в Windows Server 2012 R2 и новее — поддерживается по умолчанию, отдельно включать не нужно), ноутбук или телефон могут переключаться между Wi-Fi и мобильной сетью без пересоздания VPN-сессии — туннель просто "подхватывает" новый адрес. На практике проверяйте это на конкретных устройствах: поведение зависит от клиентского ОС и версии, и на части старых билдов Android MOBIKE работает нестабильно.

Частые вопросы