IKEv2 ve Windows a FortiGate: tři nastavení, která lidé slučují
Výměna klíčů IKE, ochrana CHILD SA a autentizace protějšku jsou tři samostatné řádky. Shodná čísla skupin ve dvou dialozích je neslučují.
Dohoda IKEv2 mezi klientem Windows a bránou FortiGate stále selhává a hledání neshodného čísla přináší ještě delší seznam čísel. Seznam se stane zvládnutelným teprve tehdy, když se rozdělí na tři řádky, které selhávají nezávisle: výměna klíčů, která chrání IKE, ochrana uplatněná na CHILD SA a autentizace, která dokazuje, kdo je která strana. Čísla skupin se objevují ve dvou z těchto řádků a znamenají různé věci.
Tři řádky, které selhávají nezávisle
První řádek je výměna klíčů uvnitř samotného IKE, která vytváří klíče chránící vyjednávání. Druhý je návrh pro CHILD SA, který chrání provoz, jenž tunel přenáší. Třetí je autentizace, která rozhoduje, co každá strana předloží a jak to druhá strana ověří.
Selhání se objevují na různých místech. Selhání výměny zastaví vyjednávání dřív, než existuje jakýkoli tunel. Selhání CHILD SA nastane po úspěšné autentizaci, někdy jen při obnově klíčů. Selhání autentizace může v protokolech vypadat jako selhání výměny, pokud čtete jen první chybu.
Rozdělení řádků není účetnictví. Mění, které nastavení stojí za to změnit, a brání nejdražšímu kroku v celé této oblasti, kterým je regenerace funkčních certifikátů kvůli opravě neshody v návrhu. Změna jednoho řádku by nikdy neměla nutit ostatní dva, aby se změnily s ním. Právě tato nezávislost je smyslem jejich samostatného zápisu.
Co řídí obě pole Windows
Windows drží dvě pole odděleně: DHGroup konfiguruje samotnou výměnu IKE, zatímco PfsGroup konfiguruje zásadu IPsec, která chrání provoz v tunelu. Patří k různým fázím. Porovnání pole IKE ve Windows s hodnotou fáze 2 na FortiGate testuje špatnou dvojici a čísla se mohou shodovat, i když podkladová výměna stále selhává.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSADruhý a třetí příkaz hlásí bezpečnostní asociace, které skutečně existují, což je nejbližší věc odpovědi, kterou vám klient může dát. Asociace hlavního režimu bez asociace rychlého režimu je problém CHILD SA a je to znak neshody fáze 2, nikoli problému s certifikátem.
Zaznamenejte, co bylo nabídnuto a co vybráno při jednom pokusu. Nabízený seznam, který obsahuje přijatelný návrh, a vybraný návrh, který neodpovídá zásadě brány, je rozdíl v konfiguraci, ne 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 eliptické křivky vám nevybírá podpisový klíč
Nejvytrvalejší chybný závěr v této oblasti je, že volba DH skupiny eliptické křivky vyžaduje certifikát eliptické křivky. DH skupina dodává materiál pro výměnu klíčů; podpisový algoritmus vyjednává rámec autentizace a v IKEv2 jde o dvě samostatná rozhodnutí.
RFC 7427 existuje právě proto, že tato rozhodnutí byla dříve provázaná, a definuje, jak se podpisové algoritmy inzerují a vybírají nezávisle na výměně klíčů. Brána může současně podporovat skupinu křivky i volbu podpisových schémat.
Když tedy vyjednávání po změně skupiny selže, podívejte se na metodu autentizace dřív, než se podíváte na typ klíče certifikátu. Změna certifikátu je pomalá a riskantní operace, která je zřídka odpovědí, a když ji uděláte první, zničíte si schopnost zjistit, která změna skutečně pomohla. Přečtěte si řádek autentizace, než sáhnete na úložiště certifikátů.
Udržujte obojí v samostatných řádcích dohody a chyba přestane být lákavá. Jeden řádek vypisuje skupiny, druhý podpisová schémata a identity, a ani jeden není důkazem o druhém.
Umístěte každý soukromý klíč k jeho skutečnému vlastníkovi
Brána, která předkládá vlastní certifikát, potřebuje soukromý klíč, který k němu patří. Protějšek, který validuje řetěz, potřebuje certifikát CA a konkrétně nepotřebuje podpisový klíč CA. Záměna těchto tří artefaktů je způsob, jak lidé skončí importem soukromého klíče CA do zařízení VPN, aby se certifikát objevil v jiné kategorii.
Ve FortiOS jsou role odlišné: lokální certifikát s jeho klíčem, vzdálený certifikát používaný k identifikaci protějšku a záznam vzdálené CA, který zakládá důvěru v certifikáty, jež tato CA podepsala. Záznam vzdálené CA bez soukromého klíče není neúplný; je správný pro svůj účel.
Importované podpisové klíče CA rozšiřují pravomoc každého, kdo dokáže toto zařízení číst. Neřeší ani běžnou validaci protějšku, protože validace potřebuje veřejný certifikát a rozhodnutí o důvěře, ne schopnost vydávat nové certifikáty.
Udržujte podpisový klíč CA u procesu samotného vydavatele a zaznamenejte, které zařízení drží který klíč. Krátká tabulka vlastníků má větší cenu než delší tabulka algoritmů, když audit chce vědět, kdo mohl koho představovat. Nikdo neimportuje klíč, o kterém ví, že je jen inventární. Napište inventář před incidentem, ne po něm.