Un MAC non concordant dans IKE signifie que la vérification de la clé partagée a échoué

Votre journal Cloud VPN montre une tentative de clé partagée suivie de MAC mismatched, et le premier réflexe est souvent de chercher un problème d'adresse. Dans cette branche, MAC est un code d'authentification de message : une valeur calculée sur l'échange avec la clé négociée. Le pair a comparé son propre calcul à la valeur reçue, et ils différaient. Aucune carte réseau n'est impliquée, et aucun réglage d'interface ne change cette comparaison.

En pratique, deux conditions le produisent : les secrets des deux extrémités ne sont pas la même valeur, ou les identités utilisées pour sélectionner le secret ne correspondent pas. Décidez laquelle en lisant la paire, pas le tunnel isolé.

Ce que l'étape prouve

La vérification s'exécute après que les deux côtés ont échangé les paramètres initiaux et se sont identifiés. Elle sélectionne des clés partagées candidates pour les identités locale et distante et tente de valider les données d'authentification reçues ; quand aucune ne valide, le diagnostic est émis. C'est une affirmation forte sur l'authentification et faible sur la cause, car elle ne dit pas quel côté est en tort.

Un succès antérieur ne se reporte pas sur cette vérification. Un IKE_SA_INIT terminé, ou une charge de détection NAT qui a renvoyé les valeurs attendues, prouve que les pairs peuvent communiquer. Cela ne prouve rien sur le fait qu'ils partagent un secret.

Deux erreurs de configuration, un message

La première est un vrai écart de secret, et c'est généralement un accident de provisionnement : une valeur générée installée sur une console et retapée sur l'autre, un caractère de fin qui a survécu d'un côté, ou un guillemet venu avec un collage. La seconde est un écart d'identité, où le secret est correct mais l'identité présentée par le pair sélectionne une autre entrée, si bien que le bon secret n'est jamais essayé. Les deux produisent la même ligne, c'est pourquoi deviner coûte un après-midi.

Comparez la paire avant de toucher à un secret. Faites correspondre le tunnel, le point de terminaison du pair, la fenêtre temporelle et la configuration distante, car deux tunnels redondants peuvent contenir des secrets différents et l'écran devant vous n'est peut-être pas celui qui a échoué.

La détection NAT est une autre étape

La détection NAT demande comment les paquets sont réécrits, pas qui est le pair. Une passerelle client derrière NAT s'authentifie toujours correctement lorsque son identité configurée est celle que le pair attend, et un problème NAT se manifeste comme une divergence de proposition ou de port plutôt qu'une comparaison d'authentification échouée.

Ne reportez pas une ancienne affirmation sur une version de fournisseur dans un déploiement actuel. Ce que la traversée NAT exige dans votre version relève de sa propre documentation, et l'expression MAC mismatch n'est pas une preuve pour ou contre.

Décidez à partir de la paire, pas de l'écran

Lisez les deux configurations côte à côte avec le secret masqué, puis posez trois questions. L'identité de chaque côté est-elle exactement ce que l'autre attend, caractère par caractère ? Les deux extrémités utilisent-elles la même version d'IKE et la même méthode d'authentification ? Le tunnel qui échoue correspond-il à la configuration que vous lisez ? Un non à l'une d'elles décide la réparation sans toucher au secret.

Si les trois sont propres, remplacez le secret via le flux de travail approuvé plutôt que de modifier autour de lui.

Après que le pair s'authentifie

Une fois l'authentification réussie, la surface d'échec suivante est l'association de sécurité enfant : propositions et sélecteurs de trafic. Faire tourner un secret déjà accepté ne peut pas réparer un échec enfant et prolonge l'interruption. Lisez l'état de l'enfant, puis les sélecteurs et les plages protégées des deux côtés, et faites correspondre le guide de dépannage Cloud VPN à l'étape qui a réellement échoué.

Corrélez des journaux récents des deux extrémités pour la même paire et la même fenêtre. Un côté seul donne un verdict sans l'entrée de l'autre, et c'est cette ambiguïté qui a produit le message au départ.

Ce qu'il ne faut pas conclure

Ne lisez pas le message comme une demande de changer les adresses MAC, et ne publiez pas le secret partagé en demandant de l'aide ; un extrait contenant la clé doit avoir la clé retirée, pas le journal conservé. Ne supposez pas non plus une faute de routage, car des pairs qui ne peuvent pas s'atteindre ne produisent aucune comparaison d'authentification. Et ne généralisez pas une limitation documentée d'une famille de produits à toute implémentation IPsec.

Enregistrez la paire qui échoue, l'état du tunnel avant et après, et laquelle des deux conditions vous avez modifiée. Cet enregistrement fait de la prochaine occurrence une vérification de cinq minutes.