WireGuard星型（Hub&Spoke）架构下无法访问办公路由器及子网网关的故障排查求助

大家好，我之前一直是OpenVPN的忠实用户，最近出于安全性和性能考量，决定把所有VPN服务切换到WireGuard。

我的核心需求是能从外网访问办公室的私有局域网。因为办公路由器和外网客户端都处于防火墙之后，所以我采用了Hub&Spoke（星型）架构：Hub节点部署在一台带公网IP的Linux云VPS上，所有客户端都和Hub建立连接，再通过Hub实现互相通信——这个架构和我之前用OpenVPN时完全一致，当时一切正常。

目前的状态是：我把办公路由器（ASUS RT-AX92U，用VPN Fusion功能作为WireGuard客户端）接入VPN后，能正常看到其他VPN客户端，也能访问办公子网里的所有机器，但唯独没法直接连接到办公路由器本身：不管是ping它的VPN地址10.10.10.3，还是它的LAN网关地址192.168.51.1，都没有响应。路由器在办公内网里是可以正常访问的，而且OpenVPN下完全没有这个问题，实在搞不懂是防火墙的问题，还是WireGuard的配置哪里出错了。我搜过类似问题，试过别人的解决方案，但都没效果，肯定是有什么地方我没弄明白...

先把我的地址规划列出来：

• VPN地址段：10.10.10.0/24
• 办公LAN地址段：192.168.51.0/24
• 办公路由器LAN地址：192.168.51.1
• 办公路由器VPN地址：10.10.10.3
• WireGuard Hub地址：10.10.10.1
• 客户端A地址：10.10.10.4
• 客户端B地址：10.10.10.5

下面是各个节点的WireGuard配置文件：

Hub节点配置 #

[Interface]
Address = 10.10.10.1/32
ListenPort = 51820
PrivateKey = ************
PreUp = iptables -t mangle -A PREROUTING -i wg0 -j MARK --set-mark 0x30
PreUp = iptables -t nat -A POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE
PostDown = iptables -t mangle -D PREROUTING -i wg0 -j MARK --set-mark 0x30
PostDown = iptables -t nat -D POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE

[Peer]
PublicKey = ************
PresharedKey = ************
AllowedIPs = 10.10.10.3/32, 192.168.51.0/24

[Peer]
PublicKey = ************
PresharedKey = ************
AllowedIPs = 10.10.10.4/32

[Peer]
PublicKey = ************
PresharedKey = ************
AllowedIPs = 10.10.10.5/32

办公路由器配置 #

[Interface]
Address = 10.10.10.3/32
PrivateKey = ********

[Peer]
PublicKey = ********
PresharedKey = ********
AllowedIPs = 10.10.10.0/24
Endpoint = cloudIP:51820

客户端B配置（客户端A和这个完全一致） #

[Interface]
Address = 10.10.10.5/32
PrivateKey = ********

[Peer]
PublicKey = ********
PresharedKey = ********
AllowedIPs = 10.10.10.0/24, 192.168.51.0/24
Endpoint = cloudIP:51820

编辑1：进一步测试结果 #

经过@Robbie的分析，我重点排查了防火墙设置：按照他的建议修改了Hub的配置（移除MASQUERADE规则，添加IP转发配置，同时恢复系统级的ip-forward=0），但问题依旧。

我在客户端A上跑了tracert，同时在Hub上用tcpdump抓包，结果如下：

客户端A上的traceroute输出

C:\Users\inter> TRACERT.EXE 192.168.51.55

Tracing route to 192.168.51.55 over a maximum of 30 hops

1    23 ms    23 ms    23 ms  10.10.10.1
2     *        *        *     Request timed out.
3    42 ms    40 ms    40 ms  192.168.51.55

Trace complete.

Hub上的tcpdump输出

[root@remoto3 wireguard]# tcpdump -tttnei wg0
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
00:00:00.000000 ip: 10.10.10.4 > 192.168.51.55: ICMP echo request, id 1, seq 4540, length 72
00:00:00.000038 ip: 10.10.10.4 > 192.168.51.55: ICMP echo request, id 1, seq 4540, length 72
00:00:00.019062 ip: 192.168.51.55 > 10.10.10.4: ICMP echo reply, id 1, seq 4540, length 72
00:00:00.000023 ip: 192.168.51.55 > 10.10.10.4: ICMP echo reply, id 1, seq 4540, length 72
00:00:00.023966 ip: 10.10.10.4 > 192.168.51.55: ICMP echo request, id 1, seq 4541, length 72
00:00:00.000022 ip: 10.10.10.4 > 192.168.51.55: ICMP echo request, id 1, seq 4541, length 72
00:00:00.018760 ip: 192.168.51.55 > 10.10.10.4: ICMP echo reply, id 1, seq 4541, length 72
00:00:00.000021 ip: 192.168.51.55 > 10.10.10.4: ICMP echo reply, id 1, seq 4541, length 72
00:00:00.021823 ip: 10.10.10.4 > 192.168.51.55: ICMP echo request, id 1, seq 4542, length 72
00:00:00.000020 ip: 10.10.10.4 > 192.168.51.55: ICMP echo request, id 1, seq 4542, length 72
00:00:00.018592 ip: 192.168.51.55 > 10.10.10.4: ICMP echo reply, id 1, seq 4542, length 72
00:00:00.000021 ip: 192.168.51.55 > 10.10.10.4: ICMP echo reply, id 1, seq 4542, length 72
00:00:00.442107 ip: 10.10.10.4.netbios-ns > 192.168.51.55.netbios-ns: UDP, length 50
00:00:00.000135 ip: 10.10.10.1 > 10.10.10.4: ICMP host 192.168.51.55 unreachable - admin prohibited filter, length 86
00:00:01.503801 ip: 10.10.10.4.netbios-ns > 192.168.51.55.netbios-ns: UDP, length 50
00:00:00.000089 ip: 10.10.10.1 > 10.10.10.4: ICMP host 192.168.51.55 unreachable - admin prohibited filter, length 86
00:00:01.515731 ip: 10.10.10.4.netbios-ns > 192.168.51.55.netbios-ns: UDP, length 50
00:00:00.000121 ip: 10.10.10.1 > 10.10.10.4: ICMP host 192.168.51.55 unreachable - admin prohibited filter, length 86
00:10:07.780807 ip: 10.10.10.4 > 192.168.51.1: ICMP echo request, id 1, seq 4543, length 40
00:00:00.000106 ip: 10.10.10.4 > 192.168.51.1: ICMP echo request, id 1, seq 4543, length 40
00:00:04.668951 ip: 10.10.10.4 > 192.168.51.1: ICMP echo request, id 1, seq 4544, length 40
00:00:00.000044 ip: 10.10.10.4 > 192.168.51.1: ICMP echo request, id 1, seq 4544, length 40
00:00:42.525787 ip: 10.10.10.4 > 10.10.10.1: ICMP echo request, id 1, seq 4545, length 40
00:00:00.000148 ip: 10.10.10.1 > 10.10.10.4: ICMP echo reply, id 1, seq 4545, length 40
00:00:01.019225 ip: 10.10.10.4 > 10.10.10.1: ICMP echo request, id 1, seq 4546, length 40
00:00:00.000073 ip: 10.10.10.1 > 10.10.10.4: ICMP echo reply, id 1, seq 4546, length 40
00:00:14.268544 ip: 10.10.10.4 > 10.10.10.3: ICMP echo request, id 1, seq 4547, length 40
00:00:00.000170 ip: 10.10.10.4 > 10.10.10.3: ICMP echo request, id 1, seq 4547, length 40
00:00:04.684129 ip: 10.10.10.4 > 10.10.10.3: ICMP echo request, id 1, seq 4548, length 40
00:00:00.000040 ip: 10.10.10.4 > 10.10.10.3: ICMP echo request, id 1, seq 4548, length 40

从抓包结果看，确实有流量被过滤了——虽然办公子网的机器能正常响应，但路由器的两个地址都没任何回复。我怀疑是路由器的防火墙在搞鬼，虽然我已经尝试放宽规则了，但还是没效果...

编辑2：进一步验证结果 #

按照@Robbie在评论里建议的方法，我从VPN客户端上扫描了路由器的VPN地址10.10.10.3，结果如下：

[root@peer ~]$ nmap -Pn 10.10.10.3

Starting Nmap 7.92 ( https://nmap.org ) at 2023-12-11 09:00 CET
Nmap scan report for 10.10.10.3
Host is up.
All 1000 scanned ports on 10.10.10.3 are in ignored states.
Not shown: 1000 filtered tcp ports (no-response)

Nmap done: 1 IP address (1 host up) scanned in 201.47 seconds

现在可以确定WireGuard的配置是没问题的，问题肯定出在办公路由器的防火墙设置上，接下来我会重点排查路由器的防火墙规则。

备注：内容来源于stack exchange，提问作者LucaR