WireGuard 访问家庭局域网的回程路由排查

VPS：把家庭网段归属到 OpenWrt Peer#

VPS 的 /etc/wireguard/wg-nesoriel.conf 中，OpenWrt Peer 配置为：

1
[Peer]
2
# OpenWrt
3
PublicKey = <OPENWRT_PUBLIC_KEY>
4
AllowedIPs = 10.0.0.20/32, 192.168.3.0/24
5
Endpoint = <OPENWRT_ENDPOINT>:<PORT>

AllowedIPs 在服务端不仅是访问限制，还是 WireGuard 的 cryptokey routing 表：发往 192.168.3.0/24 的加密包会被交给 OpenWrt Peer。

仅改 Peer 的 AllowedIPs 还不够。服务端内核也需要有到家庭网段的路由：

1
ip route replace 192.168.3.0/24 dev wg-nesoriel

为了持久化，将其写进接口生命周期：

1
[Interface]
2
PostUp = ip route replace 192.168.3.0/24 dev wg-nesoriel; <原有 PostUp 命令>
3
PreDown = ip route del 192.168.3.0/24 dev wg-nesoriel 2>/dev/null || true; <原有 PreDown 命令>

如果只改运行态，重启 WireGuard 后路由会消失；这种“暂时好了”的网络配置通常会在最不合适的时间重新坏掉。

修改后可无中断同步 Peer 配置：

1
sudo wg syncconf wg-nesoriel <(sudo wg-quick strip wg-nesoriel)
2
ip route get 192.168.3.20

预期路由应走 wg-nesoriel：

1
192.168.3.20 dev wg-nesoriel src 10.0.0.1

远程 Fedora：将家庭网段送入隧道#

Fedora 的 /etc/wireguard/wg-nesoriel.conf 中，VPS Peer 需要包含家庭 LAN：

1
[Peer]
2
PublicKey = <VPS_PUBLIC_KEY>
3
AllowedIPs = 10.0.0.0/24, 192.168.3.0/24
4
Endpoint = <VPS_PUBLIC_IP>:51820
5
PersistentKeepalive = 21

应用后验证：

1
ip route get 192.168.3.20

预期：

1
192.168.3.20 dev wg-nesoriel src 10.0.0.3

OpenWrt：允许 VPN 转发到 LAN#

OpenWrt 中 wg_nesoriel 放在独立防火墙区域，至少需要：

1
wg_nesoriel → lan

实际 UCI 形态类似：

1
firewall.<wg-zone>.network='wg_nesoriel'
2
firewall.<forwarding>.src='wg_nesoriel'
3
firewall.<forwarding>.dest='lan'

这一步完成后，远程 Fedora 已可以 ping 通 OpenWrt 的 LAN 地址：

1
ping -c 4 192.168.3.20

但 PVE 和媒体服务器仍不通。

确认 OpenWrt 防火墙确实转发了请求#

查看 firewall4 的实际规则，wg_nesoriel zone 中已经存在：

1
forward_wg_nesoriel {
2
    jump accept_to_lan
3
}

VPS 上的 FORWARD 规则计数器也在增长，且抓包确认请求经过中继并被发往 OpenWrt：

1
10.0.0.3 > 192.168.3.16: ICMP echo request
2
10.0.0.3 > 192.168.3.30: ICMP echo request

这说明请求路径完整：

1
Fedora → VPS → OpenWrt → LAN 服务器

但抓不到返回的 ICMP echo reply。此时继续重复检查 WireGuard 握手没有意义，问题已缩小到 LAN 主机的回程。

找到不对称路由#

PVE 和媒体服务器所在的 192.168.3.0/24 网段，其默认网关是：

1
192.168.3.1

而转发请求的 OpenWrt 是：

1
192.168.3.20

当 PVE 收到：

1
源地址：10.0.0.3
2
目的地址：192.168.3.16

它需要回复 10.0.0.3。但本机没有 10.0.0.0/24 的静态路由，只会把回复交给默认网关 192.168.3.1。

192.168.3.1 又不知道 VPN 网段应经 192.168.3.20 返回，于是包离开了正确路径。

1
请求：10.0.0.3 → OpenWrt 192.168.3.20 → 192.168.3.16
2
回复：192.168.3.16 → 默认网关 192.168.3.1 → 丢失

这解释了为什么 OpenWrt 自己可达：发往它本机的流量不需要经过 LAN 设备的默认路由；而任何由它转发到 LAN 的流量都依赖目标设备的回程路径。

方案一：在家庭主网关添加静态路由#

这是最干净的三层路由方案。在 192.168.3.1 上增加：

1
目标网段：10.0.0.0/24
2
下一跳：192.168.3.20

这样 LAN 设备发送给 10.0.0.0/24 的流量会正确回到 OpenWrt，再转入 WireGuard。

优点：

• LAN 服务器能看到真实的远程客户端地址，例如 10.0.0.3；
• 可基于真实源 IP 做审计与 ACL；
• 不需要 NAT。

缺点是需要控制并修改家庭主网关 192.168.3.1。若它是光猫、上级路由器或不便维护的设备，这个方案不一定可用。

方案二：OpenWrt 对 VPN → LAN 做精确 SNAT#

当前环境选择此方案。OpenWrt 在向 LAN 发送 VPN 客户端流量时，将源地址改为自己的 LAN 地址 192.168.3.20：

1
原始请求：10.0.0.3 → 192.168.3.16
2
SNAT 后：192.168.3.20 → 192.168.3.16

LAN 服务器回复 192.168.3.20 时，路由不再依赖上级网关，回复会直接回到 OpenWrt。连接跟踪再将回复还原并交还给 10.0.0.3。

为什么不能只给 WireGuard zone 开启 Masquerade#

这是本次实际踩到的一个细节。

在 OpenWrt firewall4 中，为 wg_nesoriel zone 设置：

1
option masq '1'

会生成与**流量离开 wg_nesoriel**方向有关的 NAT 行为；它不能表达“流量从 wg_nesoriel 进入、从 br-lan 离开时 SNAT”这个需求。直接使用 zone NAT 没有解决问题。

某些 UCI config nat 写法也无法使用 dest zone 指定此类定向 SNAT。因此使用一个加载在 firewall4 inet fw4 表上下文的 nftables 自定义链，表达式最明确，范围也最小。