IKEv2 Windows és FortiGate alatt: három beállítás, amit az emberek összevonnak
Az IKE-kulcscsere, a CHILD SA védelme és a partner hitelesítése három külön sor. A csoportszámok egyezése két párbeszédablakban nem vonja össze őket.
A Windows-ügyfél és a FortiGate-átjáró közötti IKEv2-megállapodás folyamatosan meghiúsul, és a nem egyező szám keresése még hosszabb számlistát eredményez. A lista csak akkor válik kezelhetővé, ha három sorra bontjuk, amelyek egymástól függetlenül hiúsulnak meg: az IKE-t védő kulcscsere, a CHILD SA-ra alkalmazott védelem és a hitelesítés, amely bizonyítja, ki melyik fél. Csoportszámok e sorok közül kettőben jelennek meg, és különböző dolgokat jelentenek.
Három sor, amelyek egymástól függetlenül hiúsulnak meg
Az első sor az IKE-n belüli kulcscsere, amely azokat a kulcsokat állítja elő, amelyek a tárgyalást védik. A második a CHILD SA-ra vonatkozó javaslat, amely az alagút által szállított forgalmat védi. A harmadik a hitelesítés, amely eldönti, mit mutat be mindegyik fél, és hogyan ellenőrzi azt a másik.
A hibák különböző helyeken jelentkeznek. A cserehiba még azelőtt leállítja a tárgyalást, hogy bármilyen alagút létezne. A CHILD SA hibája a sikeres hitelesítés után következik be, néha csak kulcsújításnál. A hitelesítési hiba a naplókban cserehibának tűnhet, ha csak az első hibát olvassa el.
A sorok szétválasztása nem könyvelés. Megváltoztatja, melyik beállítást érdemes módosítani, és megakadályozza az egész terület legdrágább lépését, vagyis a működő tanúsítványok újragenerálását egy javaslati eltérés javításához. Egy sor változása soha nem kényszerítheti a másik kettőt, hogy vele együtt változzon. Ez a függetlenség a teljes értelme annak, hogy külön írjuk le őket.
Mit vezérel a Windows két mezője
A Windows két mezőt tart külön: a DHGroup magát az IKE-cserét konfigurálja, míg a PfsGroup az alagút forgalmát védő IPsec-szabályzatot konfigurálja. Különböző fázisokhoz tartoznak. Egy Windows IKE-mező összehasonlítása egy FortiGate 2-es fázis értékével a rossz párt vizsgálja, és a számok egyezhetnek, miközben a mögöttes csere továbbra is meghiúsul.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAA második és a harmadik parancs azokat a biztonsági társulásokat jelenti, amelyek valóban léteznek, és ez áll legközelebb ahhoz a válaszhoz, amit egy ügyfél adhat Önnek. Fő módú társulás gyors módú társulás nélkül CHILD SA-probléma, és ez a 2-es fázis eltérésének a jele, nem tanúsítványproblémáé.
Jegyezze fel, mit ajánlottak fel és mit választottak egy kísérletben. Az a felajánlott lista, amely elfogadható javaslatot tartalmaz, és az a kiválasztott javaslat, amely nem felel meg az átjáró szabályzatának, konfigurációs nézeteltérés, nem interoperabilitási rejtély.
| 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 |
Az elliptikus görbe csoport nem választja ki az aláírási kulcsát
A terület legmakacsabb téves következtetése, hogy az elliptikus görbe DH-csoport kiválasztásához elliptikus görbe tanúsítvány kell. A DH-csoport kulcscsere-anyagot ad; az aláírási algoritmusról a hitelesítési keretrendszer tárgyal, és ez két külön döntés az IKEv2-ben.
Az RFC 7427 éppen azért létezik, mert ezek a döntések korábban összefonódtak, és meghatározza, hogyan hirdetik meg és választják ki az aláírási algoritmusokat a kulcscserétől függetlenül. Egy átjáró egyszerre támogathat görbecsoportot és aláírási sémák választékát.
Ezért amikor egy tárgyalás egy csoportváltás után meghiúsul, nézze meg a hitelesítési módszert, mielőtt a tanúsítvány kulcstípusára nézne. A tanúsítvány cseréje lassú és kockázatos művelet, amely ritkán a válasz, és ha elsőként teszi meg, tönkreteszi a képességét annak megállapítására, melyik változtatás segített valójában. Olvassa el a hitelesítési sort, mielőtt a tanúsítványtárhoz nyúl.
Tartsa mindkettőt a megállapodáslap külön soraiban, és a hiba megszűnik csábítónak lenni. Az egyik sor csoportokat sorol fel, a másik aláírási sémákat és identitásokat, és egyik sem bizonyíték a másikra.
Minden privát kulcsot a tényleges tulajdonosához rendeljen
Az az átjáró, amely a saját tanúsítványát mutatja be, a hozzá illő privát kulcsot igényli. Az a partner, amely egy láncot ellenőriz, a CA-tanúsítványt igényli, és kifejezetten nem igényli a CA aláírási kulcsát. E három összetevő összekeverése az, ahogy az emberek CA privát kulcsot importálnak egy VPN-eszközbe, hogy egy tanúsítvány más kategóriában jelenjen meg.
A FortiOS-ben a szerepek különválnak: helyi tanúsítvány a kulcsával, távoli tanúsítvány a partner azonosítására, és távoli CA-bejegyzés, amely bizalmat alapoz a CA által aláírt tanúsítványokba. A privát kulcs nélküli távoli CA-bejegyzés nem hiányos; a céljára nézve helyes.
Az importált CA-aláírási kulcsok kiterjesztik mindazok jogosultságát, akik olvasni tudják az eszközt. A szokásos partnerellenőrzést sem oldják meg, mert az ellenőrzéshez nyilvános tanúsítvány és bizalmi döntés kell, nem az új tanúsítványok kiadásának képessége.
Tartsa a CA-aláírási kulcsot a kibocsátó saját folyamatánál, és jegyezze fel, melyik eszköz melyik kulcsot tartja. A tulajdonosok rövid táblázata többet ér az algoritmusok hosszabb táblázatánál, amikor egy audit azt kérdezi, ki kit tudott volna megszemélyesíteni. Senki nem importál olyan kulcsot, amelyről tudja, hogy csak leltári célra való. Írja meg a leltárt az incidens előtt, nem utána.