- 为什么要给 OpenConnect 做带宽限速
- 限速的基本思路与关键位置
- 常用限速工具与机制
- 从思路到实战：配置流程（文字引导）
- 举例性的参数设计思路（非命令）
- 按用户名/会话限速的实现挑战
- 不改内核的替代方案
- 优缺点对比与选型建议
- 常见问题与排障方向
- 未来趋势（简要）
- 结论（要点回顾）
为什么要给 OpenConnect 做带宽限速
在个人或小型 VPN 服务器上，OpenConnect（或其服务端 ocserv）常常把所有客户端的流量汇聚到一条虚拟接口（通常是 tun0）。如果不做限速，某个用户或进程的突发下载就可能把整台服务器的上行/下行吃满，影响其他用户体验，也可能触发宿主机的带宽套餐阈值。给 OpenConnect 加入带宽限制，能实现公平共享、流量控制和防止滥用。
限速的基本思路与关键位置
从网络栈角度看，OpenConnect 的流量要么经过内核的 TUN/TAP 虚拟接口，要么被用户空间进程转发。因此常见的限速点有：
- 虚拟接口（例如 tun0）上做整体或按IP/子网的流量控制；
- 宿主机的物理网口（eth0）上做出口方向的形态控制；
- 应用层代理（如 SOCKS/HTTP 代理）对单连接或单用户做限速；
- 更细粒度的实现可用 eBPF 或 cgroup 来根据进程或容器做流量分类与限速。
常用限速工具与机制
在 Linux 上，最常见的流量控制工具是 tc（traffic control），配合 qdisc（队列规则）和 class（类）可以实现非常灵活的限速策略。常用的 qdisc 包括 HTB（层次令牌桶）用于长期带宽分配和优先级管理，TBF（令牌桶过滤器）用于平滑突发流量。
为实现按用户或会话限速，常见做法是先用 iptables 或 nftables 标记（mark）流量，然后让 tc 根据 mark 做过滤分类。另一种方式是基于分配给 VPN 客户端的虚拟 IP（或固定 IP 池）直接按源/目的 IP 做过滤。
从思路到实战：配置流程（文字引导）
下面以“按客户端 IP 做公平分配”为例，给出可落地的步骤说明（不展示完整脚本，重点描述步骤与原理）：
- 确认接口与流向：使用 ip addr 和 ip route 确认 OpenConnect 使用的虚拟接口名（通常 tun0）。决定你要控制的方向：限制“出口到公网”的速率一般在物理网口的输出方向控制；若要限制 VPN 客户端之间或单客户端出入口则在 tun0 上控制。
- 选择 qdisc 与策略：如果需要多等级分配（比如基础带宽+突发保留），选择 HTB；如果是简单的全局上限，TBF 更轻量。
- 建立根队列并创建类：为 tun0 创建一个 root qdisc，并在其下创建若干 class，例如“总带宽 100Mbps -> 为每个客户端分配 5Mbps 保证/20Mbps 峰值”。
- 流量分类：使用 iptables 给不同客户端的流量打上不同的 fwmark。打 mark 的依据可为客户端分配的虚拟 IP、VPN 登录用户名（如果能在 iptables 中识别）或证书指纹映射的固定 IP。
- tc 过滤绑定：在 tc 中增加 filter，根据 fwmark 或 ip4 src/dst 将流量导向对应的 class。
- 监控与调整：通过 tc -s qdisc / iftop / nethogs / vnstat 等观察实际带宽占用，必要时调整 class 的速率与优先级。
举例性的参数设计思路（非命令）
假设服务器总出口是 200Mbps，你希望给每个在线客户端分配“保证 5Mbps，最大 20Mbps”。可以把根 class 设置为 200Mbps，然后为每个客户端创建子类，分别设定 ceil（允许的最大速率）为 20Mbps，rate（保证速率）为 5Mbps。再为低优先级的流量（比如 P2P）设置更低的 rate 并加上更严格的 policing。
按用户名/会话限速的实现挑战
OpenConnect 客户端通常在 VPN 建立后由服务器分配虚拟 IP。要做到精确的“按用户名限速”需要将用户名映射到固定的虚拟 IP 或在认证时写入策略，以便 iptables 能识别并打上相应标记。某些 ocserv + PAM 或脚本化的认证流程可以在用户登录时分配固定 IP 或调用脚本来更新 tc/iptables 规则，实现实时生效。
不改内核的替代方案
- 在应用层使用代理（如 squid、haproxy 或基于 SOCKS 的限速代理），把 OpenConnect 配置成仅做加密通道，流量再过代理进行带宽控制；这对网页/HTTP 场景友好，但对 UDP 或非代理协议支持有限。
- 如果使用容器化部署，可用 cgroup v2 的 net_cls 或 eBPF 程序做流控，便于按容器或进程做精确限制。
优缺点对比与选型建议
把限速放在 tun0（虚拟接口）上的优点是简单、可覆盖所有协议；缺点是对“按用户名”需要额外映射机制。把限速放在物理网口能确保宿主机出口不被吃满，但对内部不同用户的区分能力弱。应用层代理能做很细的策略（按 URL、Content-Type），但需要所有流量经过代理，配置复杂。
常见问题与排障方向
- 限速不生效：检查 tc filter 匹配条件是否与实际流量一致（源/目标 IP、端口、fwmark）；确认 qdisc 已附加到正确的接口与方向。
- 突发流量瞬间超限：为避免突发队列积累，合理设置 burst、latency 或使用 TBF 来平滑。
- 监控数据与感受不一致：部分流量（如 UDP）短时内难以完全统计，建议用多种工具交叉验证并观察内核的 qdisc 统计信息。
未来趋势（简要）
随着 eBPF 的成熟，越来越多的人会用 eBPF + tc/bpf 实现用户态可编程的分类与调度，具备更低的开销与更细粒度的控制能力。对于云原生环境，cgroup v2 与 eBPF 的组合也更易于按容器或租户做限速，相比传统 tc 的静态规则更灵活。
结论（要点回顾）
为 OpenConnect 做带宽限速，核心是确定限速点（tun0 或物理出口）、选择合适的 qdisc（HTB/TBF）、并用 iptables/nftables 标记实现按用户/会话的分类。监控与逐步调优是保证策略生效的关键。对于追求更高灵活性的场景，可考虑应用层代理或基于 eBPF 的新方案。
暂无评论内容