☰

如何使用 conntrack 将来自未知 MAC 地址的传入 iptables 请求标记为 99

tag-icon • tag-icon iptables conntrack
如何使用 conntrack 将来自未知 MAC 地址的传入 iptables 请求标记为 99

我的 iptables 规则已经运行多年，没有发生任何事故，但在通过以下方式允许所有受信任的 MAC 访问后：

/sbin/iptables -A INPUT -m mac --mac-source $MAC -j ACCEPT
/sbin/iptables -A FORWARD -m mac --mac-source $MAC -j ACCEPT

我正在尝试标记其他 mac 地址，例如：

/sbin/iptables -A PREROUTING -t mangle -i $INT_DEV -p tcp --dport 80 -j MARK --set-mark 99

但是当我尝试读取该地址时，
conntrack -L | grep "src=10.1.1.234"
我没有在任何地方看到我的未知 10.1.1.234 freeloader...
但我想继续在 iptables 中通过以下方式将我的 freeloader 转移到登录页面

/sbin/iptables -t filter -A FORWARD -m mark --mark 99 -j DROP```  
And obviously it doesn't work because I can't even see it from my conntrack listing.  
What am I doing wrong here..?

答案1

有区别的是包马克，又名标记，防火墙标记或者福马克以及 conntrack 入口标记，又称ctmark，连接标记或者康马克：前者附在包的缓冲缓冲区，后者附加到连接跟踪条目. 存在明显iptables 垫-切斯和柏油-获取包括将标记从数据包传递到连接条目或者从连接条目到数据包。

这里不需要使用这个标记连接跟踪对于这种情况，它conntrack -L根本不是显示丢弃数据包的正确工具（请参阅最后一段）。当使用该iptables-nft变体时，为了调试目的查看标记数据包的最简单方法（否则只需使用-j LOG将在其日志中添加数据包的标记）是跟踪它们并使用它xtables-monitor --trace显示它们的命运（iptables-legacy会将其发送到内核日志，并且可能很容易淹没日志，此外它不能很好地与网络命名空间配合使用：这是 -legacy 和 -nft 变体之间罕见的不兼容变化）。

一个可能的例子：

iptables -A PREROUTING -t mangle -i $INT_DEV -p tcp --dport 80 -j MARK --set-mark 99
iptables -A PREROUTING -t mangle -m mark --mark 99 -j TRACE

[...]

iptables -A FORWARD -m mark --mark 99 -j DROP

现在可以非常详细地跟踪-j TRACE和之间的所有这些标记数据包的详细命运-j DROP（或加上对这些选定的少数数据包的所有进一步处理），如下所示：-j ACCEPT

xtables-monitor --trace

为了限制详细程度，可以通过改变规则TRACE来仅跟踪启动新流的数据包：

iptables -A PREROUTING -t mangle -m mark --mark 99 -m conntrack --ctstate NEW -j TRACE

此外：此类流的第一个数据包确实会触发创建连接跟踪条目（即使没有标记）通常在事件模式下可见conntrack -E -p tcp --dport 80。但是当这个数据包被丢弃时，临时的 conntrack 条目永远不会确认的并且事件永远不会提供给conntrack。虽然使用命令时它将不可见conntrack，但在被丢弃之前，它仍然在使用的规则中可见-m conntrack --ctproto tcp --ctorigdstport 80。任何进一步的重试都将再次成为第一个数据包，这将创建一个暂定条目，但由于数据包被丢弃等原因，该条目将无法确认。

因此conntrack只能用于显示第一个数据包未被丢弃的流，否则就没有可用的流。

相关内容