Un MAC que no coincideix a IKE significa que la comprovació de la clau compartida ha fallat
En un registre IKEv2 amb clau prèviament compartida, MAC és un codi d'autenticació de missatge. Què compara la comprovació i els dos errors de configuració que realment la causen.
El vostre registre de Cloud VPN mostra un intent amb clau compartida seguit de MAC mismatched, i el primer instint sovint és buscar un problema d'adreça. En aquesta branca MAC és un codi d'autenticació de missatge: un valor calculat sobre l'intercanvi amb la clau negociada. El parell ha comparat el seu propi càlcul amb el valor que va rebre, i diferien. Aquí no hi ha cap targeta de xarxa, i cap paràmetre d'interfície canvia aquesta comparació.
A la pràctica ho produeixen dues condicions: els secrets dels dos extrems no són el mateix valor, o les identitats que s'utilitzen per triar el secret no es corresponen. Decidiu quina és llegint la parella, no el túnel sol.
Què demostra l'etapa
La comprovació s'executa després que tots dos costats hagin intercanviat els paràmetres inicials i s'hagin identificat. Selecciona claus compartides candidates per a les identitats local i remota i intenta validar les dades d'autenticació rebudes; quan cap no valida, s'emet el diagnòstic. És una afirmació forta sobre l'autenticació i feble sobre la causa, perquè no diu quin costat és incorrecte.
L'èxit anterior no es trasllada a aquesta comprovació. Un IKE_SA_INIT completat, o una càrrega de detecció de NAT que va retornar els valors esperats, demostra que els parells poden parlar. No demostra res sobre si comparteixen un secret.
Dos errors de configuració, un missatge
El primer és un desajust real del secret, i normalment és un accident de proveïment: un valor generat instal·lat en una consola i retipat a l'altra, un caràcter final que va sobreviure en un costat, o una cometa que va arribar amb un enganxat. El segon és un desajust d'identitat, on el secret és correcte però la identitat que presenta el parell selecciona una entrada diferent, de manera que el secret correcte no s'intenta mai. Tots dos produeixen la mateixa línia, i per això endevinar costa una tarda.
Compareu la parella abans de tocar cap secret. Feu coincidir el túnel, el punt final del parell, la finestra temporal i la configuració remota, perquè dos túnels redundants poden tenir secrets diferents i la pantalla que teniu davant potser no és la que ha fallat.
La detecció de NAT és una etapa diferent
La detecció de NAT pregunta com es reescriuen els paquets, no qui és el parell. Una passarel·la de client darrere de NAT encara s'autentica correctament quan la seva identitat configurada és la que el parell espera, i un problema de NAT es mostra com una discrepància de proposta o de port en lloc d'una comparació d'autenticació fallida.
No porteu una afirmació antiga sobre una versió de proveïdor a un desplegament actual. El que el trànsit NAT requereix a la vostra versió pertany a la seva pròpia documentació, i la frase MAC mismatch no és evidència a favor ni en contra.
Decidiu a partir de la parella, no de la pantalla
Llegiu les dues configuracions una al costat de l'altra amb el secret ocultat, i després feu tres preguntes. La identitat de cada costat és exactament la que l'altre espera, caràcter a caràcter? Els dos extrems utilitzen la mateixa versió d'IKE i el mateix mètode d'autenticació? El túnel que falla correspon a la configuració que llegiu? Un no a qualsevol d'aquestes decideix la reparació sense tocar el secret.
Si les tres estan netes, substituïu el secret pel flux de treball aprovat en lloc d'editar al voltant.
Després que el parell s'autentiqui
Un cop l'autenticació té èxit, la següent superfície de fallada és l'associació de seguretat filla: propostes i selectors de trànsit. Rotar un secret que ja s'ha acceptat no pot arreglar una fallada filla, i allarga la interrupció. Llegiu l'estat de la filla, després els selectors i rangs protegits als dos costats, i feu coincidir la guia Resolució de problemes de Cloud VPN amb l'etapa que realment ha fallat.
Correlacioneu registres nous dels dos extrems per a la mateixa parella i la mateixa finestra. Un costat sol dona un veredicte sense l'entrada de l'altre, i aquesta és l'ambigüitat que va produir el missatge des del principi.
Què no cal concloure
No llegiu el missatge com una exigència de canviar adreces MAC, ni publiqueu el secret compartit mentre demaneu ajuda; un extracte que conté la clau necessita la clau eliminada, no el registre conservat. No assumiu tampoc una fallada d'encaminament, perquè els parells que no es poden abastar no produeixen cap comparació d'autenticació. I no generalitzeu una limitació documentada d'una família de productes a tota implementació IPsec.
Registreu la parella que falla, l'estat del túnel abans i després, i quina de les dues condicions heu canviat. Aquest registre converteix la propera aparició en una comprovació de cinc minuts.