剖析 WireGuard 路由：从 AllowedIPs 到内核转发的工作原理

• 从“AllowedIPs”到数据包在内核里如何被转发：一次深入剖析
• AllowedIPs 的双重身份：路由与访问控制
• 数据包的生命周期：从本机发起到远端解密（或反向）
• 关键内核要素：路由表、策略路由、conntrack 与 sysctl
• 常见问题与误区分析
• 场景分析：把 WireGuard 作为出口网关时会发生什么
• 调试思路与工具链（文字说明）
• 性能角度与未来方向

从“AllowedIPs”到数据包在内核里如何被转发：一次深入剖析

WireGuard 在设计上追求极简，但在路由与转发这一环节上，隐藏着不少细节：AllowedIPs 既是路由决定的依据，也是对等端流量选择的筛子；内核如何把数据包从物理网卡、通过隧道接口，再交给目标网络的流程也涉及多个子系统（路由表、策略路由、conntrack、NAT 等）。本文面向有一定网络与 Linux 基础的技术爱好者，逐步拆解 WireGuard 数据平面的走向与常见误区。

AllowedIPs 的双重身份：路由与访问控制

许多人把 AllowedIPs 理解为“Peer 能访问的目标网段”，这只是部分真相。更准确的说法是：

• 出站路由依据：当本机向某个目标地址发包时，内核会在路由表中查找下一跳。如果路由表没有更具体的项，而 WireGuard 安装了相应的路由条目（通常由用户空间工具如 wg-quick 或手动通过路由命令写入），这些路由会把目标指向 wg 接口，从而触发 WireGuard 的加密发送流程。AllowedIPs 在这一步决定哪些目的地址应该被“送到”某个 peer。
• 入站解密与对等端筛选：当 WireGuard 接收到一个加密数据包并解密后，会检查解密出的源地址是否属于某个 peer 的 AllowedIPs 列表。这是防止伪造隧道内网段来源的一道防线。

因此，AllowedIPs 实际上起到了“路由条目”和“源地址验证”的双重作用——拆开这两者，有助于理解为何有时候即便路由看似正确，流量仍被丢弃。

数据包的生命周期：从本机发起到远端解密（或反向）

把一条出站数据流的路径拆成关键阶段：

1. 本地应用发包：应用构造 IP 包并交给内核网络栈，内核先执行路由查找（可能涉及多个路由表和策略路由规则）。
2. 路由选择命中 WireGuard 路由：如果目标 IP 与某个 peer 的 AllowedIPs 匹配且相应路由指向 wg 接口，包被送给 WireGuard 网络接口的输出处理逻辑。
3. WireGuard 封装与发送：内核或内核模块（取决于实现）根据 peer 的密钥和端点信息对包进行加密、封装在 UDP 包里，并交给底层物理接口发出。
4. 远端接收并解密：远端主机接到 UDP 包，解密后得到原始 IP 包。内核再次进行路由决策：如果目标是远端本机，则交到本地；否则，可能继续转发到内网其他主机（前提是允许转发）。

注意：入站解密得到的包会重新进入目标主机的网络栈做路由决策而不是简单交付，这意味着目标地址是否是本机、路由表和 ip_forward 等设置会影响转发行为。

关键内核要素：路由表、策略路由、conntrack 与 sysctl

理解 WireGuard 在内核中的表现，需要把以下几个组件串起来：

• 路由表（route tables）：WireGuard 常通过添加针对 AllowedIPs 的路由条目（指向 wg 接口）来引导流量。如果多个 peer 的 AllowedIPs 重叠，最具体（最长前缀）优先，等具体度相同时则取决于路由优先级与添加顺序。
• 策略路由（policy routing）：在复杂场景中，基于源地址的策略路由会影响出站选择。例如，把来自某一子网发出的包强制走特定的出口。WireGuard 的隧道接口也会受到这些策略的影响。
• conntrack（连接跟踪）：对于 TCP/UDP 等有状态协议，连接跟踪会记录翻墙流量的 NAT 状态和方向。WireGuard 把封装的 UDP 当作新连接来处理，解密后原包的 conntrack 狀態可能会影响后续 NAT/防火墙处理。
• 内核转发开关（ip_forward）：当 WireGuard 运行在网关模式（接收并转发隧道内的流量到其它内部主机）时，必须开启相应的 ip_forward（ipv4/ipv6）。否则解密后的包即便路由存在也不会被转发。

常见问题与误区分析

理解这些工作原理之后，几个常见问题就容易定位了：

• “但是我的流量没走 WireGuard”：检查路由表是否存在指向 wg 的路由，尤其注意路由的具体度与优先级。很多时候 0.0.0.0/0 被其他更具体的规则覆盖。
• “开启 0.0.0.0/0 导致本地网络无法访问”：把默认路由替换成 wg 会导致本地局域网资源不可达，需要额外添加直连局域网子网的路由或策略来避免走隧道。
• 多个 peer 的 AllowedIPs 重叠：WireGuard 本身不会在应用层提示冲突，内核路由决定最终归属。重叠会导致不可预测的 peer 选择或路由抖动。
• 解密后包没有被转发到 LAN：确认 ip_forward 已启用，且防火墙规则允许 FORWARD 链的转发。conntrack 的状态也可能导致相关包被丢弃或被 NAT 处理异常。

场景分析：把 WireGuard 作为出口网关时会发生什么

假设一台 WireGuard 服务器对外有公网 IP，内部有多台主机通过隧道上网。关键点：

• 客户端的 AllowedIPs 通常包含它们要访问的目标（可能是 0.0.0.0/0），客户端本地会安装相应路由，把流量交给 wg 接口。
• 服务器端在解密后，若目的地址是远端互联网地址，则会把包路由到默认网关并可能做 SNAT（源地址转换），否则若目标在局域网且允许转发，则直接转发到内部网络。
• 若不做 NAT，服务器必须能够直接路由回客户端的子网并且对端路由配置正确；否则需要 SNAT 以便回程流量正确返回服务器。

调试思路与工具链（文字说明）

遇到问题时，可以按照以下顺序排查：

1. 查看 WireGuard 的 peer 配置与 AllowedIPs 是否如预期；确认端点 IP/端口与握手是否正常。
2. 检查内核路由表，验证目标地址是否被指向 wg 接口；如果使用策略路由，也要一并检查。
3. 确认 sysctl 中 ip_forward 是否开启（对于网关模式）；检查防火墙 FORWARD 链规则。
4. 利用抓包观察封装/解封装后的 UDP 流量，定位是封装未发出还是解密后被丢弃。
5. 检查 conntrack 状态与 NAT 规则是否影响流量走向。

性能角度与未来方向

WireGuard 的设计把加解密放进内核（或内核模块）以获得高性能，但这也意味着路由表与内核网络栈的行为会直接决定隧道流量的正确性与效率。随着多路径、多对等端部署的增多，如何优雅处理 AllowedIPs 重叠、实现基于策略的更细粒度控制、以及与容器/虚拟化网络联合工作，都会是未来需要关注的方向。

对技术爱好者而言，理解 AllowedIPs 不仅仅是配置一个网段那么简单，而是要把它放到内核路由、对等端验证、转发与 NAT 的整体流程里去看。掌握这些逻辑，能更从容地搭建、排错并优化 WireGuard 网络。