IKEv2 på Windows og FortiGate: tre innstillinger folk slår sammen
IKE-nøkkelutveksling, CHILD SA-beskyttelse og peer-autentisering er tre separate rader. At gruppenumrene stemmer i to dialoger slår dem ikke sammen.
En IKEv2-avtale mellom en Windows-klient og en FortiGate-gateway fortsetter å feile, og jakten på et nummer som ikke passer gir en lengre liste med numre. Listen blir først håndterbar når den deles i tre rader som feiler uavhengig: nøkkelutvekslingen som beskytter IKE, beskyttelsen som brukes på CHILD SA, og autentiseringen som beviser hvem hver side er. Gruppenumre forekommer i to av disse radene og betyr forskjellige ting.
Tre rader som feiler uavhengig
Den første raden er nøkkelutvekslingen inne i IKE selv, som lager nøklene som beskytter forhandlingen. Den andre er forslaget for CHILD SA, som beskytter trafikken tunnelen bærer. Den tredje er autentisering, som avgjør hva hver side presenterer og hvordan den andre validerer det.
Feil lander på forskjellige steder. En utvekslingsfeil stopper forhandlingen før det finnes noen tunnel. En CHILD SA-feil skjer etter at autentiseringen har lykkes, noen ganger bare ved en nøkkelutskiftning. En autentiseringsfeil kan i loggene se ut som en utvekslingsfeil hvis du bare leser den første feilen.
Å dele radene er ikke regnskap. Det endrer hvilken innstilling som er verdt å endre, og det forhindrer det dyreste trekket i hele dette området, nemlig å regenerere fungerende sertifikater for å rette en uoverensstemmelse i forslaget. At én rad endres bør aldri tvinge de to andre til å endre seg med den. Den uavhengigheten er hele poenget med å skrive dem separat.
Hva de to Windows-feltene styrer
Windows holder to felter adskilt: DHGroup konfigurerer selve IKE-utvekslingen, mens PfsGroup konfigurerer IPsec-policyen som beskytter trafikken i tunnelen. De hører til forskjellige faser. Å sammenligne et Windows IKE-felt med en FortiGate-fase-2-verdi tester feil par, og tallene kan stemme mens den underliggende utvekslingen fortsatt feiler.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSADen andre og tredje kommandoen rapporterer sikkerhetsassosiasjonene som faktisk finnes, og det er det nærmeste du kommer et svar en klient kan gi deg. En hovedmodus-assosiasjon uten en hurtigmodus-assosiasjon er et CHILD SA-problem, og det er signaturen på en fase-2-uoverensstemmelse snarere enn et sertifikatproblem.
Noter hva som ble tilbudt og hva som ble valgt i ett forsøk. En tilbudt liste som inneholder et akseptabelt forslag, og et valgt forslag som ikke samsvarer med gatewayens policy, er en konfigurasjonsuenighet, ikke en interoperabilitetsgåte.
| 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 |
En elliptisk kurve-gruppe velger ikke signaturnøkkelen din
Den mest vedvarende feilslutningen på dette området er at valg av en elliptisk kurve-DH-gruppe krever et elliptisk kurve-sertifikat. En DH-gruppe leverer materiale til nøkkelutveksling; signaturalgoritmen forhandles av autentiseringsrammeverket, og de er to separate beslutninger i IKEv2.
RFC 7427 finnes nettopp fordi disse beslutningene tidligere var sammenfiltret, og den definerer hvordan signaturalgoritmer annonseres og velges uavhengig av nøkkelutvekslingen. En gateway kan støtte en kurvegruppe og et utvalg signaturskjemaer samtidig.
Så når en forhandling feiler etter en gruppeendring, se på autentiseringsmetoden før du ser på sertifikatets nøkkeltype. Å bytte et sertifikat er en langsom og risikabel operasjon som sjelden er svaret, og å gjøre det først ødelegger evnen din til å avgjøre hvilken endring som faktisk hjalp. Les autentiseringsraden før du rører sertifikatlageret.
Hold begge i separate rader i avtaledokumentet, og feilen slutter å være fristende. Den ene raden lister grupper, den andre lister signaturskjemaer og identiteter, og ingen av dem er bevis for den andre.
Sett hver privat nøkkel hos sin faktiske eier
En gateway som presenterer sitt eget sertifikat trenger den private nøkkelen som passer til det. En peer som validerer en kjede trenger CA-sertifikatet og trenger spesifikt ikke CA-ens signaturnøkkel. Å forveksle disse tre artefaktene er hvordan folk ender med å importere en privat CA-nøkkel til en VPN-enhet for å få et sertifikat til å vises i en annen kategori.
På FortiOS er rollene forskjellige: et lokalt sertifikat med nøkkelen sin, et eksternt sertifikat som brukes til å identifisere en peer, og en ekstern CA-oppføring som etablerer tillit til sertifikater som den CA-en signerte. En ekstern CA-oppføring uten privat nøkkel er ikke ufullstendig; den er korrekt for sitt formål.
Importerte CA-signaturnøkler utvider myndigheten til alle som kan lese den enheten. De løser heller ikke vanlig peer-validering, fordi validering trenger det offentlige sertifikatet og tillitsbeslutningen, ikke evnen til å utstede nye sertifikater.
Hold CA-signaturnøkkelen hos utstederens egen prosess, og noter hvilken enhet som holder hvilken nøkkel. En kort tabell over eiere er mer verdt enn en lengre tabell over algoritmer når en revisjon spør hvem som kunne utgi seg for hvem. Ingen importerer en nøkkel de vet bare er for inventar. Skriv inventaret før hendelsen, ikke etter.