查看iptables规则命中次数：iptables问题排查终极指南

发布于 2025-10-29 分类: Linux
系列文章: iptables 入门教程：从“门卫”到“网络总管”
第 1 部分: iptables终极教程（2024）：从零理解Docker/K8s网络原理的基石 第 2 部分: iptables核心详解：彻底搞懂表、链、规则和动作的关系 第 3 部分: iptables 数据包流程图详解：一张图彻底搞懂数据包的完整路径 第 4 部分: iptables常用命令与实例：从开放端口到配置NAT防火墙 第 5 部分: 查看iptables规则命中次数：iptables问题排查终极指南 (当前) 第 6 部分: iptables重启后规则丢失怎么办？终极指南：永久保存iptables规则 (Ubuntu/CentOS)

好的，我们进入高级阶段——故障排查。这是区分iptables新手和老手的关键能力。本章将为你装备一套完整的“侦探工具”，让你在网络迷雾中找到真相。

到目前为止，你已经学会了如何制定iptables规则。但现实世界中，最常遇到的挑战是：“我配置了规则，为什么服务还是不通？”或者“为什么这个IP还是能访问我的服务器？” 这时，你就需要化身为一名网络侦探，找出数据包被错误处理的真凶。很多时候，答案就藏在规则的命中次数里。

本章就是你的“侦探工具箱”，我们将学习如何调试iptables规则，系统性地追踪那些被错误丢弃或放行的数据包。

4.1 连接跟踪 (Stateful Firewall) 的重要性

在深入排错之前，我们必须先掌握iptables最强大的特性之一：连接跟踪（Connection Tracking）。iptables不仅仅是简单地看每个数据包的IP和端口，它还能“记住”连接的状态，这就是所谓的“状态防火墙”。

iptables通过 -m state 模块，将连接分为四种状态：

  • NEW: 连接的第一个包。比如，你访问一个网站时发出的第一个TCP SYN包。
  • ESTABLISHED: 连接已建立。在TCP三次握手完成后，后续的所有双向通信数据包都处于这个状态。
  • RELATED: 关联连接。有些协议比较复杂，会“衍生”出新的连接，比如FTP协议。主连接是21端口，但数据传输会随机开一个新端口，这个新端口的连接就是RELATED。
  • INVALID: 无效或无法识别的包。比如，一个不属于任何已知连接的TCP ACK包。

还记得我们在第三章配置的那条核心安全规则吗？

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

这条规则的威力在于，只要一个NEW状态的连接被你后续的规则（如 ... --dport 22 -j ACCEPT）放行了，那么这个连接后续所有的数据交换（ESTABLISHED状态）都会被这条规则快速接受，大大简化了规则集，也提高了安全性。

排错启示：当你发现连接“通了一下就断”，或者只能单向通信时，很可能是连接跟踪出了问题，或者你错误地DROP了ESTABLISHED状态的包。

4.2 自定义链：让规则井井有条

当规则越来越多时，INPUT、OUTPUT 这些主链会变得臃肿不堪，难以阅读和维护。这时，我们可以使用自定义链来组织规则。

引例：假设你想把所有和Web服务（80, 443）相关的规则放在一起。

第1步：创建自定义链
使用 -N (New-chain) 命令创建一个名为 WEB_RULES 的链。

iptables -N WEB_RULES

第2步：在自定义链中添加规则

iptables -A WEB_RULES -p tcp --dport 80 -j ACCEPT
iptables -A WEB_RULES -p tcp --dport 443 -j ACCEPT
# 可以在这里添加更多针对Web的复杂规则，比如限制特定IP

第3步：将主链的流量引导至自定义链
在 INPUT 链中，创建一个“跳转”规则，将所有访问Web端口的流量都交给 WEB_RULES 链去处理。

iptables -A INPUT -p tcp -m multiport --dports 80,443 -j WEB_RULES

工作流程：一个访问80端口的数据包进入 INPUT 链，匹配到这条规则后，就会 -j (Jump) 到 WEB_RULES 链。在 WEB_RULES 链中，它被 -j ACCEPT。如果 WEB_RULES 链中所有规则都不匹配，它会回到 INPUT 链的下一条规则继续匹配。

排错启示：使用自定义链能让你的规则逻辑更清晰，排错时可以更快速地定位到相关的规则集合。

4.3 【核心排错技能】故障排查：追踪“失踪”的数据包

现在，让我们打开侦探工具箱。当一个连接不通时，数据包很可能在某个链的某条规则上被 DROP 了。我们的任务就是找到它。

排错流程总结（记忆口诀）：先看录像（Counters），再装窃听（LOG），不行再上全跟踪（TRACE）。

第一步：查看iptables规则命中次数 - 最高效的排错起点

这是最快、最直接的排错方法。学会查看iptables规则命中次数是所有高级排错技巧的基础。iptables会为每一条规则记录两个计数器：匹配到的数据包数量（pkts）和字节总数（bytes）。

操作步骤：

  1. 执行一次会导致问题的操作。比如，从客户端尝试连接一次被阻止的服务器端口。
  2. 立即查看带计数器的规则列表。
    iptables -L -n -v --line-numbers
  3. 分析计数器变化。找到 pkts 计数器刚刚增加了 1 或更多的那条规则。这条规则很可能就是“真凶”。

实战案例：
你发现无法SSH到服务器。你执行 ssh your_server_ip，失败后立即在服务器上运行 iptables -L INPUT -n -v --line-numbers。

输出可能像这样：

Chain INPUT (policy DROP 15 packets, 840 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       58  4321 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
2     1304 98765 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
3        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
4        1    60 DROP       tcp  --  *      *       1.2.3.4              0.0.0.0/0            tcp dpt:22

你发现第4条规则的 pkts 计数器是 1，并且明确写着 DROP 了来自你IP 1.2.3.4 的22端口流量。问题找到了！

查看iptables规则命中次数 就是通过观察 pkts 计数器的变化来实现的。这是排错的第一步，也是最高效的一步。

第二步：安装“窃听器” - 使用iptables日志记录丢弃的包

如果计数器无法精确定位问题（比如，流量很大，看不出具体是哪个包），或者你想知道被默认策略DROP的包到底是什么，就需要使用 LOG 目标，让iptables日志记录丢弃的包。

LOG 目标像一个窃听器，它不会 ACCEPT 或 DROP 数据包，只是将数据包的头信息记录到系统日志中，然后让数据包继续往下匹配规则。

方法一：记录所有被默认策略丢弃的包
在链的末尾，也就是在所有 ACCEPT 规则之后，添加一条 LOG 规则。

# 对于INPUT链
iptables -A INPUT -j LOG --log-prefix "INPUT_DROPPED: "
# 对于FORWARD链
iptables -A FORWARD -j LOG --log-prefix "FORWARD_DROPPED: "

--log-prefix 会在你每条日志前加上一个自定义的前缀，方便你筛选。

方法二：精准定位特定规则
如果你怀疑某条 DROP 规则有问题，可以在它前面插入一条 LOG 规则。

# 假设你想调查上面案例中第4条DROP规则
# 先插入一条LOG规则到第4个位置
iptables -I INPUT 4 -s 1.2.3.4 -p tcp --dport 22 -j LOG --log-prefix "SSH_DROP_ATTEMPT: "

现在，任何匹配这条DROP规则的包，都会先被LOG记录下来。

如何查看日志？
通常在 /var/log/syslog (Debian/Ubuntu) 或 /var/log/messages (CentOS/RHEL) 中。也可以直接使用 dmesg 命令查看内核环形缓冲区：

dmesg | grep "DROPPED"

日志输出会包含详细信息，如源/目的IP、端口、协议、网卡等，一目了然。

第三步：终极武器 - iptables TRACE用法详解

在极其复杂的场景下（比如涉及多个自定义链跳转，或者 mangle 和 nat 规则交织），LOG 也可能无法说清数据包的完整路径。这时，我们需要终极武器：TRACE。

TRACE 目标可以详细记录一个数据包流经的每一个链、每一条规则。下面是详细的iptables TRACE用法：

  1. 加载模块:
    modprobe nf_log_ipv4
  2. 在 raw 表的 PREROUTING 和/或 OUTPUT 链中开启TRACE。raw 表优先级最高，能确保我们从数据包旅程的最开始就进行追踪。
    # 追踪所有进入的、目的地为TCP 22端口的包
iptables -t raw -A PREROUTING -p tcp --dport 22 -j TRACE
# 追踪所有本机产生的、去往TCP 80端口的包
iptables -t raw -A OUTPUT -p tcp --dport 80 -j TRACE
  3. 查看追踪日志:
    同样使用 dmesg 查看。你会看到非常详细的输出，例如：
    TRACE: raw:PREROUTING:rule:1 IN=eth0 OUT= MAC=... SRC=1.2.3.4 DST=5.6.7.8 ...
TRACE: mangle:PREROUTING:return:
TRACE: nat:PREROUTING:return:
TRACE: filter:INPUT:rule:2 ... ACCEPT
    这个输出清晰地展示了数据包在 raw 表 PREROUTING 链匹配了第1条规则，然后依次经过了mangle、nat表，最后在filter表INPUT链的第2条规则被ACCEPT。

警告：TRACE 会产生大量的日志，对系统性能有显著影响。它是一个纯粹的调试工具，用完后一定要立即删除规则！

-- 感谢阅读 --