OpenVPN 数据包 HMAC 认证失败：问题在哪一层？

两种故障共用同一套说法，而它们几乎毫无共同点。一种是收到的数据包认证标签未通过校验；另一种是某个人的凭据被拒绝。把前者当成后者，你便会去寻找一个从来就不是问题的密码。

这条消息点明的是某一层，而在更换任何材料之前先确定是哪一层，才是有用的工作。把候选对象并排比较，是看清差别的最快方式。

两种故障只有一字相同

数据包认证错误是在处理流量时抛出的：收到数据包上的标签或摘要与接收方计算的结果不符。账号被拒绝发生在登录交换被解析之后，它点名的是用户而不是数据包。第三种消息讲的是在传入数据包中找不到 HMAC，那又不一样，因为这种情形里数据包根本没带上预期的认证元素。完整的日志前缀会告诉你是三者中的哪一种，而把错误粘贴到工单里时，最先被删掉的往往正是这个前缀。

这个区分会改变修法。一种要的是控制通道设置相匹配，另一种要的是账号状态，第三种要的是一个与它所到达的监听端不匹配的配置文件。

对比运行中的进程实际加载了什么

磁盘上文件正确，并不能证明在它被修改之前就已启动的进程是对的。要检查选中的配置文件、它所连接的端点，以及更改之后服务有没有重新加载。还要确认该端点属于这个配置文件，因为在旧文件期待别的东西的地方，可能正由另一个实例或另一项服务在监听。

从同一来源重新导出一份受支持的配置文件是廉价的对比，因为它消除了你以为已配置的内容与客户端实际发送的内容之间的偏差。生成全新的密钥材料是更大的动作，只有两端一起采用才有帮助。只在本机替换一端，会重新造出你正想消除的不匹配。

对比控制通道与数据通道

两种机制认证连接的不同的部分，并且分别配置，正如 2.6 版本选项手册 所述。tls-auth 为控制通道的数据包加上 HMAC，并接受一个方向参数，该参数在对等两端必须相反；而 tls-crypt 则改用共享密钥来保护控制通道。两者都不是数据通道自身完整性校验。使用 AEAD 数据密码时，这项校验已内建在密码里，所以单独的 auth 摘要不会像非 AEAD 密码那样被使用。

这意味着，从可用的非 AEAD 部署里抄来的 auth 那一行，在 AEAD 部署里可能无关紧要；而如果 tls-auth 密钥或其方向有误，AEAD 部署仍可能在控制通道上失败。要把每一项设置与对端比较，而不是与记忆里的配置比较。

把修法与你要放弃的属性放在一起比较

关闭数据包认证会让警告消失，也会移除那个发现不匹配的校验，这不等于修好了配置文件。要问清楚你放弃了哪项属性，以及没有它这套设计是否还成立。

在动手改动之前，先读两端最早的相关事件，然后只改它点明的那处不匹配。

如果下一次尝试推进到证书或登录错误，那是进展而不是倒退：数据包层现在一致了，连接已经往前走。把促成这次变化的设置记录下来，让下一个人继承的是一份解释，而不是一个谜。