Windows e strongSwan: alinhar as quatro transformações de uma proposta IKE
Uma cifra partilhada não basta quando os pares discordam do grupo de troca de chaves. Compare as quatro transformações e aplique depois uma única política de perfil delimitada.
Os dois pares suportam AES, ambos aceitam SHA-256, e o túnel continua a não subir. A proposta falhou num componente que ninguém comparou, normalmente o grupo de troca de chaves. Este guia lê a troca real antes de alterar seja o que for, aplica uma única política delimitada e deixa uma reversão que restaura os parâmetros anteriores.
Leia a falha antes de mudar um grupo
Um «erro de correspondência de política» é um resumo, não um diagnóstico. Significa que não foi encontrada nenhuma proposta mutuamente aceitável e não diz nada sobre qual componente foi rejeitado. Trate-o como o início da investigação e não como prova sobre um grupo concreto.
A resposta está normalmente do lado do servidor. Um registo do strongSwan no nível adequado lista a proposta recebida do cliente e a proposta que está configurado para aceitar, e a diferença entre as duas listas nomeia o componente que falhou.
Não assuma que o cliente oferece o que diz uma publicação antiga do fórum. O perfil ativo e a política instalada decidem a lista oferecida, e uma compilação do Windows atualizada pode oferecer um conjunto diferente do da captura de ecrã que está a copiar.
Escreva as duas listas. Quatro posições de transformação e um grupo são uma lista curta, e compará-la linha a linha leva menos tempo do que qualquer experiência. Quatro posições guardam-se facilmente de vista. Um ficheiro de registo não.
Compare cada transformação, não um só nome conhecido
Uma proposta IKE é um conjunto de escolhas que têm todas de coincidir. A cifragem protege a negociação, a integridade ou um PRF autentica-a, e um grupo Diffie-Hellman estabelece material de chave novo. Uma proposta que coincide nas duas primeiras e difere na terceira continua inaceitável para os dois pares.
Os dois campos do Windows que aqui se confundem pertencem a fases diferentes. O DHGroup aplica-se à troca de chaves IKE, enquanto o PfsGroup se aplica à associação filha que protege o tráfego. Mudar o segundo não repara uma falha no primeiro.
Os nomes dos grupos diferem entre implementações, e isso é outra fonte de confusão. O strongSwan escreve modp2048 e ecp256, enquanto o Windows usa nomes de enumeração como Group14 e ECP256, pelo que uma comparação tem de traduzir antes de comparar. Mantenha uma nota de duas colunas com os dois nomes. A divergência seguinte classifica-se então em segundos.
| Transform | Windows parameter | strongSwan name | Failure it causes |
|---|---|---|---|
| Encryption | CipherTransformConstants | aes, aes256gcm and similar | No common proposal at all |
| Integrity or PRF | AuthenticationTransformConstants | sha256, sha512 and similar | Proposal rejected after encryption matches |
| Key-exchange group | DHGroup | modp2048, ecp256 | Exchange fails during key establishment |
| Child SA protection | PfsGroup | esp proposal groups | Tunnel negotiates, data association does not |
Aplique uma política completa e delimitada
O instrumento suportado para um perfil IKEv2 nativo é uma política IPsec por ligação, definida como um único objeto em vez de campo a campo. Pré-visualize-a primeiro, aplique-a depois e conserve os parâmetros anteriores no registo de alterações.
Set-VpnConnectionIPsecConfiguration -ConnectionName "Northwind IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -WhatIfO comutador -WhatIf pré-visualiza a alteração local e não aplica nada. Isso é útil e também é uma armadilha comum, porque uma pré-visualização só prova que os parâmetros são sintaticamente aceitáveis para o cmdlet local. Não diz nada sobre se o gateway aceitará a proposta resultante.
Ajuste também o âmbito, já agora. Uma ligação no armazém de todos os utilizadores precisa do parâmetro correspondente de todos os utilizadores, e editar o perfil por utilizador com o mesmo nome apresentado altera outro objeto que o túnel não usa.
Depois ajuste o lado strongSwan ao mesmo conjunto antes de testar. Uma alteração coordenada nos dois extremos é a única versão disto que converge; mudar um lado e tentar repetidamente produz um registo cheio da mesma rejeição.
Verifique a troca e a renovação de chaves em separado
Uma ligação bem-sucedida é uma observação, e a renovação de chaves é outra. A negociação IKE inicial usa um conjunto de parâmetros, e a associação filha que transporta o tráfego pode ser renegociada mais tarde com a sua própria política. Uma configuração que liga e depois cai ao fim de algum tempo é normalmente o segundo caso.
ipsec statusall | grep -A6 "Northwind"
Get-VpnConnection -Name "Northwind IKEv2" | Format-List *O primeiro comando mostra a visão do servidor das associações estabelecidas, incluindo a SA filha e o tempo de vida restante. O segundo mostra o que o perfil do cliente tem agora, e é a única forma de confirmar que a política definida é a política em vigor.
Observe uma renovação de chaves completa antes de declarar sucesso. Isso significa deixar a ligação ativa tempo suficiente para a associação filha ser substituída, e depois confirmar que o tráfego continua. A maioria das divergências de política esconde-se nesse passo, porque a negociação inicial pode ter êxito com um conjunto que a renovação não aceita.
A reversão é o conjunto de parâmetros anterior, não um recurso permissivo. Se o cliente só oferecia um grupo antigo e fraco, a resposta é melhorar a política comum do cliente e do servidor, não acrescentar esse grupo ao gateway onde qualquer par futuro poderá negociar em baixa até ele.
Registe os quatro parâmetros, o grupo, o âmbito da ligação e o resultado da renovação. É uma nota curta, e é a diferença entre um guia e uma história sobre a vez em que o túnel subiu.