IKE 中 MAC 不匹配，意味着共享密钥校验失败

你的 Cloud VPN 日志显示一次共享密钥尝试，随后出现 MAC 不匹配，而第一反应往往是去找地址问题。在这个分支里，MAC 是消息认证码：用协商出的密钥对这次交换计算出的值。对端把自己算出的值与收到的值比较，两者不同。这里没有网卡参与，也没有任何接口设置能改变这项比较。

实践中由两种条件产生：两端的密钥值不同，或者用于选择密钥的身份并不对应。要靠阅读这一对配置来判断是哪一种，而不是只看单条隧道。

这一阶段证明了什么

校验在双方交换完初始参数并表明身份之后运行。它为本地和远端身份挑选候选共享密钥，并尝试验证收到的认证数据；当没有一个通过时，就输出该诊断。这是对认证的强论断、对原因的弱论断，因为它没有说明哪一端错了。

先前的成功不会带入这项校验。一次完成的 IKE_SA_INIT，或者一个返回了预期值的 NAT 检测载荷，只能证明两端能通话。它不能证明两者是否共享同一个密钥。

两类配置错误，同一条消息

第一类是真正的密钥不一致，通常是一次配置事故：生成的值装在一台控制台上，却在另一台上重新键入；某个尾随字符在一端留了下来；或者粘贴时带进了一个引号。第二类是身份不一致：密钥本身正确，但对端出示的身份选中了另一条记录，于是正确的密钥从未被尝试。两者输出同一行日志，所以靠猜要花掉一个下午。

在动任何一个密钥之前，先比较这一对配置。让隧道、对端端点、时间窗口和远端配置都对应上，因为两条冗余隧道可能持有不同的密钥，而你眼前的界面未必是失败的那一条。

NAT 检测是另一个阶段

NAT 检测问的是报文如何被改写，而不是对端是谁。位于 NAT 之后的客户网关，只要其配置的身份正是对端所期望的，仍然能正确认证；NAT 问题表现为提议或端口不匹配，而不是认证比较失败。

不要把关于某个厂商版本的旧说法带进当前部署。你的版本对 NAT 穿越有什么要求，属于它自己的文档，而「MAC 不匹配」这句话既不支持也不反对。

依据这一对配置判断，而不是依据界面

把两份配置并排阅读，隐去密钥，然后问三个问题。每一端的身份是否与另一端期望的逐字符完全相同？两端是否使用同一 IKE 版本和同一种认证方法？失败的隧道是否就是你正在读的这份配置？任何一问为否，都能在不碰密钥的前提下确定修法。

如果三项都干净，就通过已批准的流程替换密钥，而不是绕着它改。

对端认证通过之后

一旦认证成功，下一个故障面是子安全联盟：提议和流量选择器。轮换一个已经被接受的密钥修不好子级故障，还会拉长中断时间。先读子级状态，再读两侧的选择器和受保护网段，并把 Cloud VPN 故障排查 指南对应到真正失败的那个阶段。

把两端针对同一对端、同一时间窗口的新日志关联起来。只看一端就会在缺少另一端输入的情况下下结论，而最初产生这条消息的正是这种含糊。

不该得出什么结论

不要把这句消息读成要求修改 MAC 地址，也不要在求助时公开共享密钥；含密钥的片段需要把密钥去掉，而不是把日志留下。也不要假定是路由故障，因为彼此不可达的对端根本不会产生认证比较。更不要把某个产品族有文档记录的局限推广到所有 IPsec 实现。

记录失败的那一对、隧道前后的状态，以及你改动了两种条件中的哪一种。这份记录会把下一次故障变成五分钟的检查。