明确防火墙后端是管理前提：先用systemctl status确认firewalld或iptables是否活跃，再结合lsmod判断nftables支持；按数据流向分链归类（input/output/forward），用状态跟踪精简规则，保存并验证规则有效性。
Linux防火墙配置容易混乱，核心原因在于规则叠加、链表顺序敏感、状态跟踪不一致，以及iptables与firewalld混用。梳理策略的关键不是重写所有规则，而是建立可读、可验证、可回滚的结构化管理方式。
明确当前使用的防火墙后端
先确认系统实际生效的是哪套机制，避免操作错层：
- 运行 systemctl status firewalld 查看 firewalld 是否活跃；若显示 active，则它正接管 iptables 规则（即使 iptables 命令能执行，也可能被 firewalld 覆盖）
- 运行 systemctl status iptables 或检查 /etc/sysconfig/iptables 文件是否存在，判断是否为传统 iptables 模式（常见于 CentOS 6/RHEL 6）
- 运行 lsmod | grep nf_tables 可辅助判断内核是否启用 nftables 支持；现代发行版（如 RHEL 8+/Ubuntu 20.04+）默认使用 nftables 后端，但 firewalld 仍可兼容调用
按数据流向分链归类，不堆砌规则
把规则对应到明确的网络路径上，避免在 INPUT 链里塞转发逻辑、或在 FORWARD 链里管本机服务：
- INPUT 链：只处理目的地是本机的数据包（如 SSH、HTTP 服务监听）
- OUTPUT 链：只处理本机主动发出的数据包（如 curl 外部 API、yum 更新）
- FORWARD 链：仅用于网关/路由场景，且必须配合 net.ipv4.ip_forward = 1 内核参数启用
- 若无 NAT 需求，nat 表（PREROUTING/POSTROUTING）可清空不查；若发现 nat 表有规则却未做端口映射或 SNAT，大概率是历史残留
用状态跟踪替代冗余放行
避免为每个服务单独加“允许响应包”规则。正确做法是依赖连接状态，大幅精简规则数：
- 在 INPUT 链开头插入：iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
- 后续只需定义“新连接”的白名单，例如：-A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
- 这样既允许已建立连接的返回流量，又防止非法新连接绕过端口限制
保存并验证规则有效性
临时命令不等于持久生效，且规则顺序直接影响结果：
- iptables 规则重启即失效，需执行：iptables-save > /etc/sysconfig/iptables（CentOS/RHEL）或 iptables-save | sudo tee /etc/iptables/rules.v4（Debian/Ubuntu）
- firewalld 修改后务必运行：firewall-cmd --runtime-to-permanent
- 验证时不用只 ping，用 iptables -L -v -n 查看各规则命中计数；某条 DROP 规则计数暴涨，说明前面漏放或顺序错了
