- 同时运行 WireGuard 与 OpenVPN 时常见的麻烦与直观表现
- 冲突背后的常见根因
- 一步步诊断：从外到内，缩小问题范围
- 1. 确认接口与隧道状态
- 2. 检查路由表与默认路由
- 3. 确认 DNS 配置
- 4. 测试连通性与路径追踪
- 5. 检查防火墙与 NAT 规则
- 快速修复策略：针对常见问题的可操作方法
- 场景：两个隧道争默认路由
- 场景：DNS 被覆盖或解析异常
- 场景：防火墙规则冲突
- 场景：分片或 MTU 导致应用异常
- 场景：IP 段重叠
- 两个实际案例：故障到恢复的路径
- 防止未来问题的最佳实践
- 结语风格的提示
同时运行 WireGuard 与 OpenVPN 时常见的麻烦与直观表现
在家用路由、VPS 或开发机上并行运行 WireGuard 与 OpenVPN 很常见：一方用于个人隧道，另一方用于公司或备用出口。表面上两者只要接口存在、隧道建立即可，但实际经常会遇到连不上某些站点、DNS 污染、路由走错出口、甚至流量全部被本地阻断等问题。典型表现包括网页加载超时、内网资源无法访问、外部 IP 与期望不一致、DNS 查询频繁超时等。
冲突背后的常见根因
要把问题拆开看，往往不是 VPN 软件本身“互相干扰”，而是系统网络栈中几类资源被竞争或错误配置导致。常见的根因如下：
- 路由表冲突：两个隧道都尝试把默认路由或特定子网路由指向自己的虚拟接口，系统只能按优先级选择一条。
- DNS 解析冲突：VPN 客户端推送不同的 DNS，或 systemd-resolved 与传统 /etc/resolv.conf 管理冲突，导致解析结果不一致。
- 防火墙/NAT 规则覆盖：iptables 或 nftables 规则被后启动的客户端修改，导致原有的规则失效或被覆盖。
- MTU 与分片问题：不同隧道的 MTU 设置不一致，引起分片或 PMTU 问题，造成部分应用连接失败。
- IP 地址冲突：两个隧道分配了重叠的私人网段，使内网路由歧义。
- 策略路由误配：未正确设置源地址或策略路由表，导致返回包走错出口（路由对称性破坏）。
一步步诊断：从外到内，缩小问题范围
遇到并行运行时的问题，按以下顺序排查能最快定位根源。
1. 确认接口与隧道状态
首先检查两套隧道是否都处于“已建立”状态、各自的虚拟接口是否有正确的本地 IP。若某一端完全未建立，应优先解决握手/证书/密钥问题。
2. 检查路由表与默认路由
查看系统路由表，关注默认路由（0.0.0.0/0 或 ::/0）以及针对目标网段的具体路由条目。判断哪些流量被指向 WireGuard，哪些被指向 OpenVPN。注意路由条目的优先级和 metric 值。
3. 确认 DNS 配置
看当前系统使用的 DNS 是谁提供的（本地缓存、VPN 推送还是 DHCP），并分别对域名解析做结果比对。如果解析结果在不同 VPN 下返回不同 IP，可能导致连接走向不可达的后端。
4. 测试连通性与路径追踪
针对失效的目标做逐跳追踪、分段测试（先 ping 本地网关、VPN 对端、目标 IP），以确定断链是发生在本地出口、VPN 隧道内还是远端服务器。
5. 检查防火墙与 NAT 规则
查看当前的防火墙链（如 INPUT/OUTPUT/FORWARD 或 nftables 表），留意是否有规则覆盖了虚拟接口或篡改了源/目的地址。也要检查 MASQUERADE / SNAT 规则是否按接口区分清楚。
快速修复策略：针对常见问题的可操作方法
根据诊断结果，下面是一些行之有效且易于实现的修复方法。
场景：两个隧道争默认路由
如果你希望一个隧道作为全局出口、另一个仅用于访问特定内网资源，解决办法是：让仅用于内网访问的隧道不要推默认路由，而是添加精确的路由条目指向目标子网；或者调整默认路由的 metric，让优先出口固定。另一种更稳妥的方法是采用策略路由，按源地址或进程标记区分流量走向。
场景：DNS 被覆盖或解析异常
确保系统的 DNS 管理方式一致。若使用 systemd-resolved，应让 VPN 客户端只推送 DNS 条目，而不覆盖全局解析；或者使用分割 DNS（split-DNS），只有特定域名走 VPN 的 DNS。若无法调整推送，考虑在本机做 hosts 或本地 DNS 缓存来覆盖关键解析。
场景：防火墙规则冲突
在防火墙中为每个虚拟接口建立明确的链和接口匹配规则，避免通用规则无差别地应用于所有接口。对 NAT 规则使用按接口匹配而非通配，以免后启动的客户端修改了全局 NAT 行为。
场景：分片或 MTU 导致应用异常
为两个隧道设置合适的 MTU，并在遇到问题时调低 MTU 值以减少分片。还可以启用或调整 MSS clamping（即在防火墙层限制 TCP MSS）来避免路径 MTU 问题。
场景：IP 段重叠
最直接的解决是重新规划隧道内网段，确保两端没有重叠。如果短时间内无法更改，采用 NAT 在一端对冲突网段做地址转换，消除路由歧义。
两个实际案例：故障到恢复的路径
案例一：用户发现本地访问公司内网服务失败，打开 WireGuard 后原本正常的 OpenVPN 内网访问中断。诊断显示 WireGuard 推送了更广的路由前缀，把原本属于 OpenVPN 的内网网段误导向 WireGuard。修复步骤是调整 WireGuard 的 Allowed IPs，缩小其路由范围，或在系统路由表中为公司内网添加高优先级的路由条目。
案例二：同时启用两种 VPN 后网页解析速度下降且偶尔失败。排查发现两个客户端都推送了 DNS，且 systemd-resolved 优先使用后启动客户端提供的 DNS，但该 DNS 对外部域名解析不完整。解决方法是启用分割 DNS：只让公司域名走公司 VPN 的 DNS，其他查询走公共 DNS，同时禁用客户端对全局 /etc/resolv.conf 的覆盖。
防止未来问题的最佳实践
- 规划清晰的隧道用途：设定哪一个用于全局出口，哪一个仅做内网访问。
- 使用明确的路由策略或策略路由（policy-based routing），按源地址或进程分流。
- 在防火墙和 NAT 规则中按接口区分，避免模糊匹配。
- 为 DNS 制定统一策略：优先使用分割 DNS 或本地缓存，避免客户端互相覆盖。
- 对 MTU 和 MSS 做统一管理，防止分片问题影响体验。
- 记录网络拓扑与 IP 规划，避免不同隧道分配重叠网段。
结语风格的提示
同时运行 WireGuard 与 OpenVPN 本质上是管理多条逻辑路径的问题：把每条路径的职责、路由与解析清晰化，系统才能稳定工作。用诊断的步骤逐层排查，从接口、路由、DNS 到防火墙，通常可以快速找到并修复冲突。长期来看，策略路由、分割 DNS 与良好的规则组织是最可靠的防线。
暂无评论内容