nftables的PREROUTING链无法处理非本机MAC包，因网卡硬件在非混杂模式下已过滤掉目的MAC不匹配的帧，这些帧根本不会上送至内核协议栈；混杂模式虽可接收，但内核链路层仍会丢弃非目标帧，且PREROUTING位于IP层入口，无MAC信息可用。
不能在 nftables 的 prerouting 链直接丢弃“目标 MAC 与本地网卡不符的混杂模式嗅探包”——这个需求本身存在原理性误解，nftables（以及整个 Netfilter 架构）根本收不到这类包，也无从匹配或丢弃。
为什么 prerouting 链看不到“非本机 MAC”的包
网卡硬件层在非混杂模式下，会自动过滤掉目的 MAC 不是本机地址、广播地址（ff:ff:ff:ff:ff:ff）或多播地址的帧。这些帧根本不会被提交给内核协议栈，更不会到达 NF_INET_PRE_ROUTING 钩子点。nftables 运行在内核协议栈中，它处理的是已经通过硬件过滤、成功上送的数据包。
混杂模式只是让网卡把“不该收”的帧也交给内核——但这不等于内核会把它们当作合法网络层数据包来处理。现代 Linux 内核对非目标 MAC 的以太网帧，在链路层就直接丢弃（不交付给 IP 栈），不会走到 prerouting 阶段。
nftables 无法基于目的 MAC 做 prerouting 过滤
nftables 的 ether 表虽支持匹配 dst mac，但仅适用于 output 和 ingress 钩子（后者需启用 clsact qdisc），不适用于 prerouting。prerouting 是 IPv4/IPv6 协议栈入口，此时帧头已被剥离，MAC 层信息不可见（除非用 ingress + tc + cls_bpf 等非常规路径）。
即使强行用 eBPF 或 tc 捕获原始帧，也无法区分“嗅探行为”：混杂模式本身不发包、不改包、不响应，它只是静默接收。你看到的“异常流量”往往是嗅探器上层应用（如 tcpdump、Wireshark）触发的后续行为（如 DNS 查询、HTTP 请求），而非混杂模式本身的特征。
真正可行的防御思路不是拦 MAC，而是控行为
与其试图拦截“混杂模式下的未知 MAC 包”，不如聚焦可检测、可干预的网络层异常：
-
关闭不必要的混杂权限：限制普通用户执行
ip link set eth0 promisc on，通过 capabilities（CAP_NET_RAW）或 sudo 权限管控 - 监控异常 ARP 行为：部署 arpwatch 或自定义脚本，发现同一 IP 多个 MAC、频繁 Gratuitous ARP、ARP 表抖动等典型中间人/嗅探前兆
- 交换机端口安全：在物理/虚拟交换机上配置 port-security、DAI（动态 ARP 检测）、IPSG（IP 源防护），从网络基础设施侧阻断非法 MAC 学习和 ARP 欺骗
-
主机层连接跟踪审计：用 nftables 的
ct state invalid或log规则标记异常连接状态；结合 auditd 监控cap_net_raw使用记录
如果真要尝试底层帧级控制（不推荐生产环境）
仅作技术说明，需明确风险：
- 加载
clsactqdisc：tc qdisc add dev eth0 clsact - 用
tc filter+bpf或flower匹配 dst mac 并丢弃：tc filter add dev eth0 ingress protocol all flower dst_mac 00:11:22:33:44:55 action drop - 注意：这作用于 ingress 路径（接收方向），但仍在驱动之后、协议栈之前；且无法识别“混杂模式”，只能按 MAC 字面值过滤；误配会导致整台机器断网
