IKEv2 op Windows en FortiGate: drie instellings wat mense saamvoeg
IKE-sleuteluitruiling, CHILD SA-beskerming en eweknie-verifikasie is drie afsonderlike rye. Ooreenstemmende groepsnommers in twee dialoogvensters voeg dit nie saam nie.
’n IKEv2-ooreenkoms tussen ’n Windows-kliënt en ’n FortiGate-poort bly misluk, en die soektog na ’n verkeerde nommer lewer ’n langer lys nommers op. Die lys word eers hanteerbaar wanneer dit in drie rye verdeel word wat onafhanklik misluk: die sleuteluitruiling wat IKE beskerm, die beskerming wat op die CHILD SA toegepas word, en die verifikasie wat bewys wie elke kant is. Groepsnommers kom in twee van daardie rye voor en beteken verskillende dinge.
Drie rye wat onafhanklik misluk
Die eerste ry is die sleuteluitruiling binne IKE self, wat die sleutels lewer wat die onderhandeling beskerm. Die tweede is die voorstel vir die CHILD SA, wat die verkeer beskerm wat die tonnel dra. Die derde is verifikasie, wat bepaal wat elke kant aanbied en hoe die ander kant dit valideer.
Mislukkings beland op verskillende plekke. ’n Uitruilingsmislukking stop die onderhandeling voordat enige tonnel bestaan. ’n CHILD SA-mislukking gebeur nadat verifikasie geslaag het, soms eers by ’n nuwe sleutelronde. ’n Verifikasie-mislukking kan in die logs soos ’n uitruilingsmislukking lyk as jy net die eerste fout lees.
Om die rye te skei is nie boekhouding nie. Dit verander watter instelling die moeite werd is om te verander, en dit verhoed die duurste stap in hierdie hele area, naamlik om werkende sertifikate te hergenereer om ’n voorstel-wanpassing reg te maak. Een ry wat verander, moet nooit die ander twee dwing om saam te verander nie. Daardie onafhanklikheid is die hele punt daarvan om hulle apart te skryf.
Wat die twee Windows-velde beheer
Windows hou twee velde apart: DHGroup stel die IKE-uitruiling self in, terwyl PfsGroup die IPsec-beleid instel wat tonnelverkeer beskerm. Hulle hoort by verskillende fases. Om ’n Windows IKE-veld teen ’n FortiGate fase-2-waarde te vergelyk, toets die verkeerde paar, en die nommers kan ooreenstem terwyl die onderliggende uitruiling steeds misluk.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSADie tweede en derde opdragte rapporteer die sekuriteitsassosiasies wat werklik bestaan, wat die naaste aan ’n antwoord is wat ’n kliënt vir jou kan gee. ’n Hoofmodus-assosiasie sonder ’n vinnige-modus-assosiasie is ’n CHILD SA-probleem, en dit is die kenmerk van ’n fase-2-wanpassing eerder as ’n sertifikaatprobleem.
Teken op wat aangebied en wat gekies is in een poging. ’n Aangebode lys wat ’n aanvaarbare voorstel bevat en ’n gekose voorstel wat nie by die poort se beleid pas nie, is ’n konfigurasieverskil, nie ’n interoperabiliteitsraaisel nie.
| 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 |
’n Elliptiese-kromme-groep kies nie jou handtekening-sleutel nie
Die hardnekkigste verkeerde afleiding in hierdie area is dat die keuse van ’n elliptiese-kromme-DH-groep ’n elliptiese-kromme-sertifikaat vereis. ’n DH-groep verskaf sleuteluitruilingsmateriaal; die handtekeningalgoritme word deur die verifikasieraamwerk onderhandel, en die twee is aparte besluite in IKEv2.
RFC 7427 bestaan juis omdat daardie besluite voorheen verstrengel was, en dit definieer hoe handtekeningalgoritmes onafhanklik van die sleuteluitruiling geadverteer en gekies word. ’n Poort kan terselfdertyd ’n krommegroep en ’n keuse van handtekeningmetodes ondersteun.
Dus, wanneer ’n onderhandeling ná ’n groepverandering misluk, kyk na die verifikasiemetode voordat jy na die sertifikaat se sleuteltipe kyk. Om ’n sertifikaat te verander is ’n stadige, riskante operasie wat selde die antwoord is, en om dit eerste te doen vernietig jou vermoë om te sien watter verandering werklik gehelp het. Lees die verifikasiery voordat jy aan die sertifikaatstoor raak.
Hou die twee in aparte rye van die ooreenkomsblad en die fout hou op om aanloklik te wees. Een ry lys groepe, die ander lys handtekeningmetodes en identiteite, en nie een is bewyse oor die ander nie.
Plaas elke private sleutel by sy werklike eienaar
’n Poort wat sy eie sertifikaat aanbied, het die private sleutel nodig wat daarby pas. ’n Eweknie wat ’n ketting valideer, het die CA-sertifikaat nodig, en dit het spesifiek nie die CA se ondertekeningsleutel nodig nie. Om daardie drie artefakte te verwar, is hoe mense ’n CA private sleutel in ’n VPN-toestel invoer om ’n sertifikaat in ’n ander kategorie te laat verskyn.
Op FortiOS is die rolle duidelik onderskei: ’n plaaslike sertifikaat met sy sleutel, ’n afgeleë sertifikaat wat gebruik word om ’n eweknie te identifiseer, en ’n afgeleë CA-inskrywing wat vertroue vestig in sertifikate wat daardie CA onderteken het. ’n Afgeleë CA-inskrywing sonder ’n private sleutel is nie onvolledig nie; dit is korrek vir sy doel.
Ingevoerde CA-ondertekeningsleutels verbreed die mag van enigiemand wat daardie toestel kan lees. Hulle los ook nie gewone eweknie-validering op nie, want validering het die openbare sertifikaat en die vertrouensbesluit nodig, nie die vermoë om nuwe sertifikate te skep nie.
Hou die CA-ondertekeningsleutel by die uitreiker se eie proses, en teken op watter toestel watter sleutel hou. ’n Kort tabel van eienaars is meer werd as ’n langer tabel van algoritmes wanneer ’n oudit vra wie wie kon naboots. Niemand voer ’n sleutel in wat hulle weet net vir inventaris is nie. Skryf die inventaris voor die voorval, nie daarna nie.