我的 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..?
数据包标记(又名 just mark、防火墙标记或fwmark)和 conntrack 条目标记(又名ctmark、连接标记或connmark )之间存在差异:前者附加到数据包的skbuff,后者附加到conntrack 条目。两者都有不同的iptables匹配和 目标,包括将标记从数据包传递到连接条目或从连接条目传递到数据包的方法。
在这种情况下,不需要将此标记与conntrack
conntrack -L
一起使用,并且它根本不是显示丢失数据包的正确工具(请参阅最后一段)。使用该iptables-nft
变体时,查看标记数据包以进行调试的最简单方法(否则仅使用-j LOG
会在其日志中添加数据包的标记)是跟踪它们并用于xtables-monitor --trace
显示它们的命运(iptables-legacy
会将其发送到内核日志,并且可能很容易淹没日志,此外它不能很好地与网络命名空间配合:这是 -legacy 和 -nft 变体之间罕见的不兼容更改)。一个可能的例子:
[...]
现在可以非常详细地跟踪
-j TRACE
和之间所有此类标记数据包的详细命运-j DROP
(或加上这些选定的少数数据包的所有进一步处理):-j ACCEPT
为了限制详细程度,可以通过更改
TRACE
规则来仅跟踪开始新流的数据包,如下所示:此外:此类流的第一个数据包确实会触发conntrack条目的创建,该条目(即使没有标记)通常在事件模式下使用 可见
conntrack -E -p tcp --dport 80
。但是,当此数据包被丢弃时,暂定的 conntrack 条目永远不会得到确认,并且该事件永远不会可供 使用conntrack
。虽然它在命令中不可见,但在删除之前conntrack
在规则中仍然可见。-m conntrack --ctproto tcp --ctorigdstport 80
任何进一步的重试都将再次成为第一个数据包,它将创建一个临时条目,由于数据包被丢弃等原因,该条目不会被确认。因此
conntrack
只能用于显示第一个数据包未被丢弃的流,否则没有可用的流。