IKEv2 no Windows e no FortiGate: três definições que as pessoas juntam
A troca de chaves IKE, a proteção da CHILD SA e a autenticação do par são três linhas separadas. Números de grupo iguais em duas janelas não as juntam.
Um acordo IKEv2 entre um cliente Windows e um gateway FortiGate continua a falhar, e a procura de um número que não corresponde produz uma lista de números ainda mais longa. A lista só se torna gerível quando é dividida em três linhas que falham de forma independente: a troca de chaves que protege o IKE, a proteção aplicada à CHILD SA e a autenticação que prova quem é cada parte. Os números de grupo aparecem em duas dessas linhas e significam coisas diferentes.
Três linhas que falham de forma independente
A primeira linha é a troca de chaves dentro do próprio IKE, que gera as chaves que protegem a negociação. A segunda é a proposta para a CHILD SA, que protege o tráfego que o túnel transporta. A terceira é a autenticação, que decide o que cada parte apresenta e como a outra o valida.
As falhas ocorrem em locais diferentes. Uma falha de troca interrompe a negociação antes de existir qualquer túnel. Uma falha da CHILD SA ocorre depois de a autenticação ter êxito, por vezes apenas numa renovação de chaves. Uma falha de autenticação pode parecer, nos registos, uma falha de troca se apenas ler o primeiro erro.
Separar as linhas não é contabilidade. Muda a definição que vale a pena alterar e impede o movimento mais caro de toda esta área, que é regenerar certificados a funcionar para corrigir uma discrepância de proposta. A alteração de uma linha nunca deve obrigar as outras duas a mudar com ela. Essa independência é todo o objetivo de as escrever separadamente.
O que controlam os dois campos do Windows
O Windows mantém dois campos separados: DHGroup configura a própria troca IKE, enquanto PfsGroup configura a política IPsec que protege o tráfego no túnel. Pertencem a fases diferentes. Comparar um campo IKE do Windows com um valor de fase 2 do FortiGate testa o par errado, e os números podem coincidir enquanto a troca subjacente continua a falhar.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAO segundo e o terceiro comandos reportam as associações de segurança que realmente existem, e é a coisa mais próxima de uma resposta que um cliente lhe pode dar. Uma associação em modo principal sem associação em modo rápido é um problema da CHILD SA, e é a assinatura de uma discrepância de fase 2 e não de um problema de certificado.
Registe o que foi oferecido e o que foi selecionado numa tentativa. Uma lista oferecida que contém uma proposta aceitável e uma proposta selecionada que não corresponde à política do gateway é um desacordo de configuração, não um mistério de interoperabilidade.
| 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 |
Um grupo de curva elíptica não escolhe a sua chave de assinatura
A inferência errada mais persistente nesta área é que escolher um grupo DH de curva elíptica exige um certificado de curva elíptica. Um grupo DH fornece material de troca de chaves; o algoritmo de assinatura é negociado pelo enquadramento de autenticação, e são duas decisões separadas no IKEv2.
O RFC 7427 existe precisamente porque essas decisões estavam anteriormente entrelaçadas, e define como os algoritmos de assinatura são anunciados e selecionados independentemente da troca de chaves. Um gateway pode suportar ao mesmo tempo um grupo de curva e uma escolha de esquemas de assinatura.
Por isso, quando uma negociação falha após uma mudança de grupo, olhe para o método de autenticação antes de olhar para o tipo de chave do certificado. Mudar um certificado é uma operação lenta e arriscada que raramente é a resposta, e fazê-lo primeiro destrói a sua capacidade de perceber qual alteração realmente ajudou. Leia a linha de autenticação antes de tocar no armazenamento de certificados.
Mantenha os dois em linhas separadas da folha de acordo e o erro deixa de ser tentador. Uma linha lista grupos, a outra lista esquemas de assinatura e identidades, e nenhuma é prova sobre a outra.
Coloque cada chave privada junto do seu proprietário real
Um gateway que apresenta o seu próprio certificado precisa da chave privada que lhe corresponde. Um par que valida uma cadeia precisa do certificado da AC e, em concreto, não precisa da chave de assinatura da AC. Confundir estes três artefactos é a forma como as pessoas acabam a importar uma chave privada de AC para um dispositivo VPN para fazer um certificado aparecer noutra categoria.
No FortiOS as funções são distintas: um certificado local com a sua chave, um certificado remoto usado para identificar um par e uma entrada de AC remota que estabelece confiança nos certificados assinados por essa AC. Uma entrada de AC remota sem chave privada não está incompleta; está correta para o seu propósito.
As chaves de assinatura de AC importadas alargam a autoridade de qualquer pessoa que consiga ler esse dispositivo. Também não resolvem a validação comum do par, porque a validação precisa do certificado público e da decisão de confiança, não da capacidade de emitir novos certificados.
Mantenha a chave de assinatura da AC junto do processo do próprio emissor e registe qual dispositivo tem qual chave. Uma tabela curta de proprietários vale mais do que uma tabela mais longa de algoritmos quando uma auditoria pergunta quem poderia fazer-se passar por quem. Ninguém importa uma chave que sabe ser apenas de inventário. Escreva o inventário antes do incidente, não depois.