iptables原生不推荐直接靠MAC控制，因其运行在网络层，默认看不到数据链路层的MAC地址，且xt_mac模块仅限INPUT/PREROUTING链、不支持转发流量、易受IP-MAC映射变动影响。
iptables 本身不直接处理 MAC 地址匹配，但可通过 ebtables（工作在数据链路层）或 iptables 的 xt_mac 模块（仅限输入方向、且仅对经过本机路由的帧有效）实现基于 MAC 的访问控制。实际部署中，推荐优先使用 ebtables 配合 iptables 分层管控，尤其在纯二层局域网（如无 IP 分配的访客网络）或需严格绑定物理设备的场景下。
为什么 iptables 原生不推荐直接靠 MAC 控制？
iptables 运行在网络层（IP 层），默认只能看到 IP 报文头；MAC 地址在数据链路层，进入 netfilter 钩子时多数已被剥离（除 INPUT 链中部分本地接收包）。即使加载 xt_mac 模块，也存在明显限制：
- 仅支持 INPUT 和 PREROUTING 链（后者需启用 ip_forward）
- 无法匹配转发流量（FORWARD）中的源 MAC —— 因为交换机/网桥已改写 MAC，到达路由器时源 MAC 是上一跳设备而非终端
- 若设备通过 DHCP 获取 IP 或使用 IPv6 SLAAC，IP 与 MAC 映射易变，单靠 MAC 规则缺乏上下文，易误放或误拦
正确做法：用 ebtables 做第一道 MAC 过滤
ebtables 工作在网桥层，天然可见原始以太网帧，适合在 Linux 网桥（如 br0）、虚拟化宿主机或软路由中做 MAC 白名单/黑名单：
- 允许指定 MAC 访问本机：
ebtables -A INPUT -s 00:11:22:33:44:55 -j ACCEPT - 拒绝所有未知 MAC：
ebtables -A INPUT -j DROP - 结合 iptables 使用：ebtables 控制“能不能发帧到本机”，iptables 再控“能不能建立 TCP 连接或访问某服务”
注意：启用前确保内核已加载 ebtable_filter 和 ebtable_nat 模块，且网卡处于网桥模式（非传统路由模式）。
若必须用 iptables + xt_mac，只用于特定 INPUT 场景
适用于：局域网终端直连 Linux 主机（非经交换机中转）、且主机关闭 IP 转发，所有通信均为本机收发（如打印机服务器、NAS 管理口）：
- 加载模块：
modprobe xt_mac（永久生效可加入/etc/modules） - 只允许某 MAC 访问 SSH：
iptables -A INPUT -m mac --mac-source 00:11:22:33:44:55 -p tcp --dport 22 -j ACCEPT - 务必加一条兜底拒绝：
iptables -A INPUT -m mac ! --mac-source 00:11:22:33:44:55 -j DROP（注意逻辑取反写法） - 该规则对 ARP、ICMP echo request 等非 IP 流量无效 —— 它们不走 iptables INPUT 链
更健壮的替代方案：绑定 + 动态策略
单纯依赖 MAC 地址安全性有限（MAC 可伪造），建议组合使用：
- DHCP + static lease：为可信 MAC 分配固定 IP，再用 iptables 基于 IP 限流/限服务
- 802.1X 认证：在交换机或 hostapd 层强制认证，未授权设备根本拿不到 IP 和 MAC 学习机会
- ARP 监控 + 自动封禁：用 arpwatch 或自定义脚本检测异常 MAC/IP 绑定变动，触发 ebtables 或 iptables 临时拉黑
不复杂但容易忽略的是：任何 MAC 级控制都应在网络边界（如网关、接入交换机）实施，而非在应用服务器上补救。
