IKEv2 op Windows en FortiGate: trije ynstellingen dy't minsken gearfoegje
IKE-kaaiútwikseling, CHILD SA-beskerming en peer-autentikaasje binne trije aparte rigen. Itselde groepsnûmer yn twa dialogen foeget se net gear.
In IKEv2-oerienkomst tusken in Windows-klient en in FortiGate-gateway bliuwt mislearje, en it sykjen nei in nûmer dat net past smyt in noch langere list fan nûmers op. De list wurdt pas hantearber as er yn trije rigen splitst wurdt dy't ûnôfhinklik mislearje: de kaaiútwikseling dy't IKE beskermet, de beskerming dy't op 'e CHILD SA tapast wurdt, en de autentikaasje dy't bewissiget wa't elke kant is. Groepsnûmers komme yn twa fan dy rigen foar en betsjutte ferskate dingen.
Trije rigen dy't ûnôfhinklik mislearje
De earste rige is de kaaiútwikseling binnen IKE sels, dy't de kaaien produsearret dy't de ûnderhanneling beskermje. De twadde is it foarstel foar de CHILD SA, dat it ferkear beskermet dat de tunnel draacht. De tredde is autentikaasje, dy't beslút wat elke kant presintearret en hoe't de oare kant dat falidearret.
Mislearrings komme op ferskate plakken telâne. In útwikselingsmislearring stopet de ûnderhanneling foar't der ea in tunnel is. In CHILD SA-mislearring bart neidat autentikaasje slagge is, soms allinne by in kaaifernijing. In autentikaasjemislearring kin yn 'e logs op in útwikselingsmislearring lykje as jo allinne de earste flater lêze.
De rigen skiede is gjin boekhâlding. It feroaret hokker ynstelling it wurdich is om te feroarjen, en it foarkomt de djoerste set yn dit hiele fjild, nammentlik it opnij generearjen fan wurkjende sertifikaten om in foarstelôfwiking te reparearjen. Ien rige dy't feroaret moat de oare twa nea twinge om mei te feroarjen. Dy ûnôfhinklikens is it hiele doel fan se apart skriuwen.
Wat de twa Windows-fjilden kontrolearje
Windows hâldt twa fjilden apart: DHGroup konfigurearret de IKE-útwikseling sels, wylst PfsGroup it IPsec-belied konfigurearret dat it ferkear yn 'e tunnel beskermet. Se hearre by ferskate fazen. In Windows IKE-fjild fergelykje mei in FortiGate-fase-2-wearde testet it ferkearde pear, en de nûmers kinne oerienkomme wylst de ûnderlizzende útwikseling noch mislearret.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAIt twadde en tredde kommando rapportearje de befeiligingsassosjaasjes dy't echt bestean, en dat is it tichtst by in antwurd dat in klient jo jaan kin. In haadmodus-assosjaasje sûnder in snelle-modus-assosjaasje is in CHILD SA-probleem, en it is it teken fan in fase-2-ôfwiking earder as fan in sertifikaatprobleem.
Skriuw op wat oanbean en wat keazen waard yn ien poging. In oanbean list mei in akseptabel foarstel en in keazen foarstel dat net by it belied fan 'e gateway past, is in konfiguraasje-ûnienichheid, gjin riedsel fan ynteroperabiliteit.
| 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 |
In elliptyske-kromme-groep kiest jo ûndertekeningskaai net
De hurdstikkichste ferkearde konklúzje yn dit fjild is dat it kiezen fan in DH-groep fan in elliptyske kromme in sertifikaat fan in elliptyske kromme fereasket. In DH-groep leveret materiaal foar kaaiútwikseling; it ûndertekeningsalgoritme wurdt ûnderhannele troch it autentikaasjekader, en dat binne twa aparte besluten yn IKEv2.
RFC 7427 bestiet krekt om't dy besluten earder ferweven wiene, en it definiearret hoe't ûndertekeningsalgoritmen ûnôfhinklik fan 'e kaaiútwikseling oankundige en keazen wurde. In gateway kin tagelyk in krommegroep en in kar fan ûndertekeningsskema's stypje.
Dus as in ûnderhanneling mislearret nei in groepsferoaring, sjoch dan nei de autentikaasjemetoade foar't jo nei it kaaitype fan it sertifikaat sjogge. In sertifikaat feroarje is in stadige en riskante operaasje dy't selden it antwurd is, en it earst dwaan fernielt jo fermogen om te sjen hokker feroaring echt holp. Lês de autentikaasjerige foar't jo de sertifikaatopslach oanreitsje.
Hâld de beide yn aparte rigen fan it oerienkomstblêd en de flater hâldt op ferliedlik te wêzen. Ien rige listet groepen op, de oare listet ûndertekeningsskema's en identiteiten op, en gjin fan beide is bewiis oer de oare.
Set elke priveekaai by syn echte eigner
In gateway dy't syn eigen sertifikaat presintearret hat de priveekaai nedich dy't dêrby past. In peer dy't in keatling falidearret hat it CA-sertifikaat nedich en hat spesifyk net de ûndertekeningskaai fan 'e CA nedich. Dy trije artefakten trochinoar helje is hoe't minsken einigje mei it ymportearjen fan in priveekaai fan in CA yn in VPN-apparaat om in sertifikaat yn in oare kategory ferskine te litten.
Op FortiOS binne de rollen ûnderskieden: in lokaal sertifikaat mei syn kaai, in ôfstân-sertifikaat dat brûkt wurdt om in peer te identifisearjen, en in ôfstân-CA-ynfier dy't fertrouwen fêstiget yn sertifikaten dy't dy CA ûndertekene hat. In ôfstân-CA-ynfier sûnder priveekaai is net ûnfolslein; it is korrekt foar syn doel.
Ymportearre CA-ûndertekeningskaaien ferbreedzje it gesach fan elkenien dy't dat apparaat lêze kin. Se losse ek de gewoane peer-falidaasje net op, om't falidaasje it iepenbiere sertifikaat en de fertrouwensbeslissing nedich hat, net it fermogen om nije sertifikaten út te jaan.
Hâld de CA-ûndertekeningskaai by it proses fan 'e útjouwer sels, en skriuw op hokker apparaat hokker kaai hat. In koarte tabel fan eigners is mear wurdich as in langere tabel fan algoritmen as in audit freget wa't wa neibeare koe. Nimmen ymportearret in kaai dy't er wit allinne foar ynventaris is. Skriuw de ynventaris foar it ynsidint, net dêrnei.