Пользовательская политика IKEv2 в Windows: применяйте её отдельным шагом

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

Пакет подготовки создаёт подключение IKEv2, и полученный профиль согласует нечто иное, чем задуманный вами набор. Пакет сделал свою работу; просто в нём никогда не было поля для той задачи, которую вы предполагали. Рассматривайте криптографический набор как отдельный и проверяемый шаг подготовки.

Пройдите пять пунктов ниже по порядку и держите результаты приёмки отдельно.

Два вида политики за похожими названиями

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

Группа обмена ключами и совершенная прямая секретность относятся к одним и тем же переговорам и должны быть приемлемы для шлюза. Их настройка без проверки удалённой стороны даёт сбой на более позднем этапе, чем тот, который вы правили, и поэтому такие ошибки выглядят как проблемы шлюза.

Стройте полную политику, а не два имени алгоритмов

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

$policy = @{
    ConnectionName = 'Corp IKEv2'
    AllUserConnection = $true
    EncryptionMethod = 'AES256'
    IntegrityCheckMethod = 'SHA384'
    CipherTransformConstants = 'AES256'
    AuthenticationTransformConstants = 'SHA384128'
    DHGroup = 'Group19'
    PfsGroup = 'PFS2048'
    Force = $true
}
Set-VpnConnectionIPsecConfiguration @policy

Рассматривайте этот блок как иллюстративный набор, который должны поддерживать обе стороны, а не как рекомендацию. Переключатель принуждения подавляет запрос; он не утверждает пакет, который вы не проверили.

Сначала создайте, затем примените — в одном охвате

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

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

Документированные поля Configuration Designer описывают одну настройку VPN и не раскрывают каждое встроенное управление IPsec. Если требование — управляемая доставка, у поставщика службы конфигурации VPNv2 есть раздел криптографического набора именно для этой цели.

Назначьте одного владельца политики

Более позднее обновление профиля управления может пересоздать подключение и заменить то, что применил скрипт, и замена будет выглядеть как регресс. Решите, принадлежит ли набор профилю, скрипту или каналу управления, и сделайте так, чтобы плановые обновления шли тем же путём, что и первая установка.

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

Проверяйте согласованный результат, а не пакет

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

Get-VpnConnection -Name 'Corp IKEv2' -AllUserConnection | Format-List
Get-ChildItem 'C:\ProgramData\Microsoft\Network\Connections\Pbk' | Select-Object Name, LastWriteTime

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

Похожие статьи