IKEv2 sistēmā Windows un FortiGate: trīs iestatījumi, ko cilvēki apvieno
IKE atslēgu apmaiņa, CHILD SA aizsardzība un partnera autentifikācija ir trīs atsevišķas rindas. Vienādu grupu numuru sakritība divos dialogos tās neapvieno.
IKEv2 vienošanās starp Windows klientu un FortiGate vārteju joprojām neizdodas, un nesakrītoša numura meklēšana rada vēl garāku numuru sarakstu. Saraksts kļūst pārvaldāms tikai tad, kad to sadala trīs rindās, kuras neizdodas neatkarīgi: atslēgu apmaiņa, kas aizsargā IKE, aizsardzība, kas piemērota CHILD SA, un autentifikācija, kas pierāda, kura ir katra puse. Grupu numuri parādās divās no šīm rindām un nozīmē dažādas lietas.
Trīs rindas, kuras neizdodas neatkarīgi
Pirmā rinda ir atslēgu apmaiņa pašā IKE iekšienē, kas ģenerē atslēgas, kuras aizsargā sarunas. Otrā ir priekšlikums CHILD SA, kas aizsargā trafiku, ko pārvadā tunelis. Trešā ir autentifikācija, kas izlemj, ko katra puse uzrāda un kā otra to validē.
Kļūmes notiek dažādās vietās. Apmaiņas kļūme aptur sarunas pirms jebkura tuneļa pastāvēšanas. CHILD SA kļūme notiek pēc veiksmīgas autentifikācijas, dažreiz tikai atslēgu atjaunošanas laikā. Autentifikācijas kļūme žurnālos var izskatīties kā apmaiņas kļūme, ja lasāt tikai pirmo kļūdu.
Rindu atdalīšana nav grāmatvedība. Tā maina to, kuru iestatījumu ir vērts mainīt, un novērš dārgāko soli visā šajā jomā, proti, strādājošu sertifikātu atkārtotu ģenerēšanu, lai izlabotu priekšlikuma neatbilstību. Vienas rindas maiņa nekad nedrīkst piespiest pārējās divas mainīties kopā ar to. Šī neatkarība ir viss to atsevišķas rakstīšanas mērķis.
Ko kontrolē abi Windows lauki
Windows tur divus laukus atsevišķi: DHGroup konfigurē pašu IKE apmaiņu, bet PfsGroup konfigurē IPsec politiku, kas aizsargā trafiku tunelī. Tie pieder pie dažādām fāzēm. Windows IKE lauka salīdzināšana ar FortiGate 2 fāzes vērtību pārbauda nepareizo pāri, un numuri var sakrist, kamēr pamata apmaiņa joprojām neizdodas.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAOtrā un trešā komanda ziņo par drošības asociācijām, kas patiešām pastāv, un tas ir vistuvākais atbildei, ko klients var jums sniegt. Galvenā režīma asociācija bez ātrā režīma asociācijas ir CHILD SA problēma, un tā ir 2 fāzes neatbilstības, nevis sertifikāta problēmas pazīme.
Pierakstiet, kas tika piedāvāts un kas izvēlēts vienā mēģinājumā. Piedāvātais saraksts, kas satur pieņemamu priekšlikumu, un izvēlētais priekšlikums, kas neatbilst vārtejas politikai, ir konfigurācijas domstarpības, nevis savietojamības noslēpums.
| 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 |
Eliptiskās līknes grupa neizvēlas jūsu paraksta atslēgu
Visnoturīgākais kļūdainais secinājums šajā jomā ir tāds, ka eliptiskās līknes DH grupas izvēle prasa eliptiskās līknes sertifikātu. DH grupa nodrošina atslēgu apmaiņas materiālu; paraksta algoritmu pārrunā autentifikācijas ietvars, un tie ir divi atsevišķi lēmumi IKEv2.
RFC 7427 pastāv tieši tāpēc, ka šie lēmumi iepriekš bija savīti, un tas nosaka, kā paraksta algoritmi tiek izziņoti un izvēlēti neatkarīgi no atslēgu apmaiņas. Vārteja var vienlaikus atbalstīt gan līknes grupu, gan paraksta shēmu izvēli.
Tāpēc, ja sarunas neizdodas pēc grupas maiņas, apskatiet autentifikācijas metodi pirms sertifikāta atslēgas tipa. Sertifikāta maiņa ir lēna un riskanta darbība, kas reti ir atbilde, un tās veikšana vispirms iznīcina jūsu spēju saprast, kura izmaiņa patiešām palīdzēja. Izlasiet autentifikācijas rindu pirms sertifikātu krātuves aizskaršanas.
Turiet abus atsevišķās vienošanās lapas rindās, un kļūda pārstās būt vilinoša. Viena rinda uzskaita grupas, otra – paraksta shēmas un identitātes, un neviena nav pierādījums par otru.
Novietojiet katru privāto atslēgu pie tās īstā īpašnieka
Vārtejai, kas uzrāda savu sertifikātu, nepieciešama tam atbilstošā privātā atslēga. Partnerim, kas validē ķēdi, nepieciešams CA sertifikāts, un tam konkrēti nav nepieciešama CA paraksta atslēga. Šo trīs artefaktu sajaukšana ir veids, kā cilvēki importē CA privāto atslēgu VPN ierīcē, lai sertifikāts parādītos citā kategorijā.
FortiOS vidē lomas ir atšķirīgas: lokāls sertifikāts ar tā atslēgu, attālināts sertifikāts, ko izmanto partnera identificēšanai, un attālināta CA ieraksts, kas nodibina uzticēšanos sertifikātiem, kurus parakstījusi šī CA. Attālināta CA ieraksts bez privātās atslēgas nav nepilnīgs; tas ir pareizs tā mērķim.
Importētās CA paraksta atslēgas paplašina ikviena, kas var lasīt šo ierīci, pilnvaras. Tās arī neatrisina parasto partnera validāciju, jo validācijai nepieciešams publiskais sertifikāts un uzticēšanās lēmums, nevis spēja izdot jaunus sertifikātus.
Turiet CA paraksta atslēgu pie paša izdevēja procesa un pierakstiet, kura ierīce tur kuru atslēgu. Īsa īpašnieku tabula ir vērtīgāka par garāku algoritmu tabulu, kad audits jautā, kas ko varēja uzvilkt. Neviens neimportē atslēgu, par kuru zina, ka tā ir tikai inventāram. Rakstiet inventāru pirms incidenta, nevis pēc tā.