IKEv2 в Windows и FortiGate: три параметра, которые люди объединяют
Обмен ключами IKE, защита CHILD SA и аутентификация партнёра — это три отдельные строки. Совпадение номеров групп в двух диалогах их не объединяет.
Соглашение IKEv2 между клиентом Windows и шлюзом FortiGate продолжает срываться, а поиск несовпадающего номера даёт ещё более длинный список номеров. Список становится управляемым только тогда, когда его делят на три строки, которые отказывают независимо: обмен ключами, защищающий IKE, защита, применяемая к CHILD SA, и аутентификация, доказывающая, кто каждая сторона. Номера групп встречаются в двух из этих строк и означают разные вещи.
Три строки, которые отказывают независимо
Первая строка — обмен ключами внутри самого IKE, который создаёт ключи, защищающие согласование. Вторая — предложение для CHILD SA, защищающее трафик, который несёт туннель. Третья — аутентификация, которая решает, что предъявляет каждая сторона и как другая это проверяет.
Отказы происходят в разных местах. Отказ обмена останавливает согласование ещё до появления любого туннеля. Отказ CHILD SA происходит после успешной аутентификации, иногда только при обновлении ключей. Отказ аутентификации может в журналах выглядеть как отказ обмена, если читать только первую ошибку.
Разделение строк — не бухгалтерия. Оно меняет то, какой параметр стоит менять, и предотвращает самый дорогой шаг во всей этой области, а именно перегенерацию работающих сертификатов ради исправления несоответствия предложения. Изменение одной строки никогда не должно заставлять две другие меняться вместе с ней. Эта независимость и есть весь смысл писать их отдельно.
Что контролируют два поля Windows
Windows держит два поля отдельно: DHGroup настраивает сам обмен IKE, а PfsGroup настраивает политику IPsec, защищающую трафик в туннеле. Они относятся к разным фазам. Сравнение поля IKE в Windows со значением фазы 2 FortiGate проверяет не ту пару, и номера могут совпадать, пока сам обмен по-прежнему срывается.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAВторая и третья команды показывают ассоциации безопасности, которые реально существуют, и это самое близкое к ответу, что клиент может вам дать. Ассоциация основного режима без ассоциации быстрого режима — это проблема CHILD SA, и это признак несовпадения фазы 2, а не проблемы с сертификатом.
Запишите, что было предложено и что выбрано за одну попытку. Список предложений, содержащий приемлемое предложение, и выбранное предложение, не соответствующее политике шлюза, — это расхождение конфигурации, а не загадка совместимости.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
Группа эллиптической кривой не выбирает ваш ключ подписи
Самое устойчивое ошибочное умозаключение в этой области — что выбор группы DH на эллиптической кривой требует сертификата на эллиптической кривой. Группа DH даёт материал для обмена ключами; алгоритм подписи согласуется рамкой аутентификации, и это два отдельных решения в IKEv2.
RFC 7427 существует именно потому, что эти решения раньше были переплетены, и определяет, как алгоритмы подписи объявляются и выбираются независимо от обмена ключами. Шлюз может одновременно поддерживать группу кривой и набор схем подписи.
Поэтому, когда согласование срывается после смены группы, смотрите на метод аутентификации прежде, чем на тип ключа сертификата. Смена сертификата — медленная и рискованная операция, которая редко бывает ответом, и если сделать её первой, вы уничтожите способность понять, какое изменение действительно помогло. Прочитайте строку аутентификации, прежде чем трогать хранилище сертификатов.
Держите оба в отдельных строках листа соглашения, и ошибка перестаёт быть соблазнительной. Одна строка перечисляет группы, другая — схемы подписи и идентичности, и ни одна не является доказательством о другой.
Поместите каждый закрытый ключ к его настоящему владельцу
Шлюзу, который предъявляет собственный сертификат, нужен соответствующий закрытый ключ. Партнёру, проверяющему цепочку, нужен сертификат CA и конкретно не нужен ключ подписи CA. Путаница этих трёх артефактов — это путь, которым люди импортируют закрытый ключ CA в VPN-устройство, чтобы сертификат появился в другой категории.
В FortiOS роли различны: локальный сертификат с его ключом, удалённый сертификат для идентификации партнёра и запись удалённого CA, устанавливающая доверие к сертификатам, подписанным этим CA. Запись удалённого CA без закрытого ключа не является неполной; она верна для своей цели.
Импортированные ключи подписи CA расширяют полномочия любого, кто может читать это устройство. Они также не решают обычную проверку партнёра, потому что проверке нужны открытый сертификат и решение о доверии, а не способность выпускать новые сертификаты.
Держите ключ подписи CA при процессе самого издателя и записывайте, какое устройство хранит какой ключ. Короткая таблица владельцев ценнее более длинной таблицы алгоритмов, когда аудит спрашивает, кто кого мог выдать за кого. Никто не импортирует ключ, о котором знает, что он только для инвентаризации. Напишите инвентаризацию до инцидента, а не после.