nf_conntrack – HDUO Lab

在一次验证系统对 DNS 解析抖动容忍度的 GameDay 实战中，仅向 CoreDNS 注入 200ms 延迟，竟导致数十个业务节点接连失联。核心结论：高并发下微服务的无脑重试，配合 Linux UDP 默认 30 秒的 nf_conntrack_udp_timeout 状态保留，会瞬间撑爆 nf_conntrack 表。在进行网络层混沌工程时，必须提前调优内核连接跟踪参数或使用 raw 表豁免 DNS 流量，并设置基于系统底层指标的爆炸半径熔断器。

1. 故障现场：一场失控的 GameDay

近期的 SLO 验证计划中，我们需要验证核心交易链路在 DNS 存在长尾延迟（P99 200ms）时的系统表现，以确认超时控制和降级策略是否按预期生效。

使用的故障注入工具是 ChaosBlade (v1.7.0)，目标集群为 Kubernetes 1.22，宿主机内核为 5.4.x。通过以下命令对 CoreDNS Pod 所在节点注入网络延迟：

blade create k8s network delay \
  --time 200 --offset 50 \
  --interface eth0 \
  --namespace kube-system \
  --names coredns-xxxx,coredns-yyyy

预期现象：业务监控面板中，外部接口调用的 P99 延迟略微上升，部分请求触发 500ms 的断路器，系统平稳降级。 实际现象：注入 1 分钟后，监控大盘不仅没有展现预期的降级曲线，反而出现了严重的“断崖”。更致命的是，API Server 报错频繁，多个承载高并发业务的 Worker 节点状态变为 NotReady，节点上的所有 Pod 被判定为不可用，开始触发大规模漂移重调度的雪崩。

2. 现场排查：谁拔了宿主机的网线？

由于故障节点 SSH 已经无法连入（连接直接超时），通过带外管理（IPMI）登录物理机终端。

执行 top 查看，CPU 使用率不到 30%，Load Average 在 4.0 左右（对于 64 核机器极低），内存也很充足。但网络就是不通，ping 网关全丢包。

习惯性拉出内核环形缓冲区日志排查：

dmesg -T | tail -n 20

满屏的红色报错直击痛点：

[Tue Oct 24 14:12:33 2023] nf_conntrack: nf_conntrack: table full, dropping packet
[Tue Oct 24 14:12:33 2023] nf_conntrack: nf_conntrack: table full, dropping packet

查看当前的连接跟踪数和系统上限：

cat /proc/sys/net/netfilter/nf_conntrack_count
# 输出: 262144
cat /proc/sys/net/netfilter/nf_conntrack_max
# 输出: 262144

毫无疑问，宿主机的 nf_conntrack 表被打满了，导致 Netfilter 丢弃了所有新建连接的包（包括 Kubelet 与 API Server 的心跳，以及新的 SSH 握手请求）。

到底是什么流量塞满了 conntrack 表？通过 conntrack 工具统计状态：

conntrack -L | awk '{print $1}' | sort | uniq -c

输出结果令人诧异：

      4 ICMP
   1024 tcp
 261116 udp

超过 99% 的表项全被 UDP 占满。

3. 为什么 200ms 的 DNS 延迟会击穿几十万的 conntrack 表？

这涉及到 Linux 内核对 UDP 连接跟踪的处理机制，以及业务代码在面对网络抖动时的“疯狂”行为。

底层原理：UDP 的伪状态机与超时机制

UDP 本身是无连接的，但为了让 iptables/Netfilter 能够实现状态防火墙（例如允许外部响应包返回内部），内核强行给 UDP 设计了连接跟踪机制。

当一个 UDP 包发出时，内核在 nf_conntrack 中建立一条状态，标记为 UNREPLIED。如果在默认时间内收到了对端的回包，状态变更为 ASSURED。在 CentOS/Ubuntu 等主流发行版中，相关的内核参数默认值如下：

net.netfilter.nf_conntrack_udp_timeout = 30 （未收到回包时的保留时间，30秒）
net.netfilter.nf_conntrack_udp_timeout_stream = 120 （收到回包，被认定为流时的保留时间，120秒）

业务雪崩推演

注入延迟：ChaosBlade 通过底层的 tc netem 让 CoreDNS 的响应延迟了 200ms。
业务超时：业务代码（Go net/http 或某些缺乏连接池管理的短连接客户端）设置的 DNS 查询超时可能极短（例如 100ms）。
疯狂重试：因为请求 DNS 超时，业务线程/协程被唤醒，立即发起下一次 DNS 解析。关键点来了：每次重试，客户端都会申请一个新的临时端口（Ephemeral Port）作为 UDP 源端口。
表项爆炸：由于源端口改变，Netfilter 将其视为一条全新的“连接”。旧的 DNS 请求由于没收到回包（还在 tc 的队列里排队），其在 conntrack 表中的 UNREPLIED 记录将死死挂住 30秒 才会过期回收。

算一笔账：假设单节点有 5000 QPS 的请求，由于 DNS 延迟，导致业务每秒产生 3 次重试。每秒新增 UDP conntrack 数 = 5000 * 3 = 15000。经过 30 秒的积累，15000 * 30 = 450,000 条记录。这就轻而易举地击穿了默认的 nf_conntrack_max (262144)，最终导致宿主机网络瘫痪。

4. 混沌工程防御性设计与底层加固

发现原因后，解决问题并不难。但在混沌工程实践中，如何防止测试把系统“真搞挂”，才是考验架构师功底的地方。

1. 系统底层加固：收紧 UDP conntrack 超时

对于承载高并发微服务的宿主机，默认的 30s 容忍度过于宽泛。建议在 sysctl.conf 中激进地调低这个值，并适当抬高 max 上限。

# 修改 /etc/sysctl.d/99-kubernetes-cri.conf
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60

执行 sysctl -p /etc/sysctl.d/99-kubernetes-cri.conf 立即生效。

2. 根治方案：在 Netfilter 层面豁免 DNS 流量

既然 DNS 是典型的极短生命周期 RPC，且集群内部互信，完全可以直接跳过 conntrack 跟踪。利用 iptables 的 raw 表（优先级高于 conntrack）注入 NOTRACK 规则。

# 对发往 53 端口的 UDP 流量不进行状态跟踪
iptables -t raw -I PREROUTING -p udp --dport 53 -j NOTRACK
iptables -t raw -I OUTPUT -p udp --dport 53 -j NOTRACK
# 相应的回包也不跟踪
iptables -t raw -I PREROUTING -p udp --sport 53 -j NOTRACK
iptables -t raw -I OUTPUT -p udp --sport 53 -j NOTRACK

注：如果集群内使用了依赖于状态跟踪的复杂 NetworkPolicy，此操作可能引发冲突，需配合实际 CNI 插件（如 Calico/Cilium）的具体实现来权衡。

3. GameDay 的熔断设计：爆炸半径控制

混沌工程的第一原则是控制爆炸半径。我们在后续的演练体系中，强制引入了基于 Prometheus+Alertmanager+Webhook 的“自动停止机制”。

编写一个看门狗脚本或部署专门的 DaemonSet，高频采集节点的 /proc/sys/net/netfilter/nf_conntrack_count。当 (count / max) > 80% 时，触发最高级别告警，Webhook 直接调用 ChaosBlade API 强制销毁当前所有的混沌实验：

# Webhook 触发的急救脚本片段
blade status --type create | grep Success | awk '{print $4}' | xargs -I {} blade destroy {}

常见问题

Q1：为什么不直接使用 NodeLocal DNSCache 来解决这个问题？ NodeLocal DNSCache 确实能极大缓解跨节点的 DNS 压力和 conntrack 表争抢（它将 DNS 请求拦截在本地并复用 TCP）。但如果针对 NodeLocal DNSCache 自身所在节点进行注入，或者上游 CoreDNS 完全不可用导致本地缓存穿透，业务依旧会疯狂重试击穿本地的 UDP conntrack 表。底层参数调优依然是最后一道防线。

Q2：当节点已经 NotReady 且 SSH 无法连接时，如何快速恢复？ 如果物理机有 OOB（如 IPMI、iLO），登录后直接调高上限：echo 1048576 > /proc/sys/net/netfilter/nf_conntrack_max 即可瞬间恢复网络通信。若无 OOB 且节点已“僵死”，只能通过 IaaS 控制台硬重启实例，此时务必确认 StatefulSet 挂载的存储卷是否正常卸载，以防脑裂。

Q3：使用基于 eBPF 的故障注入（如 Chaos Mesh 的 BPF 模式）是否能避免此问题？ 不能完全避免。虽然 eBPF 可以在 Socket 层或 TC 层更高效地丢包/延迟，避开部分 Netfilter 链的处理开销。但应用层（如 Go 的 HTTP Client）感知不到底层是被 eBPF 拦截还是真实网络延迟，它依然会发起重试。只要这些重试的 UDP 数据包依然经过宿主机的 Netfilter 协议栈，nf_conntrack 就会尽职尽责地去记录它们，最终依然会导致表满。

高并发网关常遇 nf_conntrack: table full 导致 SYN 丢包。盲目调大 nf_conntrack_max 只会加剧内核自旋锁争用与内存开销。根本解法是排查 SNAT 端口耗尽，并从 iptables 彻底迁移至 nftables，利用 Flowtable 机制开启流量卸载（Offload），让 ESTABLISHED 状态报文旁路跳过 Netfilter 核心链，实测可降低 40% 的 sys CPU 并彻底消除连接跟踪瓶颈。

案发现场：诡异的 99 线毛刺与超时

排查过程中，某承载了上万并发连接的 K8s Egress NAT 网关节点（Kernel 5.15.0）频繁出现请求超时，监控大盘显示 TCP 99线延迟出现规律性毛刺，Load Average 中的 sys CPU 间歇性飙升到 80% 以上。

直接上机器看内核日志：

$ dmesg -T | tail -n 20 | grep conntrack
[Thu Oct 26 14:12:33 2023] nf_conntrack: nf_conntrack: table full, dropping packet
[Thu Oct 26 14:12:33 2023] nf_conntrack: nf_conntrack: table full, dropping packet

经典的连接跟踪表爆满导致丢包。看一下当前连接数与上限：

$ sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count = 262144
net.netfilter.nf_conntrack_max = 262144

为什么盲目调大 nf_conntrack_max 是一剂毒药？

遇到 table full，很多人的第一反应是无脑加大 nf_conntrack_max。在低并发场景下这确实管用，但在高吞吐 NAT 网关上，这是一剂毒药。

nf_conntrack 是基于哈希表实现的。它的核心数据结构由 Hash buckets（桶）和链表组成。当你只调大 nf_conntrack_max 而不调整 nf_conntrack_buckets 时，每个 Hash bucket 下挂载的链表会变得极长。内核在进行包过滤或 NAT 时，需要遍历链表来匹配五元组。链表越长，查询的开销越大；加上 Hash bucket 的自旋锁（spinlock）争用，在多核高 PPS（Packet Per Second）场景下，CPU 会被 __nf_conntrack_find_get 等函数吃干抹净（表现为软中断 si 和内核态 sy CPU 极高）。

正确的临时缓解姿势必须是联动调整（保持桶大小为最大连接数的 1/4）：

# 1. 调大 Hash 桶大小（立即生效，不可通过 sysctl 修改）
$ echo 262144 > /sys/module/nf_conntrack/parameters/hashsize
# 2. 调大最大连接数
$ sysctl -w net.netfilter.nf_conntrack_max=1048576
# 3. 缩短 TIME_WAIT 和 ESTABLISHED 状态的超时时间，加速条目回收
$ sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=300
$ sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30

但这只是治标。抓包发现，该节点作为 SNAT 网关，真实存在的活跃连接并没有达到 26 万，导致表满的真凶是 SNAT 端口耗尽引发的僵尸连接积压。由于 iptables 的 MASQUERADE 规则，多个内网 Pod 访问外部同一个目标 IP:Port 时，由于源端口池（默认 1024-65535）被快速消耗殆尽，新的 SYN 包在进行 NAT 转换时无法分配到 free tuple，导致连接状态卡死并在 conntrack 表中滞留。

iptables 时代的穷途末路与 nftables 破局

只要你还在用 iptables，每一个数据包都要不可避免地穿透 PREROUTING -> FORWARD -> POSTROUTING 整条链。即使是已经建立连接（ESTABLISHED）的报文，也要每次去走一遍 Rule 解析和 Conntrack 状态机。

Kernel 4.16+ 引入了 nftables 的杀手锏功能：Flowtable (Fast-path Offload)。它的底层原理极其优雅：对于已经建立连接的 TCP/UDP 流量，Flowtable 会在网卡的 ingress hook 点（非常靠前的位置）直接进行路由转发和 NAT 替换，完全绕过传统的 Netfilter 过滤链和 Conntrack 查询。

实战：将 iptables NAT 迁移至 nftables Flowtable

不要再用 iptables-nft 这种套壳工具了，直接写原生的 nftables 配置。以下是我们在网关节点上的落地配置，实现内网到外网的 SNAT 并开启 Flowtable 硬件/软件卸载。

清除老旧规则：

$ iptables -F && iptables -t nat -F
$ systemctl stop iptables

编写 /etc/nftables.conf：

flush ruleset

table inet filter {
    # 定义 Flowtable 开启卸载
    flowtable f {
        # 挂载在非常靠前的 ingress 钩子，优先级 0
        hook ingress priority 0;
        # 绑定内外网网卡（根据实际情况修改）
        devices = { eth0, eth1 };
    }

    chain forward {
        type filter hook forward priority 0; policy drop;

        # 核心逻辑：允许 ESTABLISHED 流量，并将新流量加入 flowtable 'f'
        ip protocol { tcp, udp } flow add @f

        # 允许内网 (10.0.0.0/8) 到外网的初始包通过
        iifname "eth0" oifname "eth1" ip saddr 10.0.0.0/8 accept

        # 允许已建立连接的回包
        ct state established,related accept
    }
}

table ip nat {
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        # 传统 SNAT/Masquerade，只对首包生效
        oifname "eth1" ip saddr 10.0.0.0/8 masquerade random
    }
}

应用配置并验证：

$ nft -f /etc/nftables.conf
$ nft list ruleset

注意：masquerade random 的加入是为了缓解 SNAT 端口分配的哈希碰撞冲突，配合 Flowtable 能最大程度压榨网关性能。

性能表现对比

迁移至 nftables Flowtable 后，使用 perf top 观察内核函数调用：

迁移前：ipt_do_table 和 nf_conntrack_in 长年霸占 Top 3，软中断消耗极大。
迁移后：由于首包建立连接后，后续几十个甚至成百上千个数据包直接从网卡 ingress 进入 nft_flow_offload_eval 后被路由发出，ipt_do_table 直接消失，sys CPU 占用率暴降 40% 以上，dmesg 中再无 table full 报错。

常见问题 (FAQ)

Q1：为什么我明明清空了 iptables，用 iptables -L 还能看到一些莫名其妙的规则？ 因为较新的 OS（如 Debian 11+, RHEL 8+）默认将 iptables 软链接到了 iptables-nft。这是兼容层，你在 iptables 敲的命令，其实被转换成了 nftables 的内置表。要查看纯正的 iptables 规则，请使用 iptables-legacy -L。在系统层面彻底向 nftables 演进时，强烈建议干掉所有 legacy 和兼容层，统一用 nft 命令行管理。

Q2：开启 nftables Flowtable 之后，为什么 tcpdump 抓不到部分数据包了？ 这是预期行为。Flowtable 提供了 Software Offload 和 Hardware Offload (NIC HW offload)。如果是 Hardware offload（需要网卡驱动支持 tc 卸载），数据包在物理网卡层面就被转发了，根本不会进入内核网络栈，挂在 AF_PACKET 上的 tcpdump 自然抓不到。即使是 Software offload，由于绕过了常规的 Netfilter RX 路径，抓包结果也会呈现“只看到 SYN 包，看不到后续数据流”的现象。排查网络问题时，需要临时禁用 flowtable 规则。

Q3：在 K8s 中使用 IPVS 模式的 kube-proxy，也会受 nf_conntrack 限制吗？ 会。虽然 IPVS 维护了自己的连接管理哈希表，但它仍然深度依赖 Netfilter 框架做底层的包拦截和 NAT 协调（尤其是 nf_conntrack）。K8s 场景下大量短连接（如探针、微服务间 RPC）极易打满 conntrack。除文中提到的调优手段外，建议通过 kube-proxy 启动参数 --conntrack-max-per-core 来合理规划容量，而非手动修改 sysctl，防止被 Kubelet 重置。

标签： nf_conntrack

深入 ChaosBlade 陷阱排查：DNS 延迟注入引发的 UDP conntrack 溢出与节点雪崩实战