☰

Iptables MASQUARADE 似乎在互联网上返回“结果”，而不是要求严格的接口

tag-icon • tag-icon ubuntu iptables firewall wireguard
Iptables MASQUARADE 似乎在互联网上返回“结果”，而不是要求严格的接口

我正在尝试从 WireGuard 接口和互联网进行 iptables 伪装。它曾经可以工作，但最近，我确实添加了一些（仅四个）WireGuard 接口，并且它对所有接口都停止工作。更让我困惑的是，直接连接到服务器（使用 WireGuard）的公路战士仍然表现良好。

由于某种原因，NATing 代码似乎将“后处理 UNNATED ANSWER”返回到 Internet 接口（称为 eth0）而不是 wg72。 （注意：服务器地址用 127.127.127.127 屏蔽）

13:22:26.212282 IP 74.125.5.8.443 > **127.127.127.127.55576**: Flags [S.], seq 4023527294, ack 2220950656, win 65535, options [mss 1408,sackOK,TS val 808558239 ecr 648649,nop,wscale 8], length 0
13:22:26.212299 IP 74.125.5.8.443 > **192.168.61.150.55576**: Flags [S.], seq 4023527294, ack 2220950656, win 65535, options [mss 1408,sackOK,TS val 808558239 ecr 648649,nop,wscale 8], length 0
13:22:26.218685 IP 74.125.5.8.443 > 127.127.127.127.55575: Flags [S.], seq 1487311994, ack 816352590, win 65535, options [mss 1408,sackOK,TS val 808558245 ecr 648649,nop,wscale 8], length 0
13:22:26.218699 IP 74.125.5.8.443 > 192.168.61.150.55575: Flags [S.], seq 1487311994, ack 816352590, win 65535, options [mss 1408,sackOK,TS val 808558245 ecr 648649,nop,wscale 8], length 0

我认为这是 WireGuard 配置，其中包含所有相关的防火墙规则。

[Interface]
Address = 10.255.16.74/30
Table = off
SaveConfig = true
PostUp = iptables -A FORWARD -i eth0 -o wg72 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
PostUp = iptables -A FORWARD -i eth0 -o wg72 -m conntrack --ctstate INVALID -j ACCEPT
PostUp = iptables -A FORWARD -i wg72 -o eth0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1350
PostUp = iptables -A FORWARD -i wg72 -o eth0  -j ACCEPT
PostUp = iptables -t nat -I POSTROUTING 1 -s 192.168.61.0/24 -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = iptables -D FORWARD -i eth0 -o wg72 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
PreDown = iptables -D FORWARD -i wg72 -o eth0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1350
PreDown = iptables -D FORWARD -i wg72 -o eth0  -j ACCEPT
PreDown = iptables -t nat -D POSTROUTING  -s 192.168.61.0/24 -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 12072
PrivateKey = MAYBEMAYBENOT

[Peer]
PublicKey = BLAHBLAHBLAH
AllowedIPs = 0.0.0.0/0
Endpoint = x.x.x.x:18445

在这里，尝试使用这些规则的统计结果 - 我看到它没有使用特定的“相关，已建立”，因为主机的通用规则已经处理了它。我尝试了规则的许多变化，但结果总是相同的。

0     0 ACCEPT     all  --  eth0   wg72    0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
0     0 ACCEPT     all  --  eth0   wg72    0.0.0.0/0            0.0.0.0/0            ctstate INVALID
 1953  117K TCPMSS     tcp  --  wg72   eth0    0.0.0.0/0            0.0.0.0/0            tcp flags:0x06/0x02 TCPMSS set 1350
 4334  529K ACCEPT     all  --  wg72   eth0    0.0.0.0/0            0.0.0.0/0           
 6148  925K ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

这是 NAT 表：

 Chain POSTROUTING (policy ACCEPT 440 packets, 52566 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2128  208K MASQUERADE  all  --  *      eth0    192.168.61.0/24      0.0.0.0/0

这是一个摘要网络图。

在此输入图像描述

系统我相信 VPS 在 QENU/KVM 下运行）

uname -a：Linux xyz 4.15.0-213-generic #224-Ubuntu SMP 星期一 6 月 19 日 13:30:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

iptables版本：iptables v1.6.1

答案1

发现问题：

-- 升级了内核4.15.0-213-generic。确实解决了 Wireguard 的一些不稳定问题，但更重要的是，开始抱怨偶尔的火星类型路由

-- 在寻找外星人的路上，我确实从 iptables 转换为 nft。更容易调试并且以防万一。

-- 最后，罪魁祸首很可能是由于两个区域使用相同的子网而导致的 OSPF 路由振荡。

相关内容