iptables规则是否真正生效，需先确认firewalld是否活跃——若systemctl status firewalld显示active(running)，则iptables仅为只读查看器；再通过iptables -Lnv检查规则计数器及conntrack状态验证内核实际加载与匹配情况。
iptables 规则是否真正生效，不能只看 iptables -L 输出——很多情况下规则“写了但没用”，因为 firewalld 正在后台接管。监控策略生效状态，核心是确认“谁在管流量”以及“规则是否被内核实际加载”。告警则需围绕关键链默认策略、高危端口暴露、异常 DROP 率等可量化指标展开。
确认 iptables 是否真实接管流量
这是所有监控的前提。firewalld 活跃时，iptables 命令只是只读查看器，改规则无效。
- 运行
systemctl status firewalld，若显示 active (running)，说明 firewalld 在控制 netfilter，iptables 规则不生效 - 验证接管状态：执行
iptables -t nat -L -n和firewall-cmd --list-all 2>/dev/null || echo "firewalld not running"—— 两者输出应明显不同，且后者应报错或提示未运行 - 如需切回 iptables：停用 firewalld（
systemctl stop firewalld && systemctl disable firewalld），RHEL/CentOS 7+ 还需安装并启用iptables-services
监控规则是否被内核加载并匹配
仅存在规则列表不等于规则起作用。要确认规则是否被命中，需检查计数器和连接跟踪状态。
- 用
iptables -Lnv查看每条规则的 packet 和 byte 计数。若某条 ACCEPT 规则计数长期为 0，可能位置错误（如被前面的 DROP 拦截）或流量根本没到达 - 重点检查
-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT是否排在 INPUT 链最前（建议用iptables -nL --line-numbers核对序号），否则新连接无法建立 - 运行
conntrack -L | wc -l查看当前跟踪连接数，突降可能表示状态匹配失效；突增且伴随高 DROP 率，可能是 SYN Flood 攻击
设置基础告警指标与脚本示例
告警应聚焦可自动采集、有明确阈值、影响业务的关键点。
-
默认策略异常：监控
iptables -S INPUT | grep "^-P INPUT"，若非 DROP 或 ACCEPT（如意外变成 REJECT），立即告警 -
SSH 端口暴露风险：检查
iptables -L INPUT -n | grep ":22.*ACCEPT"，若匹配到非白名单 IP 的开放规则（如-s 0.0.0.0/0），触发告警 -
高频 DROP 告警：每分钟执行
iptables -L INPUT -v -n | awk 'NR==3 {print $1}'提取 DROP 行包计数，与上一分钟对比增长超 500 包/秒，发告警（需排除 ping 扫描等误报） - 将上述检查写成 shell 脚本，配合 cron 每 2 分钟执行一次，输出异常时调用
logger或 curl 推送企业微信/钉钉 webhook
避免常见监控盲区
很多问题不是规则没写，而是规则逻辑或上下文出错。
- 别只查 filter 表：NAT 规则（如 DNAT 转发）在
iptables -t nat -L，漏查会导致端口映射失效 - 注意链顺序：-A 追加在末尾，-I 插入在开头。用
--line-numbers确认关键规则（如 ESTABLISHED、白名单）是否真在高位 - 保存≠生效：
iptables-save > /etc/sysconfig/iptables（CentOS）或netfilter-persistent save（Debian）必须执行，否则重启后规则丢失 - 内核模块依赖：确保
nf_conntrack、xt_conntrack已加载（lsmod | grep conntrack），否则状态匹配失效
