- 当网络流量“跑偏”时，先别急着重启——理解冲突发生的根源
- 先厘清基础概念：路由表、表项优先级与策略路由
- 快速诊断流程：从现象到根因的三步法
- 常用的排查命令（文本描述形式）
- 几类常见冲突与对应思路
- 1. 默认路由被覆盖或重复定义
- 2. 同一目的网段存在多条路由（优先级冲突）
- 3. 策略路由规则与 WireGuard 的 mark 冲突
- 4. IPv4 与 IPv6 同时使用时的优先顺序问题
- 案例演示：一例典型故障与一步步修复
- 辅助工具与日志重点
- 防止问题的实用建议（配置层面）
- 最后一点思路：把诊断当成可重复的过程
当网络流量“跑偏”时，先别急着重启——理解冲突发生的根源
WireGuard 在性能和简洁性上表现出色，但在复杂的本地路由环境下，路由冲突并不少见。典型症状包括：通过 VPN 的流量部分通、某些 IP 无法访问、内网服务不可达，或是默认路由被意外覆盖。解决这类问题，关键在于先弄清楚“哪条路由生效、为什么生效”，再进行有针对性的修复。
先厘清基础概念：路由表、表项优先级与策略路由
把问题拆成更小的块会更容易：Linux（或 BSD）系统通过路由表决定流量走向，路由表由多条路由条目组成，每条条目基于目的网络、接口和优先级匹配最合适的路径。WireGuard 本身通过创建虚拟接口（如 wg0）并在该接口上添加路由来导流；但系统上可能已存在其他静态或动态路由（如 DHCP 接收的默认网关，或其他 VPN/容器网络），二者发生覆盖或冲突时就会出现问题。策略路由（policy routing）进一步基于源地址或 fwmark 做分流，也会让排查复杂度提升。
快速诊断流程：从现象到根因的三步法
排查路由冲突可以按三个层次推进：
- 观察层：确认哪些目的地不可达、哪些可以访问，是否与路由器/主机有关，是否与特定的接口绑定。
- 断言层：查看路由表、接口状态、策略路由规则，确认哪条条目正在匹配问题流量。
- 验证层：临时调整路由或禁用其他接口，观察问题是否消失，从而锁定冲突来源。
常用的排查命令（文本描述形式）
在终端里，你会用到查看路由表、接口和规则的命令，比如“查看主路由表（ip route show）”、“查看所有路由规则（ip rule show）”、“查看接口与地址（ip addr show 或 ip link show）”以及抓包工具来验证实际转发路径。抓包时可观察源/目的 MAC 与 IP，以及接收接口来判断流量是否被错误路由。
几类常见冲突与对应思路
1. 默认路由被覆盖或重复定义
场景：启动 WireGuard 后，系统的默认路由指向 wg0，导致本地局域网设备不可达或内网服务脱网。原因通常是配置里将 0.0.0.0/0 推到 peer（即“全量走 VPN”），但未结合策略路由或排除重要的局域网网段。
修复思路：在配置中明确列出需要经由 VPN 的目标网段（而非默认走全局），或在本地保留对 LAN 的静态路由（例如将本地网段强制通过物理网卡）。使用策略路由为局域网源 IP 指定本地出接口可以避免被覆盖。
2. 同一目的网段存在多条路由（优先级冲突）
场景：wg0 和 eth0 都有到同一个目的网段的路由，系统选择了非预期的那条。一般发生在手动或脚本添加静态路由时没有设置合适的度量（metric）或优先级。
修复思路：调整路由度量（metric），或删除多余的冲突路由。为关键服务添加更精细的路由（更具体的子网掩码）也能确保匹配优先级更高的条目被使用。
3. 策略路由规则与 WireGuard 的 mark 冲突
场景：系统中已有基于 fwmark 的策略路由（例如透明代理、容器网络）与 WireGuard 的路由规则互相干扰，导致特定来源或进程的流量被错误导出。
修复思路：明确分层策略，使用防火墙规则在流量进入内核路由决策前打上/清除相应的 mark，并在策略路由中为不同 mark 指定独立的路由表。确保 WireGuard 的入口/出口标记与现有策略兼容。
4. IPv4 与 IPv6 同时使用时的优先顺序问题
场景：系统优先使用 IPv6 路由而 WireGuard 只为 IPv4 设置了出口，导致一些目的地“看起来”不可达。或者相反，IPv6 的默认路由被 VPN 覆盖。
修复思路：分别检查 IPv4 和 IPv6 的路由表与规则，必要时为不同 IP 版本单独制定策略路由或在配置中排除某些前缀。
案例演示：一例典型故障与一步步修复
场景描述：一台开发机连接公司 VPN（wg0），同时接入办公室网络（eth0）。启动 WireGuard 后，无法访问 NAS（本地 192.168.10.0/24），但能访问互联网。
排查过程：
- 确认现象：ping NAS 超时，本地同网段的其他机器可达。
- 查看路由表：发现 192.168.10.0/24 的路由指向 wg0 而非 eth0。
- 验证修改：临时删除到该网段的 wg0 路由或添加到 eth0 的静态路由，测试后 NAS 恢复可达。
- 最终修复：在 WireGuard 配置中排除 192.168.10.0/24，或在系统启动脚本中添加优先静态路由，确保重启后生效。
辅助工具与日志重点
排查时，除了路由与接口信息，关注内核日志（dmesg 或 systemd-journal）以及 WireGuard 的握手/日志状态也很重要。抓包工具（tcpdump、wireshark）可以直观展示封包实际从哪个接口发出。对于复杂场景，可用网络命名空间或容器复现问题，避免在生产环境直接试验。
防止问题的实用建议（配置层面）
- 在配置里尽量使用精确的目的前缀而非 0.0.0.0/0，除非确实需要全量代理。
- 保留本地网络的静态路由，不要让 VPN 覆盖内网关键段。
- 在多 VPN/多网络环境下，统一管理路由度量并记录变更，避免冲突累积。
- 使用策略路由时保持标记与路由表的一致性，必要时文档化每个标记的用途。
最后一点思路：把诊断当成可重复的过程
每次排查都按“观察—断言—验证”的流程走一遍，并把关键命令与变更记录下来，可以在下次遇到类似问题时更快定位。WireGuard 的简洁并不意味着路由管理可以忽略；在多接口、多策略并存的场景下，清晰的路由规划比临时修补更可靠。
暂无评论内容