☰

Conntrack 获取了传出协议 41 的错误转发规则

tag-icon • tag-icon iptables nat 6to4 wrt54g
Conntrack 获取了传出协议 41 的错误转发规则

我正在尝试通过运行 Tomato 1.28 的 WRT54G 转发协议 41 (ipv6-in-ipv4) 以用于 HE 隧道。Tomato 1.28 运行的是 2.4 内核，它对协议 41 一无所知，只知道它名为“ipv6”。拥有 2.4 内核似乎也意味着不能禁用 conntrack：没有“原始”iptables 规则。

我可以设置规则，以便传入的数据包通过 DNAT 发送到正确的内部主机。如果远程主机先通过隧道发送某些内容，则一切正常。数据包可以通过适当的 NAT 双向通过隧道，我得到了/proc/net/ip_conntrack如下条目：

unknown 41 599 src=72.52.104.74 dst=67.180.229.14 src=10.1.0.3 dst=72.52.104.74 use=1 mark=0

该条目表明它适用于未知协议 41，如果没有收到更多流量，则超时时间为 599 秒，并且在发起端（即 WAN 端）有一对源地址和目标地址，在接收端（即 LAN 端）有另一对源地址和目标地址。

但是如果我的系统首先尝试通过隧道发送数据包，则源地址不会像应该的那样转换为路由器的地址，并且我会得到如下的 conntrack 条目：

unknown 41 589 src=10.1.0.3 dst=72.52.104.74 [UNREPLIED] src=72.52.104.74 dst=10.1.0.3 use=1 mark=0

只要我的机器继续尝试使用隧道，它就会使这个虚假的 conntrack 条目保持活动状态，并且我可以看到数据包离开我的路由器到达电缆调制解调器时仍然带有内部源地址，导致它们被丢弃并且永远无法到达它们要去的地方。

为了使我的隧道启动，我必须关闭我这边的隧道接口，使用 HE ping 工具来引导一些 IPv6 流量进入管道，并且，当正确的 conntrack 条目上的 10 分钟超时仍然有效时，再次启动我这边的隧道——然后确保它不会连续 10 分钟处于空闲状态。我能这样做，但这样做很愚蠢。

现在我的转发规则设置如下：

# Send incoming ipv6-in-ipv4 packets to the correct host
iptables -t nat -A PREROUTING -p 41 -s 72.52.104.74 -j DNAT --to 10.1.0.3

# Allow those packets through the firewall
iptables -I FORWARD -p 41 -d 10.1.0.3 -j ACCEPT

# Things I have added to try and solve my problem, which didn't work:

# Remove the default masquerade-everything rule
iptables -t nat -D POSTROUTING 10
# Masquerade only protocols other than 41. Conntrack still gets its bogus entries, 
# and if I get the correct entry in it still works.
iptables -t nat -A POSTROUTING -p ! 41 -j MASQUERADE

我也曾尝试设置这样的 SNAT 规则：

iptables -t nat -I POSTROUTING -p 41 -s 10.1.0.3 -j SNAT --to 67.180.229.14

但据我所知，这也无济于事。

我的问题是：

1) 有人成功通过运行 Tomato 的 WRT54G 转发协议 41 吗？如果是，您使用了哪些特殊的防火墙规则？

2)为什么路由器认为它不必对传出的协议 41 进行源地址转换？

答案1

怎么样

iptables -t nat -A PREROUTING -p 41 -s 72.52.104.74 -j DNAT --to 10.1.0.3
iptables -t nat -A POSTROUTING -j MASQUERADE

相关内容