MAC incompatível no IKE significa que a verificação da chave partilhada falhou

O seu registo do Cloud VPN mostra uma tentativa com chave partilhada seguida da mensagem de que o MAC não corresponde, e o primeiro impulso é muitas vezes procurar um problema de endereço. Neste ramo, o MAC é um código de autenticação de mensagem: um valor calculado sobre a troca com a chave negociada. O par comparou o seu próprio cálculo com o valor que recebeu, e os dois diferiam. Não está envolvida nenhuma placa de rede, e nenhuma definição de interface altera essa comparação.

Duas condições o produzem na prática: os segredos nas duas pontas não têm o mesmo valor, ou as identidades usadas para selecionar o segredo não correspondem. Decida qual delas lendo o par, e não o túnel isolado.

O que esta fase prova

A verificação corre depois de ambos os lados terem trocado os parâmetros iniciais e se terem identificado. Seleciona chaves candidatas para as identidades local e remota e tenta validar os dados de autenticação recebidos; quando nenhuma valida, o diagnóstico é emitido. É uma afirmação forte sobre autenticação e uma afirmação fraca sobre a causa, porque não diz qual dos lados está errado.

Um sucesso anterior não transita para esta verificação. Um IKE_SA_INIT concluído, ou um payload de deteção de NAT que devolveu os valores esperados, prova que os pares conseguem falar. Não prova nada sobre partilharem um segredo.

Dois erros de configuração, uma mensagem

O primeiro é uma incompatibilidade real de segredos, e costuma ser um acidente de aprovisionamento: um valor gerado instalado numa consola e reescrito na outra, um caractere final que sobreviveu num dos lados, ou uma aspa que veio junto com uma colagem. O segundo é uma incompatibilidade de identidade, em que o segredo está correto mas a identidade apresentada pelo par seleciona outra entrada, pelo que o segredo certo nunca é experimentado. Ambos produzem a mesma linha, e é por isso que adivinhar custa uma tarde.

Compare o par antes de tocar em qualquer um dos segredos. Faça corresponder o túnel, o endpoint do par, a janela temporal e a configuração remota, porque dois túneis redundantes podem ter segredos diferentes e o ecrã à sua frente pode não ser o que falhou.

A deteção de NAT é uma fase diferente

A deteção de NAT pergunta como os pacotes estão a ser reescritos, não quem é o par. Um gateway de cliente atrás de NAT continua a autenticar-se corretamente quando a identidade configurada é a que o par espera, e um problema de NAT aparece como uma incompatibilidade de proposta ou de porta e não como uma comparação de autenticação falhada.

Não transporte uma afirmação antiga sobre uma versão de fornecedor para uma implementação atual. O que a travessia de NAT exige na sua versão pertence à documentação dessa versão, e a expressão MAC incompatível não é prova a favor nem contra.

Decida a partir do par, não do ecrã

Leia as duas configurações lado a lado com o segredo ocultado e faça então três perguntas. A identidade de cada lado é exatamente o que o outro espera, caractere a caractere? Ambas as pontas usam a mesma versão de IKE e o mesmo método de autenticação? O túnel que falha corresponde à configuração que está a ler? Um não a qualquer destas decide a reparação sem tocar no segredo.

Se as três estiverem limpas, substitua o segredo pelo fluxo de trabalho aprovado em vez de contornar o problema com edições.

Depois de o par se autenticar

Assim que a autenticação tem sucesso, a superfície de falha seguinte é a associação de segurança filha: propostas e seletores de tráfego. Rodar um segredo que já foi aceite não corrige uma falha na associação filha e prolonga a indisponibilidade. Leia o estado da associação filha, depois os seletores e os intervalos protegidos de ambos os lados, e faça corresponder as orientações de resolução de problemas do Cloud VPN à fase que realmente falhou.

Correlacione registos recentes de ambas as pontas para o mesmo par e a mesma janela. Um lado sozinho dá um veredicto sem a contribuição do outro, e é precisamente essa ambiguidade que produziu a mensagem em primeiro lugar.

O que não concluir

Não leia a mensagem como uma exigência de alterar endereços MAC, e não publique o segredo partilhado quando pede ajuda; um excerto que contenha a chave precisa de ter a chave removida, e não o registo mantido. Também não assuma uma falha de encaminhamento, porque pares que não se conseguem alcançar não produzem qualquer comparação de autenticação. E não generalize uma limitação documentada de uma família de produtos a todas as implementações de IPsec.

Registe o par que falhou, o estado do túnel antes e depois e qual das duas condições alterou. Esse registo transforma a ocorrência seguinte numa verificação de cinco minutos.