IKEv2 vo Windows a FortiGate: tri nastavenia, ktoré ľudia spájajú
Výmena kľúčov IKE, ochrana CHILD SA a autentifikácia partnera sú tri samostatné riadky. Zhodné čísla skupín v dvoch dialógoch ich nespájajú.
Dohoda IKEv2 medzi klientom Windows a bránou FortiGate stále zlyháva a hľadanie nezhodného čísla prináša ešte dlhší zoznam čísel. Zoznam sa stane zvládnuteľným až vtedy, keď sa rozdelí na tri riadky, ktoré zlyhávajú nezávisle: výmena kľúčov, ktorá chráni IKE, ochrana uplatnená na CHILD SA a autentifikácia, ktorá dokazuje, kto je každá strana. Čísla skupín sa objavujú v dvoch z tých riadkov a znamenajú rôzne veci.
Tri riadky, ktoré zlyhávajú nezávisle
Prvý riadok je výmena kľúčov vnútri samotného IKE, ktorá vytvára kľúče chrániace vyjednávanie. Druhý je návrh pre CHILD SA, ktorý chráni prevádzku prenášanú tunelom. Tretí je autentifikácia, ktorá rozhoduje, čo každá strana predloží a ako to druhá overí.
Zlyhania sa objavujú na rôznych miestach. Zlyhanie výmeny zastaví vyjednávanie skôr, než existuje akýkoľvek tunel. Zlyhanie CHILD SA nastane po úspešnej autentifikácii, niekedy len pri obnove kľúčov. Zlyhanie autentifikácie môže v protokoloch vyzerať ako zlyhanie výmeny, ak čítate len prvú chybu.
Rozdelenie riadkov nie je účtovníctvo. Mení, ktoré nastavenie stojí za zmenu, a bráni najdrahšiemu kroku v celej tejto oblasti, ktorým je regenerácia funkčných certifikátov na opravu nezhody v návrhu. Zmena jedného riadku by nikdy nemala nútiť ostatné dva, aby sa zmenili s ním. Práve táto nezávislosť je zmyslom ich samostatného zápisu.
Čo riadia obe polia Windows
Windows drží dve polia oddelene: DHGroup konfiguruje samotnú výmenu IKE, zatiaľ čo PfsGroup konfiguruje politiku IPsec, ktorá chráni prevádzku v tuneli. Patria k rôznym fázam. Porovnanie poľa IKE vo Windows s hodnotou fázy 2 na FortiGate testuje nesprávnu dvojicu a čísla sa môžu zhodovať, aj keď podkladová výmena stále zlyháva.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSADruhý a tretí príkaz hlási bezpečnostné asociácie, ktoré skutočne existujú, a to je najbližšie k odpovedi, ktorú vám klient môže dať. Asociácia hlavného režimu bez asociácie rýchleho režimu je problém CHILD SA a je to znak nezhody fázy 2, nie problému s certifikátom.
Zaznamenajte, čo bolo ponúknuté a čo vybrané pri jednom pokuse. Ponúkaný zoznam, ktorý obsahuje prijateľný návrh, a vybraný návrh, ktorý nezodpovedá politike brány, je rozdiel v konfigurácii, nie záhada interoperability.
| 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 |
Skupina eliptickej krivky vám nevyberá podpisový kľúč
Najvytrvalejší chybný záver v tejto oblasti je, že voľba DH skupiny eliptickej krivky vyžaduje certifikát eliptickej krivky. DH skupina dodáva materiál na výmenu kľúčov; podpisový algoritmus vyjednáva rámec autentifikácie a v IKEv2 ide o dve samostatné rozhodnutia.
RFC 7427 existuje práve preto, že tieto rozhodnutia boli predtým poprepájané, a definuje, ako sa podpisové algoritmy inzerujú a vyberajú nezávisle od výmeny kľúčov. Brána môže súčasne podporovať skupinu krivky aj výber podpisových schém.
Keď teda vyjednávanie po zmene skupiny zlyhá, pozrite sa na metódu autentifikácie skôr, než sa pozriete na typ kľúča certifikátu. Zmena certifikátu je pomalá a riskantná operácia, ktorá je zriedka odpoveďou, a ak ju urobíte prvou, zničíte si schopnosť zistiť, ktorá zmena skutočne pomohla. Prečítajte si riadok autentifikácie, než sa dotknete úložiska certifikátov.
Udržujte oboje v samostatných riadkoch dohody a chyba prestane byť lákavá. Jeden riadok vypisuje skupiny, druhý podpisové schémy a identity, a ani jeden nie je dôkazom o druhom.
Umiestnite každý súkromný kľúč k jeho skutočnému vlastníkovi
Brána, ktorá predkladá vlastný certifikát, potrebuje súkromný kľúč, ktorý k nemu patrí. Partner, ktorý validuje reťaz, potrebuje certifikát CA a konkrétne nepotrebuje podpisový kľúč CA. Zámena týchto troch artefaktov je spôsob, akým ľudia skončia s importom súkromného kľúča CA do zariadenia VPN, aby sa certifikát objavil v inej kategórii.
Vo FortiOS sú role odlišné: lokálny certifikát s jeho kľúčom, vzdialený certifikát používaný na identifikáciu partnera a záznam vzdialenej CA, ktorý zakladá dôveru v certifikáty, ktoré táto CA podpísala. Záznam vzdialenej CA bez súkromného kľúča nie je neúplný; je správny pre svoj účel.
Importované podpisové kľúče CA rozširujú právomoc každého, kto dokáže toto zariadenie čítať. Neriešia ani bežnú validáciu partnera, pretože validácia potrebuje verejný certifikát a rozhodnutie o dôvere, nie schopnosť vydávať nové certifikáty.
Udržujte podpisový kľúč CA pri procese samotného vydavateľa a zaznamenajte, ktoré zariadenie drží ktorý kľúč. Krátka tabuľka vlastníkov má väčšiu cenu než dlhšia tabuľka algoritmov, keď audit chce vedieť, kto sa mohol za koho vydávať. Nikto neimportuje kľúč, o ktorom vie, že je len inventárny. Napíšte inventár pred incidentom, nie po ňom.