Встроенный IKEv2-клиент Windows 11 без стороннего софта

MAATRIX

Если на сервере уже поднят IKEv2, ставить ради него отдельный клиент необязательно — Windows 11 умеет подключаться к IKEv2 из коробки, через обычные «Параметры → Сеть и Интернет → VPN». Проблема обычно не в самом подключении, а в двух местах: сертификате, который нужно правильно импортировать, и паре загадочных кодов ошибок — 809 и 13801, — за которыми скрываются вполне конкретные и решаемые причины. Разберём весь путь по шагам.

Что понадобится перед началом

Встроенный клиент Windows умеет работать как с сертификатами, так и с EAP-MSCHAPv2 (логин/пароль), но на практике для IKEv2 почти всегда используют сертификаты — это надёжнее и не зависит от политики паролей. Перед настройкой соберите:

• Адрес сервера — доменное имя (предпочтительно) или статический IP. Если используете IP, убедитесь, что сертификат сервера выпущен именно на этот IP как Subject Alternative Name, иначе Windows откажется проверять подлинность.
• Корневой сертификат (CA) в формате .cer или .crt — тот, которым подписан сертификат сервера. Его нужно скопировать на компьютер клиента любым удобным способом (почта, флешка, облако — сам файл не секретный).
• Клиентский сертификат, если сервер требует аутентификацию по сертификату клиента (а не только сервера) — обычно в формате .pfx с приватным ключом, защищённом паролем.
• Логин и пароль, если используется EAP, либо ничего дополнительного, если аутентификация полностью на сертификатах.

Если сервер вы поднимали сами и сертификаты выпускали через собственный Windows CA, схема их выдачи для IKEv2 подробно разобрана в статье про сертификаты для IKEv2 и SSTP через Windows CA — там же объясняется, какие EKU обязаны присутствовать в сертификате сервера (Server Authentication) и клиента (Client Authentication), без них Windows развалит handshake ещё до попытки авторизации.

Импорт корневого сертификата

Это шаг, который чаще всего пропускают — и потом получают ошибку 13801. Windows не доверяет серверу автоматически, даже если у вас есть файл сертификата: его нужно явно поместить в хранилище доверенных корневых центров сертификации, причём именно компьютера, а не пользователя (VPN-подключение поднимается на уровне системы).

Через оснастку MMC:

1. Win + R → mmc → Enter.
2. Файл → Добавить или удалить оснастку → Сертификаты → Добавить.
3. Выберите «учётной записи компьютера», затем «Локальный компьютер».
4. Перейдите в Certificates (Local Computer) → Trusted Root Certification Authorities → Certificates.
5. Правой кнопкой → Все задачи → Импорт, укажите файл корневого сертификата.

Через PowerShell (быстрее, особенно если делаете это на нескольких машинах):

Import-Certificate -FilePath "C:\certs\rootCA.cer" -CertStoreLocation Cert:\LocalMachine\Root

Если сервер также требует клиентский сертификат, импортируйте .pfx в личное хранилище компьютера:

Import-PfxCertificate -FilePath "C:\certs\client.pfx" `
  -CertStoreLocation Cert:\LocalMachine\My `
  -Password (ConvertTo-SecureString -String "пароль_pfx" -AsPlainText -Force)

Проверить, что сертификат встал туда, куда нужно, можно командой:

Get-ChildItem Cert:\LocalMachine\Root | Where-Object {$_.Subject -like "*ваш-CA*"}

Настройка подключения через «Параметры → Сеть → VPN»

Дальше — стандартный путь через графический интерфейс:

1. Откройте Параметры → Сеть и Интернет → VPN.
2. Нажмите «Добавить VPN».
3. Поставщик VPN: Windows (встроенный).
4. Имя подключения — любое, для себя.
5. Имя или адрес сервера — тот самый домен или IP из сертификата.
6. Тип VPN: IKEv2.
7. Тип данных для входа: Сертификат, если аутентификация клиента идёт по сертификату (Windows сама подхватит подходящий сертификат из личного хранилища), либо Имя пользователя и пароль, если используется EAP-MSCHAPv2.
8. Если выбрали логин/пароль — введите их сразу или оставьте поля пустыми, тогда Windows спросит при первом подключении.
9. Сохранить.

На этом этапе подключение уже можно попробовать: кликните на него в списке VPN и нажмите «Подключиться». Если сервер настроен просто, с параметрами по умолчанию с обеих сторон, соединение установится без дополнительной настройки.

Тонкая настройка через PowerShell

GUI «Параметров» не показывает параметры шифрования IKEv2 — они там просто не выведены на экран, хотя внутри выбираются автоматически. Если сервер настроен строго (например, strongSwan с явным списком proposal'ов) и не принимает предложенные Windows наборы алгоритмов, подключение упадёт с ошибкой согласования (часто это тоже маскируется под 809). В этом случае параметры задаются через PowerShell.

Создать подключение сразу с нужными настройками:

Add-VpnConnection -Name "Office-IKEv2" `
  -ServerAddress "vpn.example.com" `
  -TunnelType IKEv2 `
  -AuthenticationMethod MachineCertificate `
  -EncryptionLevel Required `
  -SplitTunneling $true `
  -RememberCredential

Явно задать криптографический набор для уже созданного подключения:

Set-VpnConnectionIPsecConfiguration -ConnectionName "Office-IKEv2" `
  -AuthenticationTransformConstants SHA256128 `
  -CipherTransformConstants AES256 `
  -EncryptionMethod AES256 `
  -IntegrityCheckMethod SHA256 `
  -PfsGroup PFS2048 `
  -DHGroup Group14 `
  -Force

Важно, чтобы эти параметры совпадали с ike= и esp= строками на сервере. Если сервер собран на strongSwan, шаблон соответствия конфигов разобран в статье про установку IKEv2 strongSwan на Ubuntu 24.04 — там показаны те же алгоритмы с серверной стороны, их и нужно зеркалить в PowerShell-команде выше.

Отключить разбиение туннеля (весь трафик через VPN) или включить — тем же параметром при создании (-SplitTunneling $false для полного туннеля) либо позже через GUI: Параметры адаптера → свойства подключения → вкладка «Сеть» → IPv4 → Дополнительно → «Использовать основной шлюз в удалённой сети».

Подключение и проверка

После настройки:

rasdial "Office-IKEv2"

или через GUI-кнопку «Подключиться». Проверить статус и параметры активного соединения:

Get-VpnConnection -Name "Office-IKEv2"
Get-VpnConnection -Name "Office-IKEv2" | Select-Object *

Если подключение установилось, но трафик не идёт туда, куда ожидалось — проверьте таблицу маршрутов (route print) и убедитесь, что split tunneling настроен так, как вы рассчитывали. Отдельно стоит проверить резолвинг DNS внутри туннеля: по умолчанию Windows не всегда подставляет DNS-сервер, отданный VPN-сервером, если включён split tunneling — это стандартное поведение, а не баг.

Для диагностики на уровне протокола включите расширенное логирование RAS:

netsh ras set tracing * enabled

Логи появятся в %WINDIR%\tracing, а события — в Event Viewer: Applications and Services Logs → Microsoft → Windows → RasClient/Operational и ...RasAgent/Operational. Там видно, на каком именно этапе IKE-обмена рвётся соединение — это быстрее, чем гадать по коду ошибки.

Типичные ошибки: 809 и 13801

Ошибка 809 — «Не удалось установить сетевое подключение между вашим компьютером и VPN-сервером, так как удалённый сервер не отвечает». Формулировка вводит в заблуждение: сервер чаще всего отвечает, просто ответ не доходит до клиента через NAT. IKEv2 использует UDP 500 (первичный обмен) и UDP 4500 (NAT-T, инкапсуляция ESP). Если между клиентом и сервером есть NAT — а он есть почти всегда, домашний роутер или NAT провайдера — Windows и сервер должны договориться о NAT Traversal, и здесь есть известная проблема на стороне Windows: клиент, находящийся за NAT, по умолчанию не устанавливает нужный флаг для устройств, которые сами не за NAT. Фикс — на клиенте:

reg add HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 2 /f

После этого — обязательная перезагрузка (перезапуска службы недостаточно). Тот же ключ иногда нужно выставить и на сервере, если это тоже Windows Server с RRAS — соответствующая настройка описана в статье про IKEv2 на Windows Server через RRAS с нуля. Дополнительно стоит проверить, что порты 500/4500 UDP не блокируются файрволом на пути — и на самом клиентском роутере, и на сервере.

Ошибка 13801 — «Учётные данные проверки подлинности IKE неприемлемы» (IKE authentication credentials are unacceptable). Это почти всегда про сертификаты, а не про пароль:

Практическое правило: если ошибка 13801 появляется сразу после смены адреса сервера (например, перешли с IP на домен) — почти наверняка дело именно в несовпадении SAN, и нужно либо перевыпустить сертификат сервера с новым SAN, либо использовать в клиенте тот же адрес, что указан в сертификате.

Если сервер настроен на несколько пользователей с раздельными клиентскими сертификатами, стоит свериться со схемой выпуска и отзыва из статьи про multi-user сертификаты для IKEv2 на strongSwan — там же разобрана ситуация, когда сертификат технически валиден, но уже отозван (CRL), что тоже даёт 13801, только чуть более редкую разновидность.

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