tcpdump 是 Linux 下调试防火墙的核心工具，需明确抓包位置、规则执行顺序并比对计数；推荐结合 -j LOG、dmesg 及指定接口（如 eth0/lo）精准定位丢包原因。
tcpdump 是 Linux 下最常用的网络抓包工具，配合防火墙（如 iptables、nftables 或 firewalld）调试时，能精准定位“包到底有没有发出去”“为什么被丢弃”“规则是否生效”等关键问题。核心要点是：先明确抓包位置（链路层 vs 网络层）、再确认防火墙规则执行顺序、最后比对抓包结果与规则动作。
抓包位置决定你能看到什么
防火墙规则在内核协议栈不同位置生效，而 tcpdump 默认在网卡驱动之后、IP 层之前捕获数据包，因此：
- 在 INPUT 链丢弃的包，若在本机发起连接，tcpdump 能抓到入向包（因为已过网卡驱动）；但若目标端口无监听进程，后续被内核丢弃，tcpdump 仍可见
- 在 OUTPUT 链丢弃的包，tcpdump 同样能抓到出向包（只要没被早于 POSTROUTING 的模块拦截）
- 若想确认 iptables 是否真丢包，需结合 iptables -t filter -L -v -n 查看对应链的 packet 计数，并与 tcpdump 抓到的包数量比对
- 注意：使用 -i any 可能因虚拟设备干扰判断，建议指定物理接口（如 eth0）或 lo（调试本地回环通信）
区分 iptables 和 nftables 的调试逻辑
iptables 和 nftables 规则触发时机相近，但计数方式和日志机制不同：
- iptables 中，加 -j LOG 可记录匹配包（需加载 nf_log_ipv4 模块），再用 dmesg -w 实时查看，比单纯看计数更直观
- nftables 推荐用 nft add rule ip filter input log prefix "DEBUG-IN: "，同样配合 dmesg；也可用 nft list ruleset -a 显示 handle，便于插入/删除特定规则
- 两者都支持 -j DROP 前加 -j LOG，避免“静默丢包”，这是调试防火墙最实用的习惯
常见误判场景与验证方法
很多“连不上”问题并非防火墙导致，tcpdump 可快速排除干扰：
- 客户端发包但服务端收不到：在服务端执行 tcpdump -i eth0 port 8080，若完全无包，说明问题在路由、中间设备或客户端未发出；若有包但无响应，再查服务状态和 INPUT 规则
- 本机访问自己失败（如 curl http://localhost）：必须用 -i lo 抓环回接口，否则看不到流量；此时 OUTPUT 和 INPUT 链均参与处理，需同时检查
- firewalld 启用后不通：firewalld 是 nftables 前端，运行 firewall-cmd --list-all 查当前 zone 和端口，再用 nft list ruleset 看底层规则是否生成正确
- 抓包显示 SYN 包发出但无 SYN-ACK：可能是远端防火墙拦截、服务未监听、或本机 OUTPUT 链 DROP，而非 INPUT 问题
一条高效调试命令组合
日常排查可直接运行（以调试 SSH 连接为例）：
- 终端1：sudo tcpdump -i eth0 -nn port 22
- 终端2：sudo iptables -t filter -L INPUT -v -n | grep :22
- 终端3：sudo ss -tlnp | grep :22（确认 sshd 是否监听）
- 若 tcpdump 有 SYN 但无 ESTABLISHED，且 ss 显示监听正常，则重点查 INPUT 链中是否有显式 DROP 或 REJECT 规则优先匹配
