我是一名家庭劳动者。我的 WireGuard VPN 已经正常运行了大约 16 个月。它在虚拟机内的 Ubuntu Server 安装上运行。虚拟机管理程序在 TrueNAS CORE 上运行。
自从我第一次设置 WireGuard 以来，我就遇到了客户端无法通过 VPN 连接到公共互联网的问题。但由于我设置 VPN 的主要目的只是为了能够远程管理我的服务器和访问网络上的设备，所以这不是一个大问题。我使用AllowedIPs客户端配置中的设置仅192.168.10.0/24通过 VPN 将流量路由到我的子网，并且发往公共互联网的流量不会触及 WireGuard。
最近我重新启动了我的 Ubuntu 虚拟机。当它重新上线时，我能够连接到 WireGuard VPN，并且通过 VPN，我可以连接到我的 Ubuntu VM (192.168.10.240) 上运行的任何服务。但是我无法连接到网络上的任何其他设备。
我curl在 Ubuntu VM 上使用，它仍然能够看到其他设备（例如 TrueNAS Core）。我还可以使用 SSH 隧道来访问这些其他设备。但我无法像平常那样通过 WireGuard 访问它们。
自上次重新启动 Ubuntu VM 以来，我唯一知道的变化是我在 Docker 中安装了 Pterodactyl Wings。这会添加一个 Docker Bridge 接口。 （子网 172.19.0.0/16，网关 172.19.0.1）但据我所知，这没有理由与 WireGuard 的网络冲突。
我真的不知道从哪里开始解决这个问题，我希望得到您的任何建议。
编辑：正如您在下面看到的，我使用 PostUp / PostDown 命令来确保 IP 表正确处理 MASQUERADE。我的 WireGuard 子网 ( 10.8.0.1/24) 与网络上的其他子网不冲突。我确实配置了多个对等点，并且每个对等点/32在此子网中都有一个唯一的。我的客户的AllowedIPs设置为将流量路由到192.168.10.0/24.
当我的客户端已连接时，我也能够10.8.0.2从服务器和客户端成功 ping 通。我还可以从另一个客户端 ping 一个客户端。
由于我可以连接到 192.168.10.240，这可能意味着 WireGuard 服务器正在提供从10.8.0.0/24到 的路由192.168.10.0/24。当流量需要物理离开该主机时，似乎会出现问题。那么问题可能出在我的 USG 路由器上（但在重新启动虚拟机时我没有更改任何内容）或者 Ubuntu 可能不接受来自 NIC 的相关流量？
我不知道如何解决这个问题。
编辑2：我将客户端设备物理连接到我的家庭实验室网络，它能够按预期访问所有服务器。但随后我激活了 WireGuard（同时仍保持物理连接），并且无法访问除 192.168.10.240 之外的所有服务器。因此，这表明 WireGuard 客户端肯定正在通过隧道将流量路由到这些地址。
我还尝试暂时使用非常简约的iptables配置（见下文），但这没有改变。
WireGuard 服务器配置：
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = [redacted]
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
PublicKey = [redacted]
AllowedIPs = 10.8.0.2/32
WireGuard 客户端配置：
[Interface]
PrivateKey = [redacted]
Address = 10.8.0.2/24
[Peer]
PublicKey = [redacted]
AllowedIPs = 10.8.0.1/24, 192.168.10.0/24
Endpoint = example.org:51820
网络详情：
- 子网192.168.10.0/24
- 网关 192.168.10.1（UniFi USG）
- DHCP 范围 192.168.10.100 - 192.168.10.199
相关主机：
- TrueNAS 服务器（物理）- 192.168.10.221
- QuickSync 服务器（物理）- 192.168.10.222
- TrueNAS 的 IPMI（物理）- 192.168.10.231
- Ubuntu VM 托管在 TrueNAS 服务器上 - 192.168.10.240（WireGuard 服务器！）
- QuickSync 服务器上的 Docker 容器 (macvlan) - 192.168.10.241
追踪：
C:\Users\test>tracert 192.168.10.221
Tracing route to 192.168.10.221
over a maximum of 30 hops:
1 * 25 ms 20 ms 10.8.0.1
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
Trace complete.
从服务器 Ping 到客户端
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
64 bytes from 10.8.0.2: icmp_seq=1 ttl=128 time=20.4 ms
64 bytes from 10.8.0.2: icmp_seq=2 ttl=128 time=27.0 ms
64 bytes from 10.8.0.2: icmp_seq=3 ttl=128 time=19.4 ms
64 bytes from 10.8.0.2: icmp_seq=4 ttl=128 time=27.1 ms
64 bytes from 10.8.0.2: icmp_seq=5 ttl=128 time=27.2 ms
^C
--- 10.8.0.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 19.409/24.223/27.209/3.536 ms
从客户端 Ping 到自身（在 VPN 上）
Pinging 10.8.0.2 with 32 bytes of data:
Reply from 10.8.0.2: bytes=32 time<1ms TTL=128
Reply from 10.8.0.2: bytes=32 time<1ms TTL=128
Ping statistics for 10.8.0.2:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
从客户端 Ping 到其他客户端
Pinging 10.8.0.2 with 32 bytes of data:
Reply from 10.8.0.2: bytes=32 time=64ms TTL=127
Reply from 10.8.0.2: bytes=32 time=41ms TTL=127
Reply from 10.8.0.2: bytes=32 time=39ms TTL=127
Ping statistics for 10.8.0.2:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 64ms, Average = 48ms
极简 iptables 配置
# Generated by iptables-save v1.8.7 on Sun Apr 14 14:57:35 2024
*filter
:INPUT DROP [0:0]
:FORWARD DROP [119314:15037722]
:OUTPUT ACCEPT [169491:32755967]
:DOCKER-USER - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j ACCEPT
-A FORWARD -j DOCKER-USER
-A FORWARD -i wg0 -j ACCEPT
-A FORWARD -o wg0 -j ACCEPT
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Sun Apr 14 14:57:35 2024
# Generated by iptables-save v1.8.7 on Sun Apr 14 14:57:35 2024
*nat
:PREROUTING ACCEPT [222:56161]
:INPUT ACCEPT [14:1327]
:OUTPUT ACCEPT [248:13567]
:POSTROUTING ACCEPT [256:16075]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Sun Apr 14 14:57:35 2024
答案1
可能是 WireGuard 服务器上的 LAN 接口名称发生了更改，或者您之前向转发到它的 NAT 连接添加了临时 iptables 规则，但该规则在服务器重新启动时丢失了。
在服务器上，伪装从 WireGuard 服务器到其 LAN 的 WireGuard 连接的一般模式是：
- 启用转发的内核参数（例如
sysctl net.ipv4.conf.all.forwarding=1）。 - 允许通过防火墙转发 WireGuard 连接（例如
iptables -A FORWARD -i wg0 -j ACCEPT反之亦然） - NAT 将那些转发到 LAN 的连接（例如
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE）
对于客户：
- 将 LAN 子网添加到其
AllowedIPs设置中。
您拥有所有这些东西 - 但您的 NAT 规则中的接口名称错误；eth0是第一个以太网接口的传统名称，但在许多 Linux 发行版上，它可能是有些不同。
在服务器上运行以检查可能出现问题的一组好命令是：
sudo wg
sudo cat /etc/wireguard/wg0.conf
sysctl net.ipv4.conf.all.forwarding
ip address
ip route
ip rule
sudo iptables-save
sudo nft list ruleset
如果一切都失败了，你也可以尝试运行tcpdump在每个主机上（像这样使用 Tcpdump 对 WireGuard 进行故障排除文章描述）尝试准确识别流量被丢弃的位置。