iptables -m cluster模块仅实现无状态VIP哈希分发，不提供防火墙策略、访问控制或连接管理功能；其本质是PREROUTING链内的CLUSTERIP目标导向机制，依赖组播MAC和二层可达性，无健康检查与状态同步能力。
iptables 的 cluster 模块不能实现“无中心防火墙分流”，它也不是为“分流控制”设计的。它的实际作用非常明确：在多个节点间共享同一个虚拟 IP（VIP），让外部流量基于哈希自动落到某一个节点上，所有节点都监听同一 VIP，但内核只让其中一个真正处理该连接。
这个机制是无状态、无中心、无健康检查、无策略能力的纯分发层，和防火墙、访问控制、连接管理完全无关。
它到底能做什么？
- 所有节点绑定相同 VIP（如
192.0.2.100）到本地 dummy 或 loopback 接口 - 所有节点配置相同组播 MAC 地址（必须是组播，如
01:00:5E:00:00:01） - 每个节点加载一条
CLUSTERIP规则，指定自己在集群中的编号（--cluster-local-node 1）和总节点数（--cluster-total-nodes 4） - 流量进入 PREROUTING 链后，根据源 IP（或源 IP+端口）哈希，决定由哪个节点接收并继续处理
- 业务进程（如 nginx）直接监听该 VIP:port，无需反向代理或额外负载均衡器
示例命令（节点 1）：
iptables -t nat -A PREROUTING -d 192.0.2.100 -p tcp --dport 80 \ -m cluster --cluster-total-nodes 4 --cluster-local-node 1 \ --cluster-hash-init 0xdeadbeef --cluster-mode sourceip \ -j CLUSTERIP
它不能做什么？
- ❌ 不检查源 IP 是否合法，不识别攻击行为
- ❌ 不支持 ipset、geoip、string 等扩展做访问控制
- ❌ 不记录连接状态，无法配合
connlimit或hashlimit做限速 - ❌ 不修改包内容（不 SNAT/DNAT），不干预 FORWARD/OUTPUT 链
- ❌ 不提供故障转移或节点健康检测，宕机节点仍会收包但无法响应
- ❌ 无法实现“某类流量只进节点 A”，这类逻辑必须靠前置路由设备或本机 filter 表叠加规则
实际部署关键点
- 交换机必须允许该组播 MAC 泛洪，或配置静态组播转发表，否则非首节点收不到流量
- 所有节点需时间同步（NTP），避免哈希不一致
-
--cluster-hash-init建议统一设置，确保各节点哈希结果一致 - VIP 不能配置在物理网卡上（避免 ARP 冲突），推荐用
dummy0或lo:0 - 后端服务要能绑定非本地地址（需开启
net.ipv4.ip_nonlocal_bind = 1）
和真正“分流”的区别在哪？
| 能力 | iptables -m cluster |
LVS/IPVS | iptables DNAT（轮询/哈希） |
|---|---|---|---|
| 是否需要中心调度器 | 否 | 是（Director） | 否（但依赖本机规则） |
| 是否修改目标 IP | 否 | 是（NAT/DR/TUN） | 是（DNAT） |
| 是否支持健康检查 | 否 | 是（配合 keepalived） | 否（需脚本轮询+动态刷新规则） |
| 是否可叠加防火墙策略 | 否（仅 PREROUTING + CLUSTERIP） | 是（可在 Director 上加 filter 规则） | 是（filter 表独立可用） |
不复杂但容易忽略：cluster 模块只是让多台机器“假装是一个 VIP 主机”，它本身不是负载均衡器，也不是防火墙，更不是服务网格。把它当成分流工具用，等于用螺丝刀敲钉子——能动，但不是正解。
