iptables的-m mac模块仅适用于直连二层网络中网关直收或转发的原始帧，需同时满足同网段、无nat/路由、流量经input/forward早期阶段、内核启用config_netfilter_xt_match_mac及mac稳定等全部前提，否则规则静默失效；典型配置如openwrt中用-i forward插入白名单与兜底drop规则，但易受mac伪造、虚拟化、云环境等影响，应结合ebtables、dhcp绑定及认证机制分层加固。
iptables 的 -m mac 模块可以实现基于源 MAC 地址的接入控制，但**仅适用于网关设备自身直收或转发的原始二层帧**，且必须满足严格网络前提。它不是通用准入方案，而是特定场景下的补充手段。
适用前提必须全部满足
否则规则静默失效：
- 客户端与网关处于同一物理或 VLAN 二层网络，中间无三层路由/NAT 设备（如光猫、企业防火墙）
- 网关已关闭 IP 转发（
sysctl net.ipv4.ip_forward = 0）——若用作路由器，则必须开启并走 FORWARD 链 - 流量路径经过 INPUT（本机服务）或 FORWARD（跨网段转发）链的早期阶段，未被桥接、Docker 或虚拟交换机绕过
- 内核已启用
CONFIG_NETFILTER_XT_MATCH_MAC（主流发行版默认开启） - 目标设备 MAC 稳定（未启用随机化，未频繁更换网卡）
正确配置方式（以 OpenWrt/软路由为典型）
网关通常开启转发，终端访问外网走 FORWARD 链。要只放行合规 MAC，需“先白后黑”+“插入顶部”：
- 用
-I FORWARD插入最前，避免被后续 ACCEPT 规则跳过 - 先明确允许合规 MAC 访问局域网（如
-d 192.168.0.0/16）、必要服务（如 DNS、DHCP） - 再对同一 MAC 允许访问 WAN（如
-o br-wan -j ACCEPT） - 最后用
-j DROP拦截所有未匹配的该 MAC 流量（或全局兜底）
示例（仅允许 00:11:22:33:44:55 上网）：
iptables -I FORWARD -m mac --mac-source 00:11:22:33:44:55 -d 192.168.0.0/16 -j ACCEPT iptables -I FORWARD -m mac --mac-source 00:11:22:33:44:55 -d 10.0.0.0/8 -j ACCEPT iptables -I FORWARD -m mac --mac-source 00:11:22:33:44:55 -d 172.16.0.0/12 -j ACCEPT iptables -I FORWARD -m mac --mac-source 00:11:22:33:44:55 -o br-wan -j ACCEPT iptables -I FORWARD -m mac --mac-source 00:11:22:33:44:55 -j DROP
关键细节与避坑点
- MAC 地址必须小写、冒号分隔：
00:11:22:33:44:55，不能是短横线或大写 - 只支持
--mac-source，不存在--mac-dest参数 - 规则顺序决定成败：允许规则必须在拒绝规则之前；
-I插入比-A追加更可靠 - 不防 ARP 欺骗：单靠 MAC 易伪造，建议搭配静态 DHCP + IP-MAC 绑定（如 dnsmasq 的
dhcp-host） - 云主机、Docker/KVM 桥接、IPv6 SLAAC 等场景基本无效——原始 MAC 在到达 netfilter 前已被替换
更可靠的替代或补充方案
纯 MAC 控制脆弱，推荐分层加固：
- WiFi 层：OpenWrt 中直接启用
macfilter 'allow'（硬件级过滤，早于 netfilter） - 链路层：用
ebtables在网桥上拦截原始帧（比 iptables 更底层、更稳定） - 网络层：结合
fail2ban监控登录日志，动态封禁异常 IP - 认证层：强制 SSH 密钥、802.1X 或 Captive Portal 接入认证
不复杂但容易忽略：MAC 地址本身无身份可信性，真正合规的接入控制必须结合认证、绑定与行为分析。
