IKEv2 Windowsis ja FortiGate'is: kolm seadet, mille inimesed ühendavad
IKE võtmevahetus, CHILD SA kaitse ja partneri autentimine on kolm eraldi rida. Grupinumbrite kattumine kahes dialoogis ei ühenda neid.
IKEv2 kokkulepe Windowsi kliendi ja FortiGate'i lüüsi vahel ei õnnestu ikka, ja sobimatu numbri otsimine annab veel pikema numbrite nimekirja. Nimekiri muutub hallatavaks alles siis, kui see jagada kolmeks reaks, mis ebaõnnestuvad sõltumatult: võtmevahetus, mis kaitseb IKE-d, CHILD SA-le rakendatav kaitse ja autentimine, mis tõestab, kes kumbki pool on. Grupinumbrid esinevad kahes neist ridadest ja tähendavad erinevaid asju.
Kolm rida, mis ebaõnnestuvad sõltumatult
Esimene rida on võtmevahetus IKE enda sees, mis loob võtmed, mis kaitsevad läbirääkimist. Teine on CHILD SA ettepanek, mis kaitseb liiklust, mida tunnel kannab. Kolmas on autentimine, mis otsustab, mida kumbki pool esitab ja kuidas teine seda valideerib.
Tõrked maanduvad eri kohtades. Vahetuse tõrge peatab läbirääkimise enne, kui ükski tunnel on olemas. CHILD SA tõrge juhtub pärast seda, kui autentimine õnnestub, mõnikord ainult võtmete uuendamisel. Autentimise tõrge võib logides näida vahetuse tõrkena, kui loete ainult esimest viga.
Ridade eraldamine ei ole raamatupidamine. See muudab, millist seadet tasub muuta, ja hoiab ära kogu selle valdkonna kalleima sammu, milleks on töötavate sertifikaatide uuesti genereerimine, et parandada ettepaneku lahknevust. Ühe rea muutumine ei tohiks kunagi sundida kahte teist sellega koos muutuma. Just see sõltumatus on nende eraldi kirjutamise mõte.
Mida juhivad Windowsi kaks välja
Windows hoiab kahte välja eraldi: DHGroup seadistab IKE vahetuse enda, samas kui PfsGroup seadistab IPsec-poliitika, mis kaitseb tunnelis olevat liiklust. Need kuuluvad eri faasidesse. Windowsi IKE-välja võrdlemine FortiGate'i faasi 2 väärtusega testib vale paari, ja numbrid võivad kattuda, samal ajal kui vahetus ise ikka ebaõnnestub.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSATeine ja kolmas käsk näitavad turvaassotsiatsioone, mis tegelikult olemas on, ja see on kõige lähem asi vastusele, mille klient saab teile anda. Põhirežiimi assotsiatsioon ilma kiirrežiimi assotsiatsioonita on CHILD SA probleem, ja see on faasi 2 lahknevuse, mitte sertifikaadiprobleemi tunnus.
Pange kirja, mida pakuti ja mida ühes katses valiti. Pakutud nimekiri, mis sisaldab vastuvõetavat ettepanekut, ja valitud ettepanek, mis ei vasta lüüsi poliitikale, on seadistuste lahkarvamus, mitte koostalitlusvõime müsteerium.
| 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 |
Elliptilise kõvera grupp ei vali teie allkirjavõtit
Selle valdkonna kõige püsivam vale järeldus on, et elliptilise kõvera DH-grupi valimine nõuab elliptilise kõvera sertifikaati. DH-grupp annab võtmevahetuse materjali; allkirja algoritmi lepitakse kokku autentimisraamistiku poolt ja need on IKEv2-s kaks eraldi otsust.
RFC 7427 on olemas just seetõttu, et need otsused olid varem läbi põimunud, ja see määratleb, kuidas allkirja algoritme võtmevahetusest sõltumatult teatatakse ja valitakse. Lüüs võib samal ajal toetada nii kõveragruppi kui ka allkirjaskeemide valikut.
Kui läbirääkimine pärast grupi muutmist ebaõnnestub, vaadake kõigepealt autentimismeetodit ja alles seejärel sertifikaadi võtmetüüpi. Sertifikaadi vahetamine on aeglane ja riskantne toiming, mis on harva vastus, ja selle esimesena tegemine hävitab teie võime aru saada, milline muudatus tegelikult aitas. Lugege autentimisrida enne, kui sertifikaadihoidlat puutute.
Hoidke mõlemad kokkuleppelehe eraldi ridadel ja viga lakkab olemast ahvatlev. Üks rida loetleb gruppe, teine allkirjaskeeme ja identiteete, ja kumbki ei ole tõend teise kohta.
Pange iga privaatvõti selle tegeliku omaniku juurde
Lüüs, mis esitab oma sertifikaati, vajab sellega sobivat privaatvõtit. Partner, kes valideerib ahelat, vajab CA sertifikaati ja justnimelt ei vaja CA allkirjavõtit. Nende kolme artefakti segamini ajamine on viis, kuidas inimesed impordivad CA privaatvõtme VPN-seadmesse, et sertifikaat ilmiks teises kategoorias.
FortiOS-is on rollid erinevad: kohalik sertifikaat koos oma võtmega, kaugsertifikaat partneri tuvastamiseks ja kaug-CA kirje, mis loob usalduse sertifikaatidesse, mille see CA allkirjastas. Kaug-CA kirje ilma privaatvõtmeta ei ole puudulik; see on oma otstarbe jaoks õige.
Imporditud CA allkirjavõtmed laiendavad igaühe volitusi, kes seda seadet lugeda saab. Need ei lahenda ka tavalist partneri valideerimist, sest valideerimine vajab avalikku sertifikaati ja usaldusotsust, mitte võimet uusi sertifikaate välja anda.
Hoidke CA allkirjavõti väljaandja enda protsessi juures ja kirjutage üles, milline seade millist võtit hoiab. Lühike omanike tabel on väärtuslikum kui pikem algoritmide tabel, kui audit küsib, kes võiks keda jäljendada. Keegi ei impordi võtit, mille kohta ta teab, et see on ainult inventari jaoks. Kirjutage inventar enne juhtumit, mitte pärast.