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 у працэсе самога ўладальніка і запісвайце, якая прылада трымае які ключ. Кароткая табліца ўладальнікаў каштоўнейшая за доўгую табліцу алгарытмаў, калі аўдыт пытаецца, хто каго мог імітаваць. Ніхто не імпартуе ключ, пра які ведае, што ён толькі для інвентару. Напішыце інвентар да інцыдэнту, а не пасля.