nftables 不支持 MAC 地址匹配，因其内核框架已剥离链路层处理，标准表无法访问以太网帧头；iptables 的 MAC 匹配也仅限直连二层场景，易受拓扑、NAT、虚拟化及 MAC 伪造影响，不可靠。
不能在 nftables 中实现真正可靠的基于 MAC 地址的局域网准入控制。
MAC 匹配在 nftables 中根本不可用
nftables 内核框架不提供任何匹配 MAC 地址的表达式模块。与 iptables 不同，nftables 没有类似 -m mac --mac-source 的功能。其核心设计将链路层（L2）处理剥离到更底层（如 netdev 表或驱动），而标准 inet、ip、bridge 表均无法访问原始以太网帧头中的源/目的 MAC 字段。
这意味着：无论你使用 ip、inet 还是 bridge 地址簇，都无法编写类似 “只允许 MAC 为 aa:bb:cc:dd:ee:ff 的设备访问 SSH” 的规则。
为什么 iptables 的 MAC 匹配本身就不适合“准入控制”
即使退回到 iptables，所谓“MAC 白名单”也仅在极窄场景下技术可行，且完全违背“无感准入”的目标：
- 必须客户端与服务器处于同一二层广播域（无路由器、无 VLAN 间路由、无桥接虚拟网卡）
- 流量必须进入 INPUT 链早期（即未被网络栈剥离 MAC 头），而现代 Linux 对本地交付包的路径已高度优化，实际行为不稳定
- 所有跨网段、NAT、Docker/KVM 桥接、云平台 VPC 等常见环境，原始 MAC 在到达防火墙规则前已被替换或丢弃
- MAC 地址极易伪造，攻击者只需执行
ip link set dev eth0 address xx:xx:xx:xx:xx:xx即可绕过 - 用户设备更换网卡、启用 WiFi 热点、使用 USB 网卡等正常操作都会导致 MAC 变更，引发“准入失败”而非“无感”
真正可行的局域网准入替代方案
若目标是“设备级可信接入+无感体验”，应放弃 MAC 绑定，转向协议层或管理层面的机制：
- 802.1X + RADIUS：企业级标准，交换机端口级认证，支持证书/EAP-TLS，设备首次接入需凭证，后续自动完成，对用户透明
- DHCP Option 82 + IP/MAC 绑定表：由 DHCP 服务器记录首次合法租约的 IP+MAC，配合交换机端口绑定或 ARP 检查，比纯防火墙更靠近接入点
-
防火墙结合动态主机标识：例如通过 mDNS（
.local）、LLMNR 或自建轻量注册服务，让设备启动时上报唯一 ID（如 UUID、设备指纹），防火墙规则根据该 ID 关联 IP 动态放行 - 零信任网络访问（ZTNA）轻量模型：部署一个最小化 authz 代理（如 WireGuard + userspace auth），设备首次连接需短时交互认证，成功后下发短期有效策略，nftables 仅按授权会话 ID 或 IP+端口组合过滤
如果你仍想用 nftables 做基础层防护
可以构建一个安全基线，但请明确它不等于“MAC 准入”：
- 用
inet filter表默认 drop，仅开放必要服务（SSH、HTTP）并限制源 IP 段 - 启用连接跟踪：
ct state established,related accept，保障回程流量 - 对关键服务加连接速率限制，防暴力探测：
limit rate 5/minute burst 10 - 结合
ipset管理可信 IP 列表（来自 DHCP 日志或 CMDB），定期更新并 reload 规则
这类配置真实、可维护、符合现代网络架构，且不会因 MAC 伪造或拓扑变化而失效。
