Linux系统内核防火墙表项深度配置方法

首先给出核心结论：所谓 Linux 内核防火墙的“配置深度”，实际上是一个常见误解。它并非一个可直接调优的参数，而是由用户态工具（如 iptables、nft）向内核 netfilter 框架写入的规则集合。通常所说的“深度”，本质上是规则链中的匹配顺序、跳转逻辑、自定义链的嵌套层级，以及各表（raw → mangle → nat → filter）协同工作所带来的整体处理复杂度。

为什么无法直接调整内核防火墙表项的“深度”

内核本身并未提供任何名为“深度”的参数供用户修改——netfilter 的 5 个 hook 点（PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING）固定不变，每个 hook 关联的表（raw/mangle/nat/filter）也是在编译时已预先确定。所谓“深度”，实际上是指规则在链中的具体位置、是否跳转到自定义链、以及是否触发某些内核模块（如 xt_connlimit）这些行为叠加后的综合结果。

• 规则位置越靠前，匹配优先级越高，但这并不代表“更深”；反而可能被后续规则覆盖（例如先执行 -j ACCEPT 再执行 -j DROP 将导致后者无效）
• 自定义链（iptables -N MYCHAIN）支持嵌套调用，但内核并未设置递归限制，仅受栈空间约束——过度嵌套极易触发 nf_tables: maximum number of expressions exceeded 这样的错误
• nat 表的 PREROUTING 和 POSTROUTING 链仅在连接首次建立时触发一次，并不适用于每包匹配的场景；若放错位置，端口转发失效或 SNAT 不生效的情况十分常见

iptables 中影响规则“处理深度”的关键操作

真正决定数据包需要经过多少层判断的，是规则链的组织方式以及跳转策略：

• 使用 -j CT --notrack 跳过连接跟踪，可降低 nf_conntrack 模块开销，但代价是丢失状态匹配能力（例如 -m state --state ESTABLISHED 将失效）
• -j LOG 配合 --log-prefix 可记录匹配路径，但每条 LOG 规则都会增加内核日志系统调用的次数，在高流量场景下极易拖慢整个链
• -j REDIRECT 实质上是 DNAT 的简化语法，仅能用于 nat/PREROUTING；若在 filter/INPUT 中使用，会直接报错 iptables: No chain/target/match by that name
• 混用 iptables 与 nft 会导致规则冲突——二者虽然共用 netfilter hook，但规则存储结构完全不同，iptables-legacy 的规则很可能被 nft 清空

查看当前生效的“深度结构”真实路径

切勿只依赖文档中的理论流程图，请使用以下命令实际检查数据包的通行路径：

sudo iptables -t raw -L -v --line-numbers
sudo iptables -t mangle -L PREROUTING -v --line-numbers
sudo iptables -t nat -L PREROUTING -v --line-numbers
sudo iptables -t filter -L INPUT -v --line-numbers

重点观察每条规则下方的 pkts 计数：如果某条 -j MYCHAIN 规则的计数为 0，说明前面已有规则提前执行了 ACCEPT 或 DROP，数据包根本未到达该层。

• 例如在 iptables -t filter -L INPUT -n --line-numbers 中，第 3 行为 -j DROP，但第 1 行 -s 127.0.0.1 -j ACCEPT 已提前截获本地请求——此时对本地流量而言，“深度”实际上只有 1 层
• nft list ruleset 的输出能更直观地展示链跳转层级，例如 jump MY_CHAIN 下又嵌套 meta nfproto ipv4 jump DEEP_CHECK，这代表两层跳转
• 若启用了 CONFIG_IP_NF_DEBUG 内核选项，可通过 dmesg | grep nf 查看每个数据包经过的 hook 名称，但该选项仅适合调试，生产环境切勿开启

真正的难点不在于规则层数的多少，而在于让每一层拥有明确的职责且互不干扰——例如 raw 表只负责 NOTRACK，mangle 表只修改 TTL 或 MARK，nat 表只做地址转换，filter 表只负责放行或拒绝。那些将多种功能混杂在一起的规则链，才是导致“深度失控”的根本原因。