OpenVPN 全局代理实战：路由、策略与配置全解析

• 把所有流量推入隧道：为什么要认真对待“全局代理”
• 核心原理：路由表、策略路由与隧道行为
• 常见策略与它们的利弊
• 实战场景与应对方法
• 场景一：办公网段需同时访问内网资源与海外服务
• 场景二：防止漏流（kill switch）
• 场景三：多隧道/多出口并存
• 调试与诊断工具（与使用场景）
• 性能与安全注意事项
• 常见踩坑与经验汇总
• 结论性建议（技术取向）

把所有流量推入隧道：为什么要认真对待“全局代理”

在翻墙场景中，“全局代理”看起来是最直接的解决方案：把客户端的默认路由指向 VPN 隧道，所有流量从出口服务器出站，一切看起来简单且直观。但实际部署时会遇到路由冲突、内网访问中断、DNS 泄漏、性能瓶颈等问题。本文不含配置片段，侧重原理剖析与实战策略，帮助你在部署 OpenVPN 全局代理时做出稳健的选择。

核心原理：路由表、策略路由与隧道行为

理解 OpenVPN 的“全局”特性，关键在于三部分：路由表（Routing Table）、策略路由（Policy Routing / ip rule）和隧道设备（tun/tap）。当服务器通过推送命令将默认网关改向隧道（redirect-gateway），客户端的主路由表会被修改，默认下一跳从本地 ISP 变成 VPN 服务器。与此同时，DNS 配置通常也会被替换或追加，避免域名解析走本地 ISP。

但是路由表是系统级的，操作系统在处理多网卡、多路由时有自己的优先级。Linux 下还可能存在多表路由、ip rule 匹配等复杂行为；Windows 的路由优先级与 Metric 也会影响结果。理解这些机制能够帮助定位“为什么有些流量没有走隧道”或“为什么 LAN 无法访问”的问题。

常见策略与它们的利弊

1）全局转发（默认路由全部走 VPN）
优点：一键翻墙，所有流量均由 VPN 出口，规避地域限制和 ISP 局限。缺点：本地局域网资源不可达（如打印机、NAS），若 VPN 中断可能导致流量回落到本地，产生泄漏；性能压力集中在单一出口。

2）分流（Split Tunneling）
优点：只把目标流量（如国外 IP、大部分流量）走隧道，本地资源保留，减少带宽占用。缺点：需要精准路由/域名解析规则；复杂环境下规则维护成本高，DNS 泄漏风险存在。

3）策略路由（基于用户/进程/端口）
优点：更细粒度的控制，能指定某些用户或程序走 VPN。缺点：通常依赖操作系统或第三方工具（如 netfilter、policy routing），配置繁琐，跨平台支持差异大。

实战场景与应对方法

场景一：办公网段需同时访问内网资源与海外服务

如果把默认路由全部替换为隧道，内网访问（例如公司文件服务器、打印机）会失效。可采用分流策略，仅将外网目的地（或明确需要翻墙的子网）通过隧道路由，而保留本地网段的直连路由。

实现思路：服务端不强制推送默认路由，客户端接受特定路由或使用 route-nopull 后手动添加直连内网路由。配合 DNS 分离（内网域名走内网解析器，公共域名走 VPN 提供的解析）可避免解析失败。

场景二：防止漏流（kill switch）

当 VPN 断开时，系统可能瞬间回退到本地网关，造成敏感流量泄漏。可靠的做法是配合防火墙规则，当隧道不可用时阻断相关流量——例如仅允许流量通过 tun 设备，禁止直连外网。当然这取决于操作系统的防火墙能力与规则优先级。

场景三：多隧道/多出口并存

当设备同时建立多个 VPN（例如同时连接工作 VPN 和翻墙 VPN），路由冲突变得复杂。此时应使用策略路由将不同来源的流量分发到不同表，或者在应用层指定代理。清晰的路由表策略与 ip rule 顺序对保持稳定至关重要。

调试与诊断工具（与使用场景）

有效排查路由问题依赖于一组基础工具：查看系统路由表、检查 DNS 配置、抓包与日志。

常见检查点：

• 路由表：确认默认路由的下一跳是否指向 tun 设备，以及是否有覆盖性的更高优先级路由。
• DNS：验证系统是否使用 VPN 提供的解析器，检查 /etc/resolv.conf 或系统 DNS 配置是否被修改。
• 抓包：通过抓包工具观察 SYN 包出接口（本地网卡或 tun），定位漏流来源。
• OpenVPN 状态与日志：确认服务器推送的路由、客户端是否执行了路由变更。

性能与安全注意事项

全局代理会把所有流量集中到 VPN 出口，带来带宽、延迟与 MTU 问题。MTU 不匹配可能导致分片，从而影响 TCP 性能。加密本身也有 CPU 开销，尤其在移动设备或路由器上需关注加密算法与硬件加速支持。

从安全角度来说，确保服务器端正确配置防火墙与 NAT，避免将内网路由错误暴露；启用强密码学套件、leak-prevention（DNS/IPv6）措施，并对服务器日志进行定期审计。

常见踩坑与经验汇总

• 不要盲目接受服务器推送的所有路由，理解每一条路由的含义再决定是否添加。
• 在多平台支持时测试差异：Windows、Linux、macOS 在路由优先级、DNS 行为上各不相同。
• 考虑用户体验：全局模式虽简单，但在有局域网资源需求的场景下会造成大量用户投诉，提供“全局/分流/仅 DNS”切换更友好。
• 对于家庭路由器安装的 OpenVPN，应优先考虑在路由器端做隧道出口与策略路由，减轻客户端配置负担。

结论性建议（技术取向）

在选择“全局代理”方案时，优先明确使用场景与安全边界：是否需要访问内网资源？是否容忍单点出口性能瓶颈？是否必须避免任何流量泄漏？基于这些需求选择全局或分流，结合策略路由与防火墙做熔断/kill-switch，最终在设备上实施前在受控环境反复测试。

OpenVPN 的灵活性使其能够满足从家庭到企业的多种需求，但也正因此需要对路由机制、DNS 行为与操作系统差异有较深入理解。掌握这些后，你就能在“简单可用”和“安全可靠”之间找到合适的平衡。