IKEv2 på Windows og FortiGate: tre indstillinger, som folk slår sammen
IKE-nøgleudveksling, CHILD SA-beskyttelse og peer-godkendelse er tre separate rækker. At gruppenumre stemmer i to dialoger slår dem ikke sammen.
En IKEv2-aftale mellem en Windows-klient og en FortiGate-gateway bliver ved med at fejle, og jagten på et nummer, der ikke passer, giver en længere liste af numre. Listen bliver først håndterbar, når den deles op i tre rækker, der fejler uafhængigt: nøgleudvekslingen, der beskytter IKE, beskyttelsen der anvendes på CHILD SA, og godkendelsen, der beviser, hvem hver side er. Gruppenumre optræder i to af disse rækker og betyder forskellige ting.
Tre rækker, der fejler uafhængigt
Den første række er nøgleudvekslingen inde i IKE selv, som frembringer de nøgler, der beskytter forhandlingen. Den anden er forslaget til CHILD SA, som beskytter den trafik, tunnelen bærer. Den tredje er godkendelse, som afgør, hvad hver side præsenterer, og hvordan den anden validerer det.
Fejl lander forskellige steder. En udvekslingsfejl stopper forhandlingen, før der findes nogen tunnel. En CHILD SA-fejl sker, efter godkendelsen er lykkedes, nogle gange kun ved en ny nøgleudveksling. En godkendelsesfejl kan i loggene se ud som en udvekslingsfejl, hvis man kun læser den første fejl.
At dele rækkerne op er ikke bogholderi. Det ændrer, hvilken indstilling der er værd at ændre, og det forhindrer det dyreste træk i hele dette område, nemlig at genskabe fungerende certifikater for at rette en uoverensstemmelse i forslaget. At én række ændres bør aldrig tvinge de to andre til at ændre sig med den. Den uafhængighed er hele pointen med at skrive dem separat.
Hvad de to Windows-felter styrer
Windows holder to felter adskilt: DHGroup konfigurerer selve IKE-udvekslingen, mens PfsGroup konfigurerer den IPsec-politik, der beskytter trafikken i tunnelen. De hører til forskellige faser. At sammenligne et Windows IKE-felt med en FortiGate-fase-2-værdi tester det forkerte par, og tallene kan stemme, mens den underliggende udveksling stadig fejler.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSADen anden og tredje kommando rapporterer de sikkerhedsassociationer, der faktisk findes, hvilket er det tætteste på et svar, en klient kan give dig. En main mode-association uden en quick mode-association er et CHILD SA-problem, og det er signaturen på en fase-2-uoverensstemmelse snarere end et certifikatproblem.
Notér, hvad der blev tilbudt, og hvad der blev valgt i ét forsøg. En tilbudt liste, der indeholder et acceptabelt forslag, og et valgt forslag, der ikke matcher gatewayens politik, er en konfigurationsuenighed, ikke en interoperabilitetsgåde.
| 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 vælger ikke din signaturnøgle
Den mest vedholdende forkerte slutning på dette område er, at valg af en elliptisk kurve-DH-gruppe kræver et elliptisk kurve-certifikat. En DH-gruppe leverer materiale til nøgleudveksling; signaturalgoritmen forhandles af godkendelsesrammen, og de er to separate beslutninger i IKEv2.
RFC 7427 findes netop, fordi disse beslutninger tidligere var sammenfiltrede, og den definerer, hvordan signaturalgoritmer annonceres og vælges uafhængigt af nøgleudvekslingen. En gateway kan på samme tid understøtte en kurvegruppe og et udvalg af signaturskemaer.
Så når en forhandling fejler efter en gruppeændring, skal du se på godkendelsesmetoden, før du ser på certifikatets nøgletype. At skifte et certifikat er en langsom og risikabel operation, som sjældent er svaret, og at gøre det først ødelægger din evne til at afgøre, hvilken ændring der faktisk hjalp. Læs godkendelsesrækken, før du rører certifikatlageret.
Hold de to i separate rækker i aftaledokumentet, og fejlen holder op med at være fristende. Den ene række lister grupper, den anden lister signaturskemaer og identiteter, og ingen af dem er bevis for den anden.
Sæt hver privat nøgle sammen med sin faktiske ejer
En gateway, der præsenterer sit eget certifikat, har brug for den private nøgle, der passer til det. En peer, der validerer en kæde, har brug for CA-certifikatet og har specifikt ikke brug for CA'ens signaturnøgle. At forveksle disse tre artefakter er, hvordan folk ender med at importere en privat CA-nøgle til en VPN-enhed for at få et certifikat til at fremstå i en anden kategori.
På FortiOS er rollerne adskilt: et lokalt certifikat med sin nøgle, et eksternt certifikat, der bruges til at identificere en peer, og en ekstern CA-post, der etablerer tillid til certifikater, som den CA har signeret. En ekstern CA-post uden en privat nøgle er ikke ufuldstændig; den er korrekt til sit formål.
Importerede CA-signaturnøgler udvider beføjelserne for enhver, der kan læse den enhed. De løser heller ikke almindelig peer-validering, fordi validering kræver det offentlige certifikat og tillidsbeslutningen, ikke evnen til at udstede nye certifikater.
Hold CA-signaturnøglen hos udstederens egen proces, og notér, hvilken enhed der holder hvilken nøgle. En kort tabel over ejere er mere værd end en længere tabel over algoritmer, når en revision spørger, hvem der kunne udgive sig for hvem. Ingen importerer en nøgle, som de ved kun er til inventar. Skriv inventaret før hændelsen, ikke efter.