☰

仅当从该对等体 ping 后才能到达 VPN 对等体

tag-icon • tag-icon linux networking vpn ping wireguard
仅当从该对等体 ping 后才能到达 VPN 对等体

问题

我有两台 Linux PC 连接到本地网络和 WireGuard VPN 网络。（假设 VPN 子网 = 10.66.66.0/24 且 PC A=10.66.66.9 和 PC B=10.66.66.10）。

问题是我无法通过 VPN 从 A ping 和 ssh 到 B，但如果我事先从 B ping VPN 子网中的任何 IP（即使不存在）或者在 A 尝试 ping/ssh B 时，它就可以工作。

本地 A 到 B 以及 B 到 A 的 ping/ssh 工作正常，并且其他 VPN 对等体始终可以访问 A。

因此问题仅出在 VPN 网络中的 B PC 上。

配置

WireGuard 服务器配置：

[Interface]
Address = 10.66.66.1/24,fd42:42:42::1/64
ListenPort = 60207
PrivateKey = privatekey
PostUp = iptables -I INPUT -p udp --dport 60207 -j ACCEPT
PostUp = iptables -I FORWARD -i eth0 -o wg0 -j ACCEPT
PostUp = iptables -I FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -I FORWARD -i wg0 -j ACCEPT
PostUp = ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D INPUT -p udp --dport 60207 -j ACCEPT
PostDown = iptables -D FORWARD -i eth0 -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PostDown = ip6tables -D FORWARD -i wg0 -j ACCEPT
PostDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

### Client
[Peer]
PublicKey = pubkey
PresharedKey = preshardkey
AllowedIPs = 10.66.66.9/32,fd42:42:42::9/128

### Client
[Peer]
PublicKey = pubkey
PresharedKey = preshardkey
AllowedIPs = 10.66.66.10/32,fd42:42:42::10/128

### Client
...

配置：

[Interface]
PrivateKey = privatekey
Address = 10.66.66.9/32,fd42:42:42::9/128

[Peer]
PublicKey = pubkey
PresharedKey = preshardkey
Endpoint = endpoint:60207
AllowedIPs = 0.0.0.0/0,::/0

B配置：

[Interface]
PrivateKey = privatekey
Address = 10.66.66.10/32,fd42:42:42::10/128

[Peer]
PublicKey = pubkey
PresharedKey = preshardkey
Endpoint = endpoint:60207
AllowedIPs = 10.66.66.0/24,fd42:42:42::0/112

问题示例

1.通过VPN从A ping到B

A:~ $ ping 10.66.66.10
PING 10.66.66.10 (10.66.66.10) 56(84) bytes of data.

（无更多输出）

2. 从 B ping 不存在的 VPN 子网 IP（或 A），而 A 到 B 的 ping 正常

B:~ $ ping 10.66.66.5
PING 10.66.66.5 (10.66.66.5) 56(84) bytes of data.
From 10.66.66.1 icmp_seq=1 Destination Host Unreachable
From 10.66.66.1 icmp_seq=2 Destination Host Unreachable
From 10.66.66.1 icmp_seq=3 Destination Host Unreachable
From 10.66.66.1 icmp_seq=4 Destination Host Unreachable
...

3. 完成上一步后突然出现大量 A 到 B 的 ping 输出

A:~ $ ping 10.66.66.10                                                                                                             (12-09 15:40)
PING 10.66.66.10 (10.66.66.10) 56(84) bytes of data.
64 bytes from 10.66.66.10: icmp_seq=1 ttl=63 time=26756 ms
64 bytes from 10.66.66.10: icmp_seq=8 ttl=63 time=19592 ms
64 bytes from 10.66.66.10: icmp_seq=9 ttl=63 time=18568 ms
64 bytes from 10.66.66.10: icmp_seq=7 ttl=63 time=20615 ms
64 bytes from 10.66.66.10: icmp_seq=10 ttl=63 time=17544 ms
64 bytes from 10.66.66.10: icmp_seq=11 ttl=63 time=16520 ms
64 bytes from 10.66.66.10: icmp_seq=12 ttl=63 time=15496 ms
64 bytes from 10.66.66.10: icmp_seq=13 ttl=63 time=14472 ms
64 bytes from 10.66.66.10: icmp_seq=14 ttl=63 time=13448 ms
64 bytes from 10.66.66.10: icmp_seq=15 ttl=63 time=12424 ms
64 bytes from 10.66.66.10: icmp_seq=16 ttl=63 time=11400 ms
64 bytes from 10.66.66.10: icmp_seq=18 ttl=63 time=9352 ms
64 bytes from 10.66.66.10: icmp_seq=17 ttl=63 time=10376 ms
64 bytes from 10.66.66.10: icmp_seq=19 ttl=63 time=8328 ms
64 bytes from 10.66.66.10: icmp_seq=20 ttl=63 time=7304 ms
64 bytes from 10.66.66.10: icmp_seq=21 ttl=63 time=6279 ms
64 bytes from 10.66.66.10: icmp_seq=22 ttl=63 time=5256 ms
64 bytes from 10.66.66.10: icmp_seq=23 ttl=63 time=4232 ms
64 bytes from 10.66.66.10: icmp_seq=24 ttl=63 time=3208 ms
64 bytes from 10.66.66.10: icmp_seq=25 ttl=63 time=2185 ms
64 bytes from 10.66.66.10: icmp_seq=26 ttl=63 time=1160 ms
64 bytes from 10.66.66.10: icmp_seq=27 ttl=63 time=137 ms
64 bytes from 10.66.66.10: icmp_seq=28 ttl=63 time=94.4 ms
64 bytes from 10.66.66.10: icmp_seq=29 ttl=63 time=94.6 ms

现在我可以从 A ping 和 ssh 到 B 一段时间了。

答案1

有两种可能的解释：

  1. B 的防火墙未配置为允许传入的 WireGuard UDP 数据包通过。当“服务器”向 B 发送数据包时，它会被拒绝，因为无法识别。

    一旦 B 尝试在 VPN 中 ping 某个东西并发送传出的 WireGuard 数据包，其防火墙就会开始接受传入数据包，因为它识别出它们是属于活动流的“回复”数据包。如果该流空闲几分钟，防火墙就会忘记它并再次开始拒绝传入数据包。

  2. B 位于 NAT 后面，并且 B 处的 NAT 网关未配置为将传入的 WireGuard UDP 数据包转发到 B 的私有地址。

    解释与防火墙大致相同——第一个出站数据包创建 NAT 状态并允许回复通过。

解决所有问题的一个简单方法是PersistentKeepalive=在 B 上启用其“服务器”的 [Peer] 配置。这将使 B 定期向“服务器”发送数据包，以便它始终知道最新的端点地址和路径上的所有防火墙和 NAT 网关都会持续跟踪 UDP 数据包流。

（通常 UDP 流超时在 30 到 120 秒之间，因此请尝试将保持活动间隔设置为 100 秒；如果这还不够，请设置为 20 秒。）

如果 B 的位置是静态的，另一种解决方案是手动定义所有必要的配置 - 在其 [接口] 配置中手动设置本地端口；允许 UDP 数据包通过其防火墙到达该端口；如有必要，创建“端口转发”规则；并在“服务器”上为 B 设置静态端点。

相关内容