IKEv2 v Windows in FortiGate: tri nastavitve, ki jih ljudje združujejo
Izmenjava ključev IKE, zaščita CHILD SA in preverjanje pristnosti partnerja so tri ločene vrstice. Enake številke skupin v dveh pogovornih oknih jih ne združijo.
Dogovor IKEv2 med odjemalcem Windows in prehodom FortiGate še naprej ne uspeva, iskanje neujemajoče se številke pa ustvari še daljši seznam številk. Seznam postane obvladljiv šele, ko ga razdelimo na tri vrstice, ki ne uspevajo neodvisno: izmenjava ključev, ki ščiti IKE, zaščita, uporabljena na CHILD SA, in preverjanje pristnosti, ki dokazuje, kdo je vsaka stran. Številke skupin se pojavijo v dveh od teh vrstic in pomenijo različne stvari.
Tri vrstice, ki ne uspevajo neodvisno
Prva vrstica je izmenjava ključev znotraj samega IKE, ki ustvari ključe, ki ščitijo pogajanja. Druga je predlog za CHILD SA, ki ščiti promet, ki ga prenaša tunel. Tretja je preverjanje pristnosti, ki odloči, kaj predstavi vsaka stran in kako druga to potrdi.
Napake se pojavijo na različnih mestih. Napaka izmenjave ustavi pogajanja, preden obstaja kakršen koli tunel. Napaka CHILD SA se zgodi po uspešnem preverjanju pristnosti, včasih le pri obnovi ključev. Napaka preverjanja pristnosti je lahko v dnevnikih videti kot napaka izmenjave, če berete le prvo napako.
Ločevanje vrstic ni knjigovodstvo. Spremeni, katera nastavitev je vredna spremembe, in prepreči najdražjo potezo na celem tem področju, to je ponovno ustvarjanje delujočih potrdil za odpravo neskladja v predlogu. Sprememba ene vrstice nikoli ne bi smela prisiliti drugih dveh, da se spremenita z njo. Ta neodvisnost je ves smisel njihovega ločenega zapisa.
Kaj nadzirata polji Windows
Windows drži dve polji ločeno: DHGroup nastavi samo izmenjavo IKE, medtem ko PfsGroup nastavi politiko IPsec, ki ščiti promet v tunelu. Pripadata različnim fazam. Primerjava polja IKE v Windows z vrednostjo faze 2 na FortiGate preizkuša napačen par, številke pa se lahko ujemajo, medtem ko osnovna izmenjava še vedno ne uspe.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSADrugi in tretji ukaz poročata o varnostnih povezavah, ki v resnici obstajajo, in to je najbližje odgovoru, ki vam ga lahko da odjemalec. Povezava v glavnem načinu brez povezave v hitrem načinu je težava CHILD SA in je znak neskladja faze 2, ne težave s potrdilom.
Zapišite, kaj je bilo ponujeno in kaj izbrano v enem poskusu. Ponujeni seznam, ki vsebuje sprejemljiv predlog, in izbrani predlog, ki ne ustreza politiki prehoda, je neskladje v konfiguraciji, ne skrivnost interoperabilnosti.
| 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 |
Skupina eliptične krivulje ne izbere vašega podpisnega ključa
Najbolj trdovraten napačen sklep na tem področju je, da izbira skupine DH eliptične krivulje zahteva potrdilo eliptične krivulje. Skupina DH zagotavlja gradivo za izmenjavo ključev; podpisni algoritem se pogaja v okviru preverjanja pristnosti, in v IKEv2 sta to dve ločeni odločitvi.
RFC 7427 obstaja prav zato, ker so bile te odločitve prej prepletene, in določa, kako se podpisni algoritmi oglašujejo in izbirajo neodvisno od izmenjave ključev. Prehod lahko hkrati podpira skupino krivulje in izbiro podpisnih shem.
Ko torej pogajanja po spremembi skupine ne uspejo, poglejte način preverjanja pristnosti, preden pogledate vrsto ključa potrdila. Zamenjava potrdila je počasna in tvegana operacija, ki je le redko odgovor, in če jo opravite prvo, uničite zmožnost ugotoviti, katera sprememba je v resnici pomagala. Preberite vrstico preverjanja pristnosti, preden se dotaknete shrambe potrdil.
Oboje imejte v ločenih vrsticah dogovora in napaka ne bo več vabljiva. Ena vrstica našteva skupine, druga podpisne sheme in identitete, in nobena ni dokaz o drugi.
Vsak zasebni ključ postavite k njegovemu dejanskemu lastniku
Prehod, ki predstavi lastno potrdilo, potrebuje zasebni ključ, ki se z njim ujema. Partner, ki preverja verigo, potrebuje potrdilo CA in posebej ne potrebuje podpisnega ključa CA. Zamenjava teh treh artefaktov je način, kako ljudje uvozijo zasebni ključ CA v napravo VPN, da se potrdilo pojavi v drugi kategoriji.
V FortiOS so vloge različne: lokalno potrdilo z njegovim ključem, oddaljeno potrdilo za prepoznavanje partnerja in vnos oddaljenega CA, ki vzpostavi zaupanje v potrdila, ki jih je podpisal ta CA. Vnos oddaljenega CA brez zasebnega ključa ni nepopoln; pravilen je za svoj namen.
Uvoženi podpisni ključi CA razširijo pooblastila vsakogar, ki lahko bere to napravo. Prav tako ne rešijo običajnega preverjanja partnerja, ker preverjanje potrebuje javno potrdilo in odločitev o zaupanju, ne zmožnosti izdajanja novih potrdil.
Podpisni ključ CA imejte pri procesu samega izdajatelja in zabeležite, katera naprava drži kateri ključ. Kratka tabela lastnikov je vredna več kot daljša tabela algoritmov, ko revizija vpraša, kdo bi se lahko predstavljal za koga. Nihče ne uvozi ključa, za katerega ve, da je samo za inventar. Zapišite inventar pred incidentom, ne po njem.