☰

通过 Wireguard 隧道转发客户端 IP 地址，而不是使用隧道 IP 进行伪装

tag-icon • tag-icon networking vpn iptables nat wireguard
通过 Wireguard 隧道转发客户端 IP 地址，而不是使用隧道 IP 进行伪装

我正在使用具有静态 IP 的 Debian VPS 为包括 Minecraft 服务器在内的一些自托管服务提供端口转发。我当前的安排是可行的，因为它允许玩家使用 VPS 的静态 IP 进行连接，但是从 Minecraft 服务器控制台的角度来看，所有玩家都不是来自各自的 WAN IP，而是来自 VPS 的wg0IP 172.31.0.1。这可以防止三名以上玩家同时参与（因为游戏限制为最多接受来自同一 IP 的三个同时连接），此外还限制了我们阻止已知麻烦制造者的能力（因为我只能通过用户名而不是 IP 地址进行禁止。）

我认为这只需要改变我的设置处理 NAT 的方式，因为即使是最差劲的消费级路由器也可以进行 NAT，而无需用自己的 LAN IP 替换客户端 WAN IP。因此，我的问题是：我必须做什么才能通过隧道传递客户端 IP，而不会消灭它们？

VPSip route输出：

default via {VPS Public Gateway} dev eth0 onlink {VPS Public Subnet}/24 dev eth0 proto kernel scope link src {VPS Public IP} 172.31.0.0/24 dev wg0 proto kernel scope link src 172.31.0.1

VPSiptables配置（由 Wireguard 使用 PostUp.sh 添加，并由相应的 PostDown.sh 删除）：

iptables -t nat -A PREROUTING -p tcp --dport 25565 -j DNAT --to-destination 172.31.0.2:25565 iptables -t nat -A PREROUTING -p udp --dport 25565 -j DNAT --to-destination 172.31.0.2:25565 iptables -t filter -A FORWARD -p tcp -d 172.31.0.2 -j ACCEPT iptables -t filter -A FORWARD -p udp -d 172.31.0.2 -j ACCEPT

VPS wg0.conf：

[Interface] PrivateKey = {Private key} ListenPort = 32016 Address = 172.31.0.1/24 PostUp = /etc/wireguard/PostUp.sh PostDown = /etc/wireguard/PostDown.sh [Peer] PublicKey = {Public key} AllowedIPs = 172.31.0.2/24

Minecraft 服务器ip route输出：

default via 172.24.0.1 dev eno1 onlink 172.24.0.0/24 dev eno1 proto kernel scope link src 172.24.0.2 172.31.0.0/24 dev wg0 proto kernel scope link src 172.31.0.2

我的世界服务器wg0.conf：

[Interface] PrivateKey = {Private key} Address = 172.31.0.2/24 Table = 1 PostUp = ip rule add pref 500 from 172.31.0.2 lookup 1 PostDown = ip rule del pref 500 [Peer] PublicKey = {Public key} AllowedIPs = 0.0.0.0/0 Endpoint = {VPS Public IP}:32016 PersistentKeepalive = 25

网络图

答案1

保留原始源 IP 地址始终是默认行为。如果它们被重写，这是因为您在某处（可能是在 VPS 上，也可能是在 Minecraft 服务器上）有明确SNAT或防火墙规则 - 找到并删除它。MASQUERADE

您很可能添加了该规则，以便 Minecraft 服务器能够理解它需要通过 wg0 进行响应，而不是遵循通过 eth0 进行的默认规则（即，使用 SNAT 时，它认为它正在响应 VPS）。但是 WireGuard 端点运行的是 Linux，因此您可以使用策略路由（您已经在客户端的 PostUp 中拥有该路由）来实现相同的目的，而无需使用 SNAT。

相关内容