nftables 中的“iifname”和“iif”有什么区别？

iif查找并比较接收到的数据包的接口索引，同时iifname与接口名称进行字符串比较。两者都有优点和缺点。

使用更少的资源也是如此iif，因为接口索引是一个简单的数字，已经存储在穿过网络堆栈和 nftables 的数据包中，因此可以立即用于比较。但它的缺点是，如果接口被删除（并且很可能重新创建，但使用更新的索引值），则 nftables 中的相应规则将不再匹配。唯一保证的接口索引始终是回环接口（lo默认命名）：它始终是在命名空间中创建的第一个并且不能删除（也不能第二次添加），因此它的索引值始终为1.

iifname另一方面，就像 iptables'--in-interface与当前接口的名称进行字符串比较。这使用了更多资源，但允许预先为不存在的接口创建规则，并使用确定的名称，这iif并不容易。iifname还可以进行通配符匹配，例如 in iifname "ppp*"，这iif在经常创建和删除接口时不能做到并且可以很方便，但要保持命名约定（例如以pppPPP 链接开头）。

示例（使用 nftables 0.9.2）：

$ unshare -r -n
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
# nft add table ip filter
# nft add chain ip filter input '{ type filter hook input priority 0; policy accept; }'
# nft add rule ip filter input iif lo counter
# nft add rule ip filter input iif dummy0 counter
Error: Interface does not exist
add rule ip filter input iif dummy0 counter
                             ^^^^^^
# nft add rule ip filter input iifname dummy0 counter
# ip link add name dummy0 type dummy
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 4a:09:68:3a:34:91 brd ff:ff:ff:ff:ff:ff
# nft add rule ip filter input iif dummy0 counter
# nft list ruleset
table ip filter {
    chain input {
        type filter hook input priority filter; policy accept;
        iif "lo" counter packets 0 bytes 0
        iifname "dummy0" counter packets 0 bytes 0
        iif "dummy0" counter packets 0 bytes 0
    }
}
# ip link delete dev dummy0
# nft list ruleset
table ip filter {
    chain input {
        type filter hook input priority filter; policy accept;
        iif "lo" counter packets 0 bytes 0
        iifname "dummy0" counter packets 0 bytes 0
        iif 2 counter packets 0 bytes 0
    }
}

界面消失了，而是显示其索引值。同样，在添加规则时，甚至可以提前使用索引值：

# nft add rule ip filter input iif 3 counter
# nft list ruleset
table ip filter {
    chain input {
        type filter hook input priority filter; policy accept;
        iif "lo" counter packets 0 bytes 0
        iifname "dummy0" counter packets 0 bytes 0
        iif 2 counter packets 0 bytes 0
        iif 3 counter packets 0 bytes 0
    }
}
# ip link add name dummy4 type dummy
# ip link add name dummy0 type dummy
# nft list ruleset
table ip filter {
    chain input {
        type filter hook input priority filter; policy accept;
        iif "lo" counter packets 0 bytes 0
        iifname "dummy0" counter packets 0 bytes 0
        iif 2 counter packets 0 bytes 0
        iif "dummy4" counter packets 0 bytes 0
    }
}

因为接口索引值不会在命名空间内回收而只会增加，所以关于索引 2 的规则是“丢失”的（它再也没有机会匹配了）。下一个创建的接口dummy4被分配了索引 3，现在解析为dummy4规则集中。dummy0 收到索引值 4，在任何iif规则中都没有引用，但仍会与iifname规则匹配。

推荐什么？

我的建议：

在应用规则之前，您应该使用iif一旦创建就不会更改的“稳定”接口，例如启动时可用的物理以太网接口（如果使用较新的物理接口稳定命名约定，如果枚举顺序更改，则不会更改） ，当然还有lo接口。它没有在示例中显示，但您仍然可以匹配接口列表iif，例如iif { lo, dummy4 }. 所以你仍然可以让一个iif语句匹配多个接口。

您应该使用iifname在启动时（和创建规则时）未知但预计稍后会出现的动态接口，或者在使用通配符匹配时将一组接口与命名约定匹配。

不是很清楚，要优化而不是使用通配符，您可以为每个新创建的接口分配一个组（例如使用ip link set dev interface group 99），然后使用iifgroup而不是iifname+ 通配符匹配接口组。但这需要一些额外的机制来对新创建的接口进行分组标记。

您还可以使用接口命名集，从而保持通用规则使用iif和iifname更改命名集的内容，而不是规则本身。请注意，之前的 wiki 链接没有说明如何在集合中使用接口，但它根本不是最新的。有关此问题的 UL SE 回答中的更多信息：How do I create a named set of strings in nftables (for interface names)? .

这不是答案，只是对先前答案的评论。（我的坏名声不允许我发表评论。）

但这需要一些额外的机制来对新创建的接口进行分组标记。

我systemd-networkd经常这样做^^^。它有一个[Link]部分，您可以在其中设置每个接口的接口组。（这是[Link]从.network文件中读取的部分systemd-networkd，而不是从文件中[Link]读取的部分。）.linksystemd-udevd

所以我会在/etc/systemd/network/something.network…中设置这样的东西

[Match]
MACAddress=my:in:te:rf:ac:e0
...

[Link]
Group=99
...

…然后ip link show group 99可用于检查接口是否（确实）正确标记。（那些没有组的人在组中0。）（也ip link show打印组号。）

这使得使用iifgroup和oifgroup在nftables.conf.