IKEv2 i Windows och FortiGate: tre inställningar folk slår ihop
IKE-nyckelutbyte, CHILD SA-skydd och peer-autentisering är tre separata rader. Matchande gruppnummer i två dialoger slår inte ihop dem.
Ett IKEv2-avtal mellan en Windows-klient och en FortiGate-gateway fortsätter att misslyckas, och sökandet efter ett nummer som inte stämmer ger en längre lista av nummer. Listan blir bara hanterbar när den delas upp i tre rader som misslyckas oberoende av varandra: nyckelutbytet som skyddar IKE, skyddet som tillämpas på CHILD SA och autentiseringen som bevisar vem varje sida är. Gruppnummer förekommer i två av de raderna och betyder olika saker.
Tre rader som misslyckas oberoende av varandra
Den första raden är nyckelutbytet inuti IKE självt, som producerar nycklarna som skyddar förhandlingen. Den andra är förslaget för CHILD SA, som skyddar trafiken som tunneln bär. Den tredje är autentisering, som avgör vad varje sida presenterar och hur den andra validerar det.
Fel hamnar på olika ställen. Ett utbytesfel stoppar förhandlingen innan någon tunnel finns. Ett CHILD SA-fel inträffar efter att autentiseringen lyckats, ibland bara vid en nyckelväxling. Ett autentiseringsfel kan se ut som ett utbytesfel i loggarna om du bara läser det första felet.
Att dela upp raderna är inte bokföring. Det ändrar vilken inställning som är värd att ändra, och det förhindrar det dyraste draget i hela området, som är att återskapa fungerande certifikat för att åtgärda en förslagsmissmatchning. En rad som ändras ska aldrig tvinga de andra två att ändras med den. Den självständigheten är hela poängen med att skriva dem separat.
Vad de två Windows-fälten styr
Windows håller två fält åtskilda: DHGroup styr själva IKE-utbytet, medan PfsGroup styr IPsec-policyn som skyddar tunneltrafiken. De hör till olika faser. Att jämföra ett Windows-IKE-fält mot ett FortiGate phase-2-värde testar fel par, och numren kan stämma medan det underliggande utbytet ändå misslyckas.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSADet andra och tredje kommandot rapporterar de säkerhetsassociationer som faktiskt finns, vilket är det närmaste ett svar en klient kan ge dig. En main-mode-association utan quick-mode-association är ett CHILD SA-problem, och det är signaturen för en phase-2-missmatchning snarare än ett certifikatproblem.
Anteckna vad som erbjöds och vad som valdes i ett försök. En erbjuden lista som innehåller ett acceptabelt förslag och ett valt förslag som inte matchar gatewayens policy är en konfigurationsoenighet, inte ett interoperabilitetsmysterium.
| 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 |
En elliptisk-kurv-grupp väljer inte din signaturnyckel
Den mest envisa felaktiga slutsatsen i det här området är att valet av en elliptisk-kurv-DH-grupp kräver ett elliptisk-kurv-certifikat. En DH-grupp levererar nyckelutbytesmaterial; signaturalgoritmen förhandlas av autentiseringsramverket, och de två är separata beslut i IKEv2.
RFC 7427 finns just för att de besluten tidigare var sammantrasslade, och definierar hur signaturalgoritmer annonseras och väljs oberoende av nyckelutbytet. En gateway kan stödja en kurvgrupp och ett urval signaturscheman samtidigt.
Så när en förhandling misslyckas efter ett gruppbyte, titta på autentiseringsmetoden innan du tittar på certifikatets nyckeltyp. Att byta ett certifikat är en långsam och riskabel operation som sällan är svaret, och att göra det först förstör din förmåga att avgöra vilken ändring som faktiskt hjälpte. Läs autentiseringsraden innan du rör certifikatlagret.
Håll de två i separata rader i avtalsbladet så slutar misstaget att vara frestande. En rad listar grupper, den andra listar signaturscheman och identiteter, och ingen av dem är bevis om den andra.
Sätt varje privat nyckel hos dess faktiska ägare
En gateway som presenterar sitt eget certifikat behöver den privata nyckel som matchar det. En motpart som validerar en kedja behöver CA-certifikatet, och den behöver specifikt inte CA:ns signeringsnyckel. Att blanda ihop de tre artefakterna är hur folk hamnar i att importera en CA-privatnyckel i en VPN-enhet för att få ett certifikat att dyka upp i en annan kategori.
På FortiOS är rollerna åtskilda: ett lokalt certifikat med sin nyckel, ett fjärrcertifikat som används för att identifiera en motpart, och en fjärr-CA-post som etablerar förtroende för certifikat som den CA:n signerade. En fjärr-CA-post utan privat nyckel är inte ofullständig; den är korrekt för sitt syfte.
Importerade CA-signeringsnycklar vidgar befogenheterna för alla som kan läsa den enheten. De löser inte heller vanlig motpartsvalidering, eftersom validering behöver det publika certifikatet och förtroendebeslutet, inte förmågan att prägla nya certifikat.
Behåll CA-signeringsnyckeln hos utgivarens egen process, och notera vilken enhet som håller vilken nyckel. En kort tabell över ägare är värd mer än en längre tabell över algoritmer när en revision frågar vem som skulle kunna utge sig för att vara vad. Ingen importerar en nyckel de vet bara är inventarium. Skriv inventariet före incidenten, inte efter.