IKEv2 på Windows og FortiGate: tre innstillingar folk slår saman
IKE-nøkkelutveksling, CHILD SA-vern og peer-autentisering er tre separate rader. At gruppenumra stemmer i to dialogar slår dei ikkje saman.
Ei IKEv2-avtale mellom ein Windows-klient og ein FortiGate-gateway held fram med å mislukkast, og jakta på eit nummer som ikkje passar gir ei lengre liste med nummer. Lista blir først handterbar når ho blir delt i tre rader som mislukkast uavhengig: nøkkelutvekslinga som vernar IKE, vernet som blir brukt på CHILD SA, og autentiseringa som bevisar kven kvar side er. Gruppenummer førekjem i to av desse radene og tyder ulike ting.
Tre rader som mislukkast uavhengig
Den første rada er nøkkelutvekslinga inne i IKE sjølv, som lagar nøklane som vernar forhandlinga. Den andre er forslaget for CHILD SA, som vernar trafikken tunnelen ber. Den tredje er autentisering, som avgjer kva kvar side legg fram og korleis den andre validerer det.
Feil landar på ulike stader. Ein utvekslingsfeil stoppar forhandlinga før det finst nokon tunnel. Ein CHILD SA-feil skjer etter at autentiseringa har lukkast, nokre gonger berre ved ein nøkkelutskiftning. Ein autentiseringsfeil kan i loggane sjå ut som ein utvekslingsfeil viss du berre les den første feilen.
Å dela radene er ikkje rekneskap. Det endrar kva innstilling som er verdt å endra, og det hindrar det dyraste trekket i heile dette området, nemleg å regenerera fungerande sertifikat for å retta ein usemje i forslaget. At éi rad blir endra bør aldri tvinga dei to andre til å endra seg med henne. Den uavhengigheita er heile poenget med å skriva dei separat.
Kva dei to Windows-felta styrer
Windows held to felt skilde: DHGroup konfigurerer sjølve IKE-utvekslinga, medan PfsGroup konfigurerer IPsec-policyen som vernar trafikken i tunnelen. Dei høyrer til ulike fasar. Å samanlikna eit Windows IKE-felt med ein FortiGate-fase-2-verdi testar feil par, og tala kan stemma medan den underliggjande utvekslinga framleis mislukkast.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSADen andre og tredje kommandoen rapporterer tryggleiksassosiasjonane som faktisk finst, og det er det næraste du kjem eit svar ein klient kan gi deg. Ein hovudmodus-assosiasjon utan ein hurtigmodus-assosiasjon er eit CHILD SA-problem, og det er signaturen på ein fase-2-usemje snarare enn eit sertifikatproblem.
Noter kva som vart tilbode og kva som vart valt i eitt forsøk. Ei tilboden liste som inneheld eit akseptabelt forslag, og eit valt forslag som ikkje samsvarar med policyen til gatewayen, er ei konfigurasjonsusemje, ikkje ei 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 |
Ei elliptisk kurve-gruppe vel ikkje signaturnøkkelen din
Den mest vedvarande feilslutninga på dette området er at val av ei elliptisk kurve-DH-gruppe krev eit elliptisk kurve-sertifikat. Ei DH-gruppe leverer materiale til nøkkelutveksling; signaturalgoritmen blir forhandla av autentiseringsrammeverket, og dei er to separate avgjerder i IKEv2.
RFC 7427 finst nettopp fordi desse avgjerdene tidlegare var samanfiltra, og han definerer korleis signaturalgoritmar blir annonserte og valde uavhengig av nøkkelutvekslinga. Ein gateway kan støtta ei kurvegruppe og eit utval signaturskjema samstundes.
Så når ei forhandling mislukkast etter ei gruppeendring, sjå på autentiseringsmetoden før du ser på nøkkeltypen til sertifikatet. Å byta eit sertifikat er ein langsam og risikabel operasjon som sjeldan er svaret, og å gjera det først øydelegg evna di til å avgjera kva endring som faktisk hjelpte. Les autentiseringsrada før du rører sertifikatlagret.
Hald begge i separate rader i avtaledokumentet, og feilen sluttar å vera freistande. Den eine rada listar grupper, den andre listar signaturskjema og identitetar, og ingen av dei er prov for den andre.
Set kvar privat nøkkel hos sin faktiske eigar
Ein gateway som legg fram sitt eige sertifikat treng den private nøkkelen som passar til det. Ein peer som validerer ei kjede treng CA-sertifikatet og treng spesifikt ikkje signaturnøkkelen til CA-en. Å forveksla desse tre artefaktane er korleis folk endar med å importera ein privat CA-nøkkel til ein VPN-eining for å få eit sertifikat til å visast i ein annan kategori.
På FortiOS er rollene ulike: eit lokalt sertifikat med nøkkelen sin, eit eksternt sertifikat som blir brukt til å identifisera ein peer, og ei ekstern CA-oppføring som etablerer tillit til sertifikat som den CA-en signerte. Ei ekstern CA-oppføring utan privat nøkkel er ikkje ufullstendig; ho er korrekt for føremålet sitt.
Importerte CA-signaturnøklar utvidar myndet til alle som kan lesa den eininga. Dei løyser heller ikkje vanleg peer-validering, fordi validering treng det offentlege sertifikatet og tillitsavgjerda, ikkje evna til å gje ut nye sertifikat.
Hald CA-signaturnøkkelen hos prosessen til utgivaren sjølv, og noter kva eining som held kva nøkkel. Ein kort tabell over eigarar er meir verdt enn ein lengre tabell over algoritmar når ein revisjon spør kven som kunne gje seg ut for kven. Ingen importerer ein nøkkel dei veit berre er for inventar. Skriv inventaret før hendinga, ikkje etter.