不能靠服务器本机防火墙（如 nftables 或 iptables）实现可靠、无感的 mac 地址访问限制，因内核在包进入规则链前已剥离 mac 头，nftables 完全不支持 mac 匹配，iptables 的 -m mac 仅限直连二层且易伪造、失效；真正可行方案是接入侧交换机端口安全或 radius 认证。

直接说结论：**不能靠服务器本机防火墙（如 nftables 或 iptables）实现可靠、无感的 MAC 地址访问限制**。MAC 地址是链路层信息，现代 Linux 内核在数据包进入防火墙规则链前，已剥离或覆盖原始 MAC 头；nftables 甚至完全移除了 MAC 匹配能力，iptables 的 `-m mac` 也仅在极少数直连二层场景下偶然生效，且极易被伪造、绕过或因网络拓扑变化而失效。 真正可行的配置位置不在服务器上，而在网络接入侧——也就是交换机、路由器或无线控制器。以下是实际可用、分层落地的方案：

在接入交换机上启用端口安全（最常用、最有效）

这是企业局域网中最主流、最稳定的 MAC 限制方式，控制粒度精确到物理端口：

• 登录交换机（如华为/H3C/Cisco），进入目标端口配置模式（例如 interface GigabitEthernet0/0/5）
• 启用端口安全：port-security enable
• 绑定唯一合法 MAC：port-security mac-address sticky 00:11:22:33:44:55（自动学习当前接入设备）
• 设置违规动作：port-security protect-action shutdown（推荐，比 restrict 更防干扰）
• 保存配置并退出，该端口此后只接受该 MAC 设备上线，插错即断连

用 RADIUS 实现集中式 MAC 认证（适合中大型网络）

当终端数量多、需审计或与账号系统联动时，应升级为动态认证：

HTML5主机托管服务公司网站模板

HTML5主机托管服务公司网站模板是一款从事主机托管服务公司宣传网站模板下载。提示：本模板调用到谷歌字体库，可能会出现页面打开比较缓慢。

下载

• 在汇聚交换机或无线 AC 上启用 MAC Authentication，并指向 FreeRADIUS 或商用 RADIUS 服务器
• RADIUS 中预录入合法终端 MAC，并关联权限策略（如“只允许访问数据库服务器的 3306 端口”）
• 终端首次接入时，设备自动截获其 DHCP 或 ARP 报文中的 MAC 发起认证
• 通过后，RADIUS 下发 VLAN、ACL 或带宽策略，实现细粒度访问控制

服务器端补充防护（非 MAC 主控，但增强纵深）

网络设备层做好 MAC 控制后，可在服务器上加一层辅助防护，防 ARP 欺骗绕过：

• 执行静态 ARP 绑定：sudo arp -s 192.168.10.50 00:1a:2b:3c:4d:5e（将关键客户端 IP 与 MAC 强制绑定）
• 配合 iptables 规则（仅作补充）：iptables -A INPUT -s 192.168.10.50 -j ACCEPT，再加一条默认 DROP
• 注意：这条规则依赖的是 IP，不是 MAC；MAC 只用于前期绑定和校验，不参与防火墙匹配

为什么不建议在 openWRT 或家用路由器上用 iptables -m mac？

虽然 openWRT 等固件支持 iptables -m mac --mac-source，但它有严重局限：

• 仅对从 LAN 口直连进来的流量有效，经 NAT、桥接、VLAN 或 WiFi 中继的包，MAC 已被替换
• 无法区分同一 IP 下多个设备（如手机热点共享），容易误杀
• 用户改个 MAC（ip link set dev wlan0 address xx:xx:xx:xx:xx:xx）就完全失效
• 属于“看起来能用，实际不可靠”的配置，不推荐用于敏感业务