tls-auth 与 tls-crypt：OpenVPN 中各自保护什么

两个选项都使用同一个共享密钥文件，也都让握手流量更难被伪造，因此常被当成同一功能的两套名字。其实不是。一个为控制包签名，另一个还会加密它们，两者都与保护你数据的加密算法无关。

当某个配置文件连不上、安全评审追问密钥到底保护什么，或者有人以为多出这个文件就能以某种不明方式让隧道加密时，这个区别就有意义了。

共享密钥真正保护的是什么

这两个选项使用的密钥属于控制通道：负责协商参数、证明身份并派生数据密钥的那次交换。它是双方在握手继续之前都必须持有的预共享秘密。由于它位于身份校验之前，密钥不对会在比密码不对更早的阶段终止对话。正是这个顺序解释了为什么故障表现得如此安静。

tls-auth 用这个秘密对控制包计算 HMAC。没有有效签名的数据包在被送入代价更高的 TLS 处理之前就被丢弃，因此这项选项常被描述为第一道过滤器，而不是 TLS 的替代品。

tls-crypt 更进一步：它除了认证受保护的控制流量，还会对其进行加密。证书内容、协商出来的加密套件名称和其他握手细节都不再出现在网络上，没有密钥的观察者甚至看不出正在尝试哪个 TLS 版本。对于担心暴露 VPN 指纹的部署来说，这正是选择它的主要理由。它依然是群组机密，而不是每个用户各自的凭证。

两种机制都不签发身份。共享密钥是群组机密，任何持有它的人都能通过这一层检查。

两个选项的差异在哪里

可观察到的差异在于旁观者能看到什么。使用 tls-auth 时，握手可见，但没有密钥就无法校验。使用 tls-crypt 时，握手对任何没有密钥的人都是不透明的。

配置方式也不同。tls-auth 搭配方向值使用，因此一侧使用密钥材料的一半，另一侧使用另一半。tls-crypt 两个方向共用一把密钥，因此方向指令不属于它的配置结构。

在现代版本中，两个选项互斥。配置文件应当只带其中一个，而不是两个都带，服务器与客户端必须就用哪一个达成一致，并且密钥材料相同。把旧指令和新指令并排保留是常见的迁移残留。删掉不生效的那条，下一位读者才能知道哪一层真正起作用。

较新的变体 tls-crypt-v2 把每个客户端绑定到它自己那份被包裹的密钥，因此吊销单个客户端不需要重新签发群组密钥。这值得了解，但它是另一个选项，并非此处两者中任何一个的同义词。

为什么密钥不匹配时看起来什么也没发生

当共享材料不一致时，对端会直接丢弃数据包，而不告诉发送方原因。没有认证错误可供阅读，因为数据包根本没到达会产生错误的那一层。

客户端不断重试，服务器一言不发，症状看起来像网络问题。于是人们重启服务、重新输入账号密码，或者为了“测试”而删掉保护指令——那是在改变部署，而不是在诊断问题。

在服务器日志里找第一条数据包层面的报错，而不是最后一行重试记录。确认两端携带同一个选项且密钥材料完全一致，并确认密钥文件不是只在某一侧重新生成过。

删掉指令并不是安全的修复。它会对每个客户端关闭一层保护，之后隧道能通只能证明这一层就是不一致之处。

还有哪些必须单独配置

这些选项并不校验对端是谁。证书校验、信任锚点和预期服务器名称仍是彼此独立的要求，不会因为存在共享密钥就变成可选项。

它们也不负责选择数据加密算法。那是另一场协商，由两端的数据通道设置控制，而由 tls-crypt 保护的隧道仍可能使用你并不想要的算法。

最后，共享密钥本身也需要妥善处理。把它当作机密，经批准的渠道分发，并在任何曾持有它的人离开时更换。由于它是共享的，它一旦泄露，就等于每个使用它的端点都泄露了。