Linux防火墙真正“看懂”连接依赖conntrack机制，它通过提取数据包五元组生成双向状态记录，使无状态包变为有记忆会话；TCP SYN标NEW、SYN-ACK后升ESTABLISHED并打[ASSURED]，UDP/ICMP同理完成状态跃迁；缺失conntrack则iptables --ctstate失效、NAT断连、多通道协议异常。
Linux 防火墙真正“看懂”连接，靠的不是规则本身，而是 conntrack —— 它把无状态的数据包，变成有记忆的会话。没有它，iptables 的 --ctstate ESTABLISHED 就是空转，NAT 会断连，FTP/SIP 等多通道协议直接失效。
Conntrack 是怎么“记住”一个连接的
每个进来的数据包，只要经过 PREROUTING 或 OUTPUT 链，conntrack 就会提取它的五元组（协议、源IP、源端口、目的IP、目的端口），生成一条双向记录：
- TCP 第一个 SYN 包进来 → 状态标记为 NEW，进入未确认链表
- SYS-ACK 回来 → 状态升级为 ESTABLISHED，正式入库并打上 [ASSURED]
- UDP 首包进来也标 NEW；收到反向响应后变为 ESTABLISHED（超时前）
- ICMP 请求/应答配对成功，同样完成 NEW → ESTABLISHED 流程
用 conntrack 查真实状态，别只盯 iptables 规则
规则写得再对，如果连接根本没进 conntrack 表，或者状态卡在异常值，流量照样不通：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 完全查不到记录 → 可能被 raw 表的 NOTRACK 跳过，或包没走到 netfilter 关键链（如本地 loopback 直通）
- 状态是 INVALID → 报文异常（FIN 乱序、TCP 标志非法），常被
-m conntrack --ctstate INVALID -j DROP拦截 - 大量 [UNREPLIED] 条目 → 只发请求没回包，典型后端宕机或 SYN Flood
- 状态是 NEW 却连不上 → iptables 缺少对应
--ctstate NEW的 ACCEPT 规则 - 已是 ESTABLISHED 却被 DROP → 后续规则（如通用 DROP）覆盖了前面的 ACCEPT，链顺序出问题
排查 NAT 和容器通信异常的关键点
Kubernetes、Docker、OVS 等场景下，conntrack 是 DNAT/SNAT 正常工作的前提：
- DNAT 后，conntrack 表里必须同时存在原始五元组和转换后五元组，才算映射完整
- 同一主机内 Pod 访问 Service IP 时，响应可能绕过网络层 → SNAT 不触发 → conntrack 表缺少反向映射 → 连接卡死
- 用
sudo conntrack -L | grep "10.96.0.10"查 Service IP 是否有双向记录；对比ss -tunp看实际 socket 是否绑定正确 - 发现某 IP 占用数百条连接？立即结合
conntrack -L | grep x.x.x.x | wc -l和ss -tunp src x.x.x.x定位进程
监控资源瓶颈与攻击迹象
conntrack 表满会导致新连接全部被丢弃，症状像“防火墙突然全拦”，但规则没动：
- 当前条目数：
cat /proc/sys/net/netfilter/nf_conntrack_count - 最大容量：
cat /proc/sys/net/netfilter/nf_conntrack_max（默认通常 65536） - TCP 状态堆积分析：
sudo conntrack -L -p tcp | awk '{print $4}' | sort | uniq -c→ 关注 SYN_RECV（SYN Flood）、TIME_WAIT（连接释放慢）、CLOSE_WAIT（应用未 close） - UDP 连接暴增？
sudo conntrack -L | awk '$1=="udp" {print $3":"$4}' | sort | uniq -c | sort -nr | head -10快速定位扫描源
