塑造 OpenVPN 流量：哪个接口能看到它？

逐项过四道检查：你要限制什么、哪个数据包携带识别它的信息、整形器能看到哪个接口，以及路由器在加密时还能承受多少。路由器同时附带 OpenVPN 页面和带宽页面，两者并存并不能证明其中任何一个可用。顺序很重要，因为针对错误数据包写下的规则永远不会命中，无论其速率多么正确。

从目标开始：限制单台设备、公平分享容量，还是优先某个应用。三者各自需要不同的匹配条件。

先写下目标，再写规则

按设备限速需要匹配该设备的地址，而该地址只存在于隧道内部。竞争流之间的公平需要一个它们共享的队列，而不是每台主机一条规则。应用优先级需要能识别应用的东西，一旦加密让内层包头从视野中消失，这是三者中最难的。先把目标写下来，才能知道你究竟需要哪个事实，以及可能从哪里取得它。

在直连 WAN 流量上生效的限速，并不能证明同一台主机在隧道内也被覆盖。规则可能匹配的是一个永远不会出现在整形器所见包头中的地址。

在隧道之内还是之外

使用路由器自带的 VPN 客户端时，许多 LAN 流都在同一条加密传输中穿行。封装之前，路由器仍能看到内层源地址和目的地址，因此在这一阶段附加的策略可以按设备分类。封装之后，普通设备只能看到 外层连接，匹配 VPN 端口并不能说明是哪台设备造成的流量。正是这一事实决定了规则该放在哪里。

各平台暴露这一信息的方式不同。有些提供在隧道接口上排队并分类的整形器；有些把限速器当作接口规则，对 VPN 与非 VPN 流量行为相同；有些则以不同的能力同时做到两者。与其照抄另一家厂商指南里的接口名，不如阅读固件自己关于所支持接口的文档。

确认地址在哪里仍然可用、地址转换发生在哪里，以及哪条队列真正控制着瓶颈。

三种策略，三种证据

限速要靠被限设备的持续传输来证明，同时另一台设备也在传输。公平分享要靠两条流达到相近速率来证明，而不是一条被饿死，这是另一种测量。应用优先级要靠大流量传输期间交互式任务仍保持响应来证明，并检查分类器是否真的识别了这条流。每种策略都需要各自的观测，没有任何一种能靠配置页面证明。

分类尤其值得怀疑。匹配外层加密端口无法还原每个内层应用的身份，所以一条看似优先某个应用的规则，实际可能优先了来自该隧道的所有流量。要看规则的计数器，而不是它的意图。

测量加密后的负载，而不是裸机负载

整形、分类和加密争抢同一个 CPU，硬件加速还可能让流量绕过你正在观察的那些规则和计数器。普通路由测试得到的吞吐数字，说明不了加密并整形负载下的设备表现。两个方向都要测，多台有代表性的客户端，并在大流量传输的同时跑一个小交互任务。负载下的响应性比空闲链路上的峰值数字更重要。

把例外也纳入测量：应当绕过隧道的流量、双方都在用时两个地址族，以及隧道断开时会发生什么。只在隧道健康时才表现合理的策略，只能算半个策略。

把规格写成三行：流量匹配、执行点和被测负载。OpenVPN 加 QoS 不是规格。