IKEv2 sa Windows at FortiGate: tatlong setting na pinagsasama ng mga tao

Patuloy na pumapalya ang isang kasunduan ng IKEv2 sa pagitan ng kliyenteng Windows at gateway na FortiGate, at ang paghahanap ng numerong hindi tugma ay nagbibigay ng mas mahabang listahan ng mga numero. Nagiging mapapamahalaan lamang ang listahan kapag hinati ito sa tatlong hilerang pumapalya nang magkahiwalay: ang palitan ng susi na nagpoprotekta sa IKE, ang proteksyong inilalapat sa CHILD SA, at ang pagpapatunay na nagpapatunay kung sino ang bawat panig. Lumilitaw ang mga numero ng grupo sa dalawa sa mga hilerang iyon at may magkaibang kahulugan.

Tatlong hilerang pumapalya nang magkahiwalay

Ang unang hilera ay ang palitan ng susi sa loob mismo ng IKE, na gumagawa ng mga susi na nagpoprotekta sa negosasyon. Ang pangalawa ay ang panukala para sa CHILD SA, na nagpoprotekta sa trapikong dinadala ng tunnel. Ang pangatlo ay pagpapatunay, na nagpapasya kung ano ang inihahain ng bawat panig at kung paano ito pinapatunayan ng isa pa.

Iba-iba ang lugar ng mga pagpalya. Ang pagpalya ng palitan ay pumipigil sa negosasyon bago pa man magkaroon ng anumang tunnel. Ang pagpalya ng CHILD SA ay nangyayari pagkatapos magtagumpay ang pagpapatunay, kung minsan sa muling pagpapalit ng susi lamang. Ang pagpalya ng pagpapatunay ay maaaring magmukhang pagpalya ng palitan sa mga log kung ang unang error lang ang binabasa mo.

Ang paghahati ng mga hilera ay hindi pagtutuos. Binabago nito kung aling setting ang sulit baguhin, at pinipigilan nito ang pinakamahal na hakbang sa buong larangang ito, na ang muling paggawa ng gumaganang mga sertipiko para ayusin ang hindi pagtutugma ng panukala. Ang isang hilerang nagbabago ay hindi dapat pilitin ang dalawa pang magbago kasama nito. Ang kalayaang iyon ang buong dahilan ng pagsulat sa kanila nang hiwalay.

Ano ang kinokontrol ng dalawang field ng Windows

Pinaghihiwalay ng Windows ang dalawang field: DHGroup ang nagtatakda ng palitan ng IKE mismo, habang ang PfsGroup ang nagtatakda ng patakarang IPsec na nagpoprotekta sa trapikong nasa tunnel. Nabibilang sila sa magkaibang yugto. Ang paghahambing ng field ng IKE ng Windows sa halaga ng phase-2 ng FortiGate ay sumusubok sa maling pares, at maaaring magtugma ang mga numero habang pumapalya pa rin ang pinagbabatayang palitan.

Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSA

Ang ikalawa at ikatlong utos ay nag-uulat ng mga samahang panseguridad na talagang umiiral, na siyang pinakamalapit sa sagot na maibibigay sa iyo ng isang kliyente. Ang samahang main-mode na walang samahang quick-mode ay problema sa CHILD SA, at ito ang tandaan ng hindi pagtutugma ng phase-2 sa halip na problema sa sertipiko.

Itala kung ano ang inihandog at ano ang napili sa isang pagsubok. Ang inihandog na listahan na may katanggap-tanggap na panukala at napiling panukala na hindi tugma sa patakaran ng gateway ay hindi pagkakasundo sa configuration, hindi isang misteryo ng interoperability.

Hindi pinipili ng grupong elliptic-curve ang iyong susi ng lagda

Ang pinakamatigas na maling hinuha sa larangang ito ay ang pagpili ng grupong DH na elliptic-curve ay nangangailangan ng sertipikong elliptic-curve. Ang grupong DH ay nagbibigay ng materyal para sa palitan ng susi; ang algorithm ng lagda ay ipinagkasundo ng balangkas ng pagpapatunay, at ang dalawa ay magkahiwalay na desisyon sa IKEv2.

Umiiral ang RFC 7427 nang eksakto dahil dating magkabuhol ang mga desisyong iyon, na naglalarawan kung paano inaanunsyo at pinipili ang mga algorithm ng lagda nang hiwalay sa palitan ng susi. Ang isang gateway ay maaaring sumuporta sa isang grupong curve at sa isang pagpipilian ng mga scheme ng lagda nang sabay.

Kaya kapag pumapalya ang negosasyon pagkatapos ng pagbabago ng grupo, tingnan ang paraan ng pagpapatunay bago tingnan ang uri ng susi ng sertipiko. Ang pagpapalit ng sertipiko ay mabagal at mapanganib na operaasyon na bihirang maging sagot, at ang paggawa nito muna ay sumisira sa kakayahan mong sabihin kung aling pagbabago ang talagang nakatulong. Basahin ang hilerang pagpapatunay bago hawakan ang imbakan ng sertipiko.

Panatilihin ang dalawa sa magkahiwalay na hilera ng sheet ng kasunduan at titigil nang maging kaakit-akit ang pagkakamali. Ang isang hilera ay naglilista ng mga grupo, ang isa ay naglilista ng mga scheme ng lagda at pagkakakilanlan, at wala sa kanila ang ebidensya tungkol sa isa pa.

Ilagay ang bawat pribadong susi sa tunay nitong may-ari

Ang gateway na naghahain ng sarili nitong sertipiko ay nangangailangan ng pribadong susi na tumutugma rito. Ang peer na nagpapatunay ng isang kadena ay nangangailangan ng sertipiko ng CA, at partikular na hindi nito kailangan ang susi sa paglagda ng CA. Ang paghahalo sa tatlong artipaktong iyon ang dahilan kung bakit may mga nag-aangkat ng pribadong susi ng CA sa isang aparatong VPN para lumitaw ang isang sertipiko sa ibang kategorya.

Sa FortiOS magkaiba ang mga papel: lokal na sertipiko kasama ang susi nito, remote na sertipiko na ginagamit upang kilalanin ang isang peer, at remote CA entry na nagtatatag ng pagtitiwala sa mga sertipikong nilagdaan ng CA na iyon. Ang remote CA entry na walang pribadong susi ay hindi kulang; tama ito para sa layunin nito.

Ang inangkat na mga susi sa paglagda ng CA ay nagpapalawak ng awtoridad ng sinumang makabasa sa aparatong iyon. Hindi rin nila nilulutas ang ordinaryong pagpapatunay ng peer, dahil ang pagpapatunay ay nangangailangan ng pampublikong sertipiko at desisyon ng pagtitiwala, hindi ng kakayahang gumawa ng mga bagong sertipiko.

Panatilihin ang susi sa paglagda ng CA sa sariling proseso ng nag-isyu, at itala kung aling aparato ang may hawak ng aling susi. Ang maikling talahanayan ng mga may-ari ay mas mahalaga kaysa sa mas mahabang talahanayan ng mga algorithm kapag nagtanong ang isang audit kung sino ang maaaring magpanggap na sino. Walang nag-aangkat ng susi na alam niyang imbentaryo lamang. Isulat ang imbentaryo bago ang insidente, hindi pagkatapos.