IKEv2 Windowsissa ja FortiGateissa: kolme asetusta, jotka ihmiset yhdistävät
IKE-avaintenvaihto, CHILD SA -suojaus ja vertaisen todentaminen ovat kolme erillistä riviä. Samat ryhmänumerot kahdessa ikkunassa eivät yhdistä niitä.
IKEv2-sopimus Windows-asiakkaan ja FortiGate-yhdyskäytävän välillä epäonnistuu edelleen, ja väärän numeron etsiminen tuottaa entistä pidemmän luettelon numeroista. Luettelosta tulee hallittava vasta kun se jaetaan kolmeen riviin, jotka epäonnistuvat toisistaan riippumatta: avaintenvaihto, joka suojaa IKE:tä, CHILD SA:han sovellettava suojaus ja todentaminen, joka osoittaa kuka kukin osapuoli on. Ryhmänumerot esiintyvät kahdessa näistä riveistä ja tarkoittavat eri asioita.
Kolme riviä, jotka epäonnistuvat toisistaan riippumatta
Ensimmäinen rivi on avaintenvaihto IKE:n sisällä, ja se tuottaa avaimet, jotka suojaavat neuvottelua. Toinen on CHILD SA:ta koskeva ehdotus, joka suojaa tunnelin kuljettamaa liikennettä. Kolmas on todentaminen, joka päättää mitä kukin osapuoli esittää ja miten toinen osapuoli sen validoi.
Viat osuvat eri paikkoihin. Vaihdon vika pysäyttää neuvottelun ennen kuin tunnelia on olemassa. CHILD SA:n vika tapahtuu sen jälkeen kun todentaminen on onnistunut, joskus vain avainten uusimisen yhteydessä. Todentamisen vika voi lokeissa näyttää vaihdon vialta, jos luet vain ensimmäisen virheen.
Rivien erottaminen ei ole kirjanpitoa. Se muuttaa sitä, mitä asetusta kannattaa muuttaa, ja estää koko tämän alueen kalleimman liikkeen eli toimivien varmenteiden uudelleenluomisen ehdotuksen ristiriidan korjaamiseksi. Yhden rivin muuttuminen ei saisi koskaan pakottaa kahta muuta muuttumaan mukana. Juuri tuo riippumattomuus on koko syy kirjoittaa ne erikseen.
Mitä Windowsin kaksi kenttää ohjaavat
Windows pitää kaksi kenttää erillään: DHGroup määrittää itse IKE-vaihdon, kun taas PfsGroup määrittää IPsec-käytännön, joka suojaa tunnelin liikennettä. Ne kuuluvat eri vaiheisiin. Windowsin IKE-kentän vertaaminen FortiGaten vaiheen 2 arvoon testaa väärää paria, ja numerot voivat täsmätä, vaikka taustalla oleva vaihto epäonnistuu edelleen.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAToinen ja kolmas komento raportoivat tietoturvayhteydet, jotka todella ovat olemassa, ja se on lähimpänä vastausta, jonka asiakas voi antaa. Päämuodon yhteys ilman nopean muodon yhteyttä on CHILD SA:n ongelma, ja se on vaiheen 2 ristiriidan eikä varmenneongelman tunnusmerkki.
Kirjaa, mitä tarjottiin ja mitä valittiin yhdellä yrityksellä. Tarjottu luettelo, joka sisältää hyväksyttävän ehdotuksen, ja valittu ehdotus, joka ei vastaa yhdyskäytävän käytäntöä, on kokoonpanon erimielisyys, ei yhteentoimivuuden mysteeri.
| 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 |
Elliptisen käyrän ryhmä ei valitse allekirjoitusavaintasi
Tämän alueen sitkein väärä päätelmä on, että elliptisen käyrän DH-ryhmän valitseminen vaatii elliptisen käyrän varmenteen. DH-ryhmä tarjoaa avaintenvaihtomateriaalia; allekirjoitusalgoritmista neuvottelee todentamiskehys, ja ne ovat kaksi erillistä päätöstä IKEv2:ssa.
RFC 7427 on olemassa juuri siksi, että nämä päätökset olivat aiemmin kietoutuneet toisiinsa, ja se määrittelee, miten allekirjoitusalgoritmeista ilmoitetaan ja miten ne valitaan avaintenvaihdosta riippumatta. Yhdyskäytävä voi tukea samanaikaisesti sekä käyräryhmää että valikoimaa allekirjoitusmenetelmiä.
Kun neuvottelu siis epäonnistuu ryhmän vaihtamisen jälkeen, katso todentamismenetelmää ennen kuin katsot varmenteen avaintyyppiä. Varmenteen vaihtaminen on hidas ja riskialtis toimenpide, joka on harvoin vastaus, ja sen tekeminen ensin tuhoaa kykysi selvittää, mikä muutos todella auttoi. Lue todentamisrivi ennen kuin kosket varmenteiden säilöön.
Pidä molemmat sopimuslomakkeen erillisillä riveillä, niin virhe lakkaa olemasta houkutteleva. Yksi rivi luettelee ryhmät, toinen allekirjoitusmenetelmät ja identiteetit, eikä kumpikaan ole todiste toisesta.
Sijoita jokainen yksityinen avain sen todellisen omistajan yhteyteen
Yhdyskäytävä, joka esittää oman varmenteensa, tarvitsee sitä vastaavan yksityisen avaimen. Vertainen, joka validoi ketjun, tarvitsee CA-varmenteen eikä nimenomaisesti tarvitse CA:n allekirjoitusavainta. Näiden kolmen artefaktin sekoittaminen on se tapa, jolla ihmiset päätyvät tuomaan CA:n yksityisen avaimen VPN-laitteeseen, jotta varmenne näkyisi eri luokassa.
FortiOSissa roolit ovat erillisiä: paikallinen varmenne avaimineen, etävarmenne vertaisen tunnistamiseen ja etä-CA-merkintä, joka luo luottamuksen kyseisen CA:n allekirjoittamiin varmenteisiin. Etä-CA-merkintä ilman yksityistä avainta ei ole puutteellinen; se on tarkoituksensa mukainen.
Tuodut CA-allekirjoitusavaimet laajentavat sen valtuuksia, joka voi lukea kyseistä laitetta. Ne eivät myöskään ratkaise tavallista vertaisen validointia, koska validointi tarvitsee julkisen varmenteen ja luottamuspäätöksen, ei kykyä myöntää uusia varmenteita.
Pidä CA-allekirjoitusavain myöntäjän omassa prosessissa ja kirjaa, mikä laite pitää mitäkin avainta. Lyhyt taulukko omistajista on arvokkaampi kuin pidempi taulukko algoritmeista, kun auditointi kysyy, kuka voisi esiintyä kenenä. Kukaan ei tuo avainta, jonka tietää olevan vain inventaariota varten. Kirjoita inventaario ennen tapahtumaa, ei sen jälkeen.