Un MAC que non coincide en IKE significa que fallou a comprobación da clave compartida

O teu rexistro de Cloud VPN mostra un intento con clave compartida seguido de MAC mismatched, e o primeiro instinto adoita ser buscar un problema de enderezo. Nesta rama MAC é un código de autenticación de mensaxe: un valor calculado sobre o intercambio coa clave negociada. O par comparou o seu propio cálculo co valor recibido, e diferían. Non hai ningunha tarxeta de rede implicada, e ningún axuste de interface cambia esa comparación.

Na práctica prodúceo dúas condicións: os segredos dos dous extremos non son o mesmo valor, ou as identidades usadas para seleccionar o segredo non se corresponden. Decide cal lendo o par, non o túnel individual.

Que demostra a etapa

A comprobación execútase despois de que ambos os dous lados intercambiasen os parámetros iniciais e se identificasen. Selecciona claves compartidas candidatas para as identidades local e remota e tenta validar os datos de autenticación recibidos; cando ningunha valida, emítese o diagnóstico. É unha afirmación forte sobre a autenticación e feble sobre a causa, porque non di que lado está equivocado.

O éxito anterior non se traslada a esta comprobación. Un IKE_SA_INIT completado, ou unha carga de detección de NAT que devolveu os valores esperados, demostra que os pares poden falar. Non demostra nada sobre se comparten un segredo.

Dous erros de configuración, unha mensaxe

O primeiro é un desaxuste real do segredo, e normalmente é un accidente de aprovisionamento: un valor xerado instalado nunha consola e reescrito na outra, un carácter final que sobreviviu nun lado, ou unha comiña que chegou cun pegamento. O segundo é un desaxuste de identidade, onde o segredo é correcto pero a identidade que presenta o par selecciona outra entrada, así que o segredo correcto nunca se proba. Ambos producen a mesma liña, por iso adiviñar custa unha tarde.

Compara o par antes de tocar calquera segredo. Fai coincidir o túnel, o punto final do par, a ventá temporal e a configuración remota, porque dous túneles redundantes poden ter segredos distintos e a pantalla que tes diante pode non ser a que fallou.

A detección de NAT é outra etapa

A detección de NAT pregunta como se reescriben os paquetes, non quen é o par. Unha pasarela de cliente detrás de NAT segue autenticándose correctamente cando a súa identidade configurada é a que o par espera, e un problema de NAT amósase como unha discrepancia de proposta ou de porto en lugar dunha comparación de autenticación fallida.

Non traslades unha afirmación antiga sobre unha versión de provedor a unha implantación actual. O que o tránsito NAT require na túa versión pertence á súa propia documentación, e a frase MAC mismatch non é evidencia a favor nin en contra.

Decide desde o par, non desde a pantalla

Le as dúas configuracións unha xunto á outra co segredo oculto, e logo fai tres preguntas. A identidade de cada lado é exactamente o que espera o outro, carácter por carácter? Usan ambos os dous extremos a mesma versión de IKE e o mesmo método de autenticación? O túnel que falla corresponde á configuración que estás a ler? Un non a calquera delas decide a reparación sen tocar o segredo.

Se as tres están limpas, substitúe o segredo mediante o fluxo de traballo aprobado en lugar de editar ao seu redor.

Despois de que o par se autentique

Unha vez que a autenticación ten éxito, a seguinte superficie de fallo é a asociación de seguridade filla: propostas e selectores de tráfico. Rotar un segredo que xa se aceptou non pode arranxar un fallo fillo, e alonga a interrupción. Le o estado da filla, despois os selectores e rangos protexidos en ambos os dous lados, e fai coincidir a guía de solución de problemas de Cloud VPN coa etapa que realmente fallou.

Correlaciona rexistros novos de ambos os dous extremos para o mesmo par e a mesma ventá. Un lado só dá un veredicto sen a entrada do outro, e esa é a ambigüidade que produciu a mensaxe desde o principio.

Que non concluír

Non leas a mensaxe como unha esixencia de cambiar enderezos MAC, e non publiques o segredo compartido mentres pides axuda; un extracto que contén a clave necesita a clave eliminada, non o rexistro conservado. Tampouco asumas un fallo de encamiñamento, porque os pares que non poden alcanzarse non producen ningunha comparación de autenticación. E non xeneralices unha limitación documentada dunha familia de produtos a toda implementación de IPsec.

Rexistra o par que falla, o estado do túnel antes e despois, e cal das dúas condicións cambiaste. Ese rexistro converte a próxima aparición nunha comprobación de cinco minutos.