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 зі значенням phase-2 у FortiGate перевіряє неправильну пару, і числа можуть збігатися, тоді як сам обмін усе одно зазнає невдачі.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAДруга й третя команди повідомляють про асоціації безпеки, які справді існують, і це найближче до відповіді, яку клієнт може вам дати. Асоціація main-mode без асоціації quick-mode — це проблема CHILD SA, і це ознака невідповідності phase-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 у власному процесі видавця і записуйте, який пристрій тримає який ключ. Коротка таблиця власників вартує більше за довшу таблицю алгоритмів, коли аудит питає, хто кого міг би видати за себе. Ніхто не імпортує ключ, про який знає, що він лише інвентарний. Напишіть інвентар до інциденту, а не після.