OpenVPN 压缩：拒绝、只接收还是完整的 LZO？

配置文件里的三行看起来都会关闭压缩，而真正做到的只有一行。差别之所以重要，是因为你想消掉的告警只是症状，而策略才决定对端还能不能压缩。把这些选项放在同一根轴上比较，也就是看变更之后各自允许什么，大部分歧义就消失了。该选哪一个，取决于你是在迁移还是已经稳定下来。

三套在配置文件中看起来相似的政策

每个选项回答的是不同的问题。allow-compression no 直接拒绝压缩载荷，allow-compression asym 只解压收到的数据而从不压缩发出的数据，旧的 comp-lzo no 则留有让对端推送开启压缩的余地。只有第一项是服务器无法覆盖的策略。

选择之前先把这三项写进一张表，因为名字相近到足以误导评审者。其中两项仍会对收到的数据包运行解压代码，安全论证说的正是这一点。第三项是移除这项能力，而不是限制它的方向。如果变更记录写着压缩已禁用，那么恰好只有一行满足这句话。

引发调查的那条告警并不是目标。在保留宽松策略的同时让它安静，得到的只是干净的日志和不变的暴露面。

旧的 LZO 选项里 no 到底是什么意思

在已弃用的 LZO 选项里，no 会关闭本地的压缩，却不禁止对端在策略允许的地方开启压缩。正是这种不对称，使得把配置文件换成严格拒绝后，行为变化方式可能在单服务器实验室测试中永远显露不出来。

安全担忧是有条件的，而不是绝对的。当攻击者能把选定的明文放在秘密旁边，并观察压缩如何改变加密流量的大小时，信息通道就存在。从 LZO 换到 LZ4 改变的是算法和分帧方式，而不是那个机制。

所以诚恳的表述关心的是你愿意允许什么，而不是当下推荐哪个算法。严格拒绝是唯一不依赖对端配合的选项。

只接收是迁移状态，不是终点

非对称接受之所以存在，是为了让一端能停止压缩，而另一端仍然期待压缩。它是一座桥，而桥需要结束日期和负责人。记录哪些对端仍在发送压缩流量，因为策略允许的正是这类流量。没有这份清单，迁移状态就会因惰性变成永久配置。

客户端无法靠修改自己的文件来强迫不兼容的服务器放弃旧分帧。推送方向由服务器决定，所以迁移真正完成的地方是服务器配置及其按客户端划分的文件。

stub 模式保留分帧却跳过压缩工作本身，它们并不是旧选项的直接替代品。在决定采用之前，请拿你仍需支持的最老对端来测试。

数据通道卸载在哪里改变答案

数据通道卸载把数据包处理搬进内核，而仍依赖压缩分帧的配置可能不适合这条路径。失败并不总是响亮的：客户端连上了，随后的行为却和你测试的隧道不一样。

要检查变更前后哪个实现处于活动状态，而不只是连接是否成功。当卸载路径拒绝压缩分帧时，严格拒绝策略与卸载部署是一致的，而宽松策略与卸载部署则不一致。

这种组合值得单独测试，因为看起来正确的文件，恰恰在那里悄悄不是真正生效的那一个。把协商出的状态与配置文件中记录的意图相比，因为只有其中之一会出现在日志里。

先选一套策略，再验证协商结果

两端都能改时选严格拒绝，暂时不能时选非对称接受，只有在能说清暴露为何可接受时才选完全压缩。然后验证协商出来的结果，而不是文件里写了什么。更安静的日志只有在与你要部署的策略一致时才算证据。

把决定放在它所适用的配置文件旁边，写明日期和仍然豁免的对端。半年之后，这条备注就是有意为之的例外与无人能说出日期的意外之间的差别。把它写进与配置文件同一个仓库，让下一位编辑在指令之前先看到理由。