IKEv2 sistemoje Windows ir FortiGate: trys nustatymai, kuriuos žmonės sujungia
IKE raktų keitimas, CHILD SA apsauga ir partnerio autentifikavimas yra trys atskiros eilutės. Tų pačių grupių numerių sutapimas dviejuose dialoguose jų nesujungia.
IKEv2 susitarimas tarp Windows kliento ir FortiGate šliuzo nuolat nepavyksta, o ieškant nesutampančio numerio gaunamas dar ilgesnis numerių sąrašas. Sąrašas tampa valdomas tik tada, kai jis padalijamas į tris eilutes, kurios nepavyksta nepriklausomai: raktų keitimas, saugantis IKE, apsauga, taikoma CHILD SA, ir autentifikavimas, įrodantis, kuri yra kiekviena pusė. Grupių numeriai pasirodo dviejose iš tų eilučių ir reiškia skirtingus dalykus.
Trys eilutės, kurios nepavyksta nepriklausomai
Pirmoji eilutė yra raktų keitimas pačiame IKE, kuris sukuria raktus, saugančius derybas. Antroji yra pasiūlymas CHILD SA, saugantis srautą, kurį neša tunelis. Trečioji yra autentifikavimas, nusprendžiantis, ką pateikia kiekviena pusė ir kaip kita ją patvirtina.
Nesėkmės kyla skirtingose vietose. Keitimo nesėkmė sustabdo derybas dar prieš atsirandant bet kokiam tuneliui. CHILD SA nesėkmė įvyksta po sėkmingo autentifikavimo, kartais tik atnaujinant raktus. Autentifikavimo nesėkmė žurnaluose gali atrodyti kaip keitimo nesėkmė, jei skaitote tik pirmąją klaidą.
Eilučių atskyrimas nėra buhalterija. Tai keičia, kurį nustatymą verta keisti, ir užkerta kelią brangiausiam veiksmui visoje šioje srityje, būtent veikiančių sertifikatų regeneravimui, siekiant ištaisyti pasiūlymo neatitikimą. Vienos eilutės pasikeitimas niekada neturėtų priversti kitų dviejų keistis kartu. Šis nepriklausomumas ir yra visas jų atskiro rašymo tikslas.
Ką kontroliuoja du Windows laukai
Windows laiko du laukus atskirai: DHGroup konfigūruoja patį IKE keitimą, o PfsGroup konfigūruoja IPsec politiką, saugančią srautą tunelyje. Jie priklauso skirtingoms fazėms. Windows IKE lauko palyginimas su FortiGate 2 fazės reikšme tikrina neteisingą porą, ir numeriai gali sutapti, nors pagrindinis keitimas vis dar nepavyksta.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAAntroji ir trečioji komandos praneša apie saugos asociacijas, kurios iš tikrųjų egzistuoja, ir tai yra artimiausia atsakymui, ką klientas gali jums duoti. Pagrindinio režimo asociacija be greitojo režimo asociacijos yra CHILD SA problema, ir tai yra 2 fazės neatitikimo, o ne sertifikato problemos požymis.
Užrašykite, kas buvo pasiūlyta ir kas pasirinkta vienu bandymu. Pasiūlytų sąrašas, kuriame yra priimtinas pasiūlymas, ir pasirinktas pasiūlymas, neatitinkantis šliuzo politikos, yra konfigūracijos nesutarimas, o ne sąveikumo paslaptis.
| 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 |
Elipsinės kreivės grupė neparenka jūsų parašo rakto
Užsispyriausia klaidinga išvada šioje srityje yra ta, kad elipsinės kreivės DH grupės pasirinkimas reikalauja elipsinės kreivės sertifikato. DH grupė teikia raktų keitimo medžiagą; parašo algoritmą derasi autentifikavimo sistema, ir tai yra du atskiri sprendimai IKEv2.
RFC 7427 egzistuoja būtent todėl, kad tie sprendimai anksčiau buvo susipynę, ir apibrėžia, kaip parašo algoritmai skelbiami ir pasirenkami nepriklausomai nuo raktų keitimo. Šliuzas gali vienu metu palaikyti kreivės grupę ir parašo schemų pasirinkimą.
Todėl, kai derybos nepavyksta po grupės pakeitimo, pažiūrėkite į autentifikavimo metodą prieš žiūrėdami į sertifikato rakto tipą. Sertifikato keitimas yra lėta ir rizikinga operacija, kuri retai būna atsakymas, o atlikus ją pirmiausia sunaikinama galimybė suprasti, kuris pakeitimas iš tikrųjų padėjo. Perskaitykite autentifikavimo eilutę prieš liedami sertifikatų saugyklą.
Laikykite abu atskirose susitarimo lapo eilutėse, ir klaida nustos būti viliojanti. Viena eilutė išvardija grupes, kita – parašo schemas ir tapatybes, ir nė viena nėra įrodymas apie kitą.
Dėkite kiekvieną privatų raktą pas jo tikrąjį savininką
Šliuzas, pateikiantis savo sertifikatą, turi turėti jį atitinkantį privatų raktą. Partneris, tikrinantis grandinę, turi turėti CA sertifikatą ir konkrečiai neturi turėti CA parašo rakto. Šių trijų elementų painiojimas yra būdas, kuriuo žmonės importuoja CA privatų raktą į VPN įrenginį, kad sertifikatas atsirastų kitoje kategorijoje.
FortiOS aplinkoje vaidmenys skiriasi: vietinis sertifikatas su savo raktu, nuotolinis sertifikatas, naudojamas partneriui identifikuoti, ir nuotolinio CA įrašas, nustatantis pasitikėjimą sertifikatais, kuriuos pasirašė tas CA. Nuotolinio CA įrašas be privataus rakto nėra nepilnas; jis yra teisingas savo paskirčiai.
Importuoti CA parašo raktai išplečia kiekvieno, kas gali skaityti tą įrenginį, įgaliojimus. Jie taip pat neišsprendžia įprasto partnerio patvirtinimo, nes patvirtinimui reikia viešo sertifikato ir pasitikėjimo sprendimo, o ne gebėjimo išduoti naujus sertifikatus.
Laikykite CA parašo raktą prie paties išdavėjo proceso ir užrašykite, kuris įrenginys laiko kurį raktą. Trumpa savininkų lentelė verta daugiau nei ilgesnė algoritmų lentelė, kai auditas klausia, kas ką galėjo apsimesti. Niekas neimportuoja rakto, apie kurį žino, kad jis skirtas tik inventoriui. Rašykite inventorių prieš incidentą, o ne po jo.