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 при процеса на самия издател и записвайте кое устройство кой ключ държи. Кратка таблица на собствениците струва повече от по-дълга таблица на алгоритмите, когато одитът пита кой кого е могъл да се представя. Никой не внася ключ, за който знае, че е само за инвентара. Напишете инвентара преди инцидента, не след него.