nftables本身不解析tcp报文或校验三次握手合法性，仅依赖conntrack提供l4连接状态标签；ct state established/related/invalid/new等状态由conntrack预计算，nftables仅匹配这些标记实现快速过滤与策略执行。
nftables 本身不解析 TCP 报文字段，也不校验三次握手的合法性（比如 SYN 后是否收到 SYN-ACK、ACK 是否合法），它依赖内核 conntrack 子系统提供连接状态标签。真正的“状态检测”发生在连接跟踪层，nftables 只是读取并匹配这些预计算好的状态标记。
conntrack 提供的 L4 状态是核心依据
conntrack 在连接生命周期中为每个数据包打上状态标签，nftables 直接使用这些标签做快速决策：
- ct state established：表示该连接已完成三次握手（对 TCP）或已有双向通信（对 UDP）。这是最常用、最可靠的放行条件，能自然过滤掉未完成握手的 SYN 包。
- ct state related：匹配由主连接触发的辅助流，例如 FTP 数据连接、ICMP 错误报文、DNS 响应等。它依赖 conntrack 的协议辅助模块（如 nf_conntrack_ftp）识别关联关系。
- ct state invalid：表示该包无法归属到任何已知连接，通常因校验失败、序列号异常、无对应连接条目等。建议默认丢弃，是防御扫描和畸形包的第一道防线。
- ct state new：仅匹配连接的第一个包（通常是 TCP SYN 或 UDP 首包）。但需谨慎使用——它不能区分合法服务请求和恶意扫描，常配合源 IP 限速或白名单使用。
为什么不能靠 nftables 单独实现“握手合法性”过滤
TCP 三次握手的语义规则（如 SYN 必须无 ACK、SYN-ACK 必须同时置位、ACK 序号必须等于 SYN 序号+1）属于协议状态机逻辑，需逐包解析 TCP 头部字段并维护上下文。nftables 规则引擎不支持这种有状态的字段组合判断和跨包关联。这类深度检测必须交由：
- eBPF 程序在内核态实时解析并标记可疑握手行为；
- 用户态守护进程（如 suricata、custom TCP monitor）结合 libpcap 分析流量，再通过 netlink 或 socket 向 nftables 注入动态规则或标记。
实际策略中如何合理利用 ct state
典型安全策略不是“只允许三次握手完成后的包”，而是分层控制：
- 入口链（input）默认 drop，显式放行 ct state established,related；
- 对需要对外提供服务的端口（如 22、80、443），额外允许 tcp dport {22,80,443} ct state new，但应搭配速率限制（limit rate 5/minute）防 SYN 洪水；
- 显式丢弃 ct state invalid，避免异常包绕过规则；
- 若部署了 DNAT，可结合 ct status dnat 区分外网进来的连接与内网主动发起的连接，便于做不同策略。
排查握手失败时，别只盯 nftables
当客户端卡在 SYN_SENT，常见原因不在 nftables 规则本身，而在更底层：
- 服务端未监听目标端口（ss -tlnp | grep :端口）；
- SYN 包被防火墙静默丢弃（检查 nft list ruleset 中 input 链是否意外 DROP 了 new 状态）；
- 服务端 SYN 队列满（ss -s | grep synrecv），此时 conntrack 可能根本未创建条目，nftables 也就无状态可查；
- 云平台安全组或中间设备拦截，SYN 根本未到达服务器网卡。
