Почему в штатном Windows IKEv2 вообще нет поля PSK

Документация шлюза говорит, что предварительно общий ключ вводится в клиенте, но в профиле Windows для него нет поля. Этот пробел не ошибка, которую обходят, вписывая ключ в поле пароля. Это разница между тем, что может протокол, и тем, что предлагает конкретная реализация.

Возможность протокола не означает поддержку клиента

Спецификация IKEv2 включает аутентификацию общим ключом, поэтому шлюз может быть законно настроен на неё. Штатный профиль удалённого доступа Windows вместо этого документирует схемы с сертификатами и EAP, и возможность протокола не создаёт поле, параметр или значение реестра, которого у клиента никогда не было.

Люди обычно попадают на справка PowerShell по добавлению VPN-подключения, где для схемы L2TP показан L2tpPsk. Этот параметр относится к L2TP и не является общим секретом IKEv2. Настройки выбора алгоритмов выбирают параметры защиты, а это уже третья, несвязанная вещь. Роль маршрутизации в Windows Server тоже не тот же объект. Серверный интерфейс может иметь элементы управления, которых нет в профиле настольного клиента, и копирование серверной настройки в профиль рабочей станции не воспроизводит эту возможность.

Выберите сертификат, EAP или L2TP

Если оператор шлюза примет аутентификацию по сертификату, это обычно самый чистый вариант: клиент предъявляет сертификат, шлюз проверяет его у доверенного издателя, и в профиле не остаётся общего секрета, который кто-то мог бы скопировать. Для этого нужны регистрация, доверенная цепочка и конфигурация шлюза, связывающая сертификат с решением об авторизации.

EAP с учётными данными пользователя — другой поддерживаемый путь в этом клиенте, и он переносит решение к поставщику удостоверений. Он приносит и свои зависимости, потому что метод EAP, сертификат сервера и доверие клиента к этому сертификату должны совпадать. Переход на L2TP/IPsec только ради знакомого поля меняет стек протоколов. Это приемлемо, когда это поддерживаемый выбор с документированной причиной, и плохой результат, когда так происходит из-за того, что кто-то искал поле, куда вписать ключ.

Проверьте, что примет шлюз

Спросите оператора, какие методы аутентификации служба удалённого доступа предлагает сегодня, а не какие продукт поддерживает вообще. Служба, настроенная на IKEv2 только с PSK, не примет сертификат из-за того, что клиент предпочитает его.

Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfter

Читайте метод аутентификации профиля и хранилище сертификатов вместе. Профиль, настроенный на EAP без пригодного сертификата за ним, сбоит так, что это выглядит как проблема сервера.

Если ответ такой, что доступен только PSK, честные варианты — одобренный клиент, который его поддерживает, или изменение дизайна аутентификации шлюза. Ни то ни другое не является локальным обходом, а обратное утверждение создаёт подключение, которое может воспроизвести только тот, кто его настроил.

Запишите решение и секреты

Запишите выбранный метод, доверенный якорь, соответствующее удостоверение и человека, утвердившего изменение. Эта запись — то, что нужно разбору инцидента, и она же мешает следующему инженеру снова пройти тот же тупик.

Держите секреты отдельно в своих заметках: пароль учётной записи, парольная фраза закрытого ключа и предварительно общий ключ шлюза — три разные вещи, даже когда экран настроек называет всё это паролем. Их путаница — это путь, которым ключ попадает в заявку. Проверьте полученный профиль свежим подключением и одним запросом приложения к приватному ресурсу. Успешный туннель без доступной службы — частичный результат, и профиль нельзя описывать как готовый, пока ресурс тоже не работает.