如何使用Nftables的Ct State指令平滑接管处于半连接状态的流量-linux运维-PHP中文网

nftables 的 ct state 无法直接接管 syn_recv 半连接，因其未进入 conntrack 表；平滑处理需结合 syn cookie、ct state invalid/new 识别与限速、established/related 快速放行等协同策略。

如何使用nftables的ct state指令平滑接管处于半连接状态的流量

nftables 的 ct state 本身不能直接接管或“平滑接管”半连接状态（SYN_RECV）的流量，因为半连接（即三次握手未完成的连接）在内核中不被视为 ESTABLISHED，也不进入 conntrack 表的正常生命周期——它只存在于 TCP 半连接队列（syn queue），尚未被连接跟踪模块（nf_conntrack）正式记录。

真正能“平滑处理”这类流量的，是配合连接跟踪状态判断 + 主动防御策略 + 队列协同参数调优，而非单靠 ct state 指令接管。以下是关键逻辑和实操要点：

ct state 能识别的状态有限，半连接不在其中

nftables 中 ct state 可匹配的值只有：

invalid（无法归类或损坏的包）
new（首次 SYN 包，且成功进入 conntrack）
established（已有双向通信，如 SYN-ACK 后的 ACK）
related（如 FTP 数据连接、ICMP 错误关联等）

⚠️ 注意：一个纯 SYN 包若因 net.ipv4.tcp_syncookies=1 或 tcp_max_syn_backlog 溢出被丢弃，它根本不会触发 conntrack 创建，自然也不会有 ct state new 可匹配。所以你无法用 ct state new 精确捕获所有“正在尝试建立”的半开连接。

真正可用的半连接协同策略

启用 SYN Cookie 防御（内核级兜底）
```
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
```
这让服务端在队列满时用加密序列号应答 SYN，避免 TCB 占用，使合法客户端仍可完成握手——这是“平滑”的底层基础。
用 ct state invalid + TCP 标志组合识别异常半开行为
恶意扫描器常发 SYN 后不响应 SYN-ACK，或伪造源 IP 导致大量 ct state invalid 包：
```
nft add rule inet filter input tcp flags & (fin | syn | rst | ack) == syn ct state invalid counter name "syn-invalid" drop
```
这类包虽未建连，但已触发 conntrack 尝试跟踪并失败，可作为攻击信号。
对高频 ct state new 源做速率限制（保护半连接队列不被耗尽）
```
nft add rule inet filter input ct state new limit rate 5/second burst 20 packets counter accept
nft add rule inet filter input ct state new counter drop
```
防止攻击者用海量 SYN 填满 tcp_max_syn_backlog，间接保障真实用户 SYN 能入队。
允许 ct state established,related 无条件通行（保障已建连流量不中断）
```
nft add rule inet filter input ct state established,related counter accept
```
这是“平滑接管”的核心体现：一旦连接真正建立（哪怕之前经历过 SYN 重传、cookie 验证），后续所有数据包都靠此规则零延迟放行，无需再走复杂匹配。