nftables可基于mac地址做准入控制，但仅在流量处于同一二层广播域、经过ingress/input/forward链且原始mac未被替换时有效；标准写法为ether saddr，支持与ip、端口及arp联动，并推荐用set构建白名单集配合兜底drop规则。
nftables 可以基于 MAC 地址做准入控制，但和 iptables 类似，它只在特定网络路径下有效——不是“绑定硬件”，而是匹配数据帧到达本机 netfilter 时的源 MAC 地址。真正起作用的前提是：流量必须经过 bridge 或 inet 家族中支持以太网头部解析的链，且原始 MAC 尚未被中间设备替换。
适用场景与硬性前提
只有满足以下全部条件，MAC 匹配才可靠生效：
- 客户端与目标主机处于同一二层广播域（同 VLAN、无三层路由/NAT 设备介入）
- 流量路径经过 nftables 的 ingress、input 或 forward 链，且使用
ether saddr表达式 - 内核启用
CONFIG_NF_TABLES_BRIDGE（桥接支持）或运行在物理/直连接口上（非虚拟网卡、非 Docker 默认桥） - 未启用 VLAN 重排序（
reorder_hdr on会剥离 VLAN 标签，影响 ether 表达式；如需 VLAN 支持，需设为off）
nftables 中匹配源 MAC 的标准写法
不同于 iptables 的 -m mac 模块，nftables 原生支持以太网层字段，语法更直接：
- 拒绝某 MAC 访问本机所有服务：
nft add rule inet filter input ether saddr 00:11:22:33:44:55 counter drop - 仅允许该 MAC 访问 SSH：
nft add rule inet filter input ether saddr 00:11:22:33:44:55 tcp dport 22 accept - 在桥接模式下（如 OpenWrt 软路由），用 bridge 家族更精准：
nft add table bridge filternft add chain bridge filter forward { type filter hook forward priority 0 \; }nft add rule bridge filter forward ether saddr 00:11:22:33:44:55 counter accept
注意：ether saddr 是唯一可用的 MAC 匹配方式，不支持目的 MAC（ether daddr 在部分内核版本中可用，但语义不稳定，不建议用于准入逻辑）。
比 iptables 更强的协同能力
nftables 天然支持多协议统一管理，可将 MAC 控制与 IP、端口、甚至 ARP 字段联动：
- 防 ARP 欺骗：结合
arp表达式校验 IP-MAC 对应关系nft add rule arp filter input arp saddr ip 192.168.1.100 @mac_whitelist counter accept - 构建白名单集（推荐）：
nft add set inet filter mac_whitelist { type ether_addr \; }nft add element inet filter mac_whitelist { 00:11:22:33:44:55, aa:bb:cc:dd:ee:ff }nft add rule inet filter input ether saddr @mac_whitelist accept - 自动兜底拒绝：
nft add rule inet filter input counter drop（放在白名单规则之后）
为什么不能叫“硬件绑定”？关键误区提醒
所谓“MAC 绑定”不是固化到网卡或驱动层，而是对流经本机协议栈的数据帧做一次快照比对。一旦流量经过以下任一环节，原始终端 MAC 就不可见：
- 家用路由器/NAT 网关（你看到的是网关 MAC）
- Docker 默认桥接（
docker0）、KVMvirbr0、OVS 桥（除非显式配置 hairpin 模式） - 云平台虚拟网卡（AWS ENA、Azure Accelerated Networking）
- IPv6 NDP 邻居发现劫持（此时 MAC 已被伪造，需配合 RA Guard）
若需覆盖全链路二层准入，应分层部署：ebtables 做桥接层初筛 → nftables 做协议层细控 → 802.1X 或动态 VLAN 分配做接入层认证。
