auth 摘要究竟保护哪些 OpenVPN 数据包
auth 选项覆盖的范围比配置文件给人的印象更窄。先理清通道、AEAD 情形与控制通道保护，再决定摘要策略。
关于 OpenVPN 摘要的多数争论都从一个错位的包开始。把 auth SHA256 读成“只接受提供 SHA256 的对端”，是首先要丢掉的想法。这个选项为特定数据包指定摘要，而究竟是哪些包，取决于通道以及该通道是否为 AEAD。按顺序走完下面四个问题；每一个都会收窄该设置在部署中的含义。
先命名该设置要保护的通道
OpenVPN 有一条承载 TLS 握手流量的控制通道，以及一条承载隧道负载的数据通道。auth 摘要在两者中都有作用，但作用并不相同，而配置文件很少把差别显现出来。动配置文件之前，先写下你要约束的是哪一条。
下表是同一选项在各语境中落点的简版。
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
在依赖它之前，先确认数据通道是否为 AEAD
如果协商出的数据加密算法是 AES-GCM 或 CHACHA20-POLY1305，数据通道会自行完成认证，单独的摘要并不承担你想象中的那项工作。两者都是 AEAD 构造，完整性由加密负载的同一运算产生。这不是降级，但它意味着“每个数据包都是 HMAC-SHA256”这样的理由在该隧道上并不成立。改写策略之前，请在服务端日志或客户端状态输出中确认协商值。
要检查实际协商出的算法，而不是配置文件里的候选列表，因为协商可能落到集合中的另一个成员。data-ciphers AES-256-GCM:AES-128-GCM 是一份用于协商的列表，两个条目都是 AEAD，所以它们都不会为负载保护消耗 auth 摘要。
把控制通道保护当作独立决策
tls-auth 给控制通道的数据包加上 HMAC，其摘要取自 auth 设置，因此 AEAD 隧道仍然可以配置有意义的摘要。tls-crypt 是另一种安排，带有自己固定的保护，所以不要假定它继承 tls-auth 的每一项属性。要去读你所选机制的文档，而不是在两者之间搬运假设。
对端双方还必须在安排和密钥方向上达成一致。摘要匹配但密钥文件方向用反，会让握手因摘要设置无法解释的原因而失败。
把 auth 与加密算法协商、证书分开看
有三项设置经常被混为一谈：auth 摘要、数据加密算法列表以及证书的签名算法。改第一项不会重新签发证书，不会选择证书的签名摘要，也不会创建用户名口令方式。协议选项的定义见 OpenVPN 2.6 源码 ，各自独立成节，这正好提醒它们是彼此独立的旋钮。
改动摘要后对端拒绝连接时，原因通常是另外两项设置之一不匹配。改任何一项之前，先把两端都读完。
把策略写下来，并与运行中的配置对照
队列级别的表述应当在同一句话里明确写出允许的数据通道模式与所选的控制通道保护。那句话是可验证的；“我们用 SHA256”则不是。然后拿它去对照实际生效的服务端与客户端配置，而不是仓库里的模板。
最后记录每条隧道实际协商了什么、由哪种机制认证了它的数据包。配置文件里看得见的 auth 行只是配置意图的证据，而意图是检查中最便宜的一环。