nfqueue 实现可疑报文应用层分析的核心是“标记+转发+处理”闭环：先在 raw 表 prerouting 链用 iptables 匹配可疑 tcp 报文并跳转 nfqueue；再通过 --queue-bypass、增大 queue maxlen、限制 copy_range 等参数保障队列可控不堆积；最后由用户程序及时返回 accept/drop 等 verdict，避免报文滞留。
用 iptables 的 NFQUEUE 将可疑报文送至应用层分析，核心是“标记 + 转发 + 处理”三步闭环。关键不在规则多复杂，而在于队列行为可控、报文不堆积、判决不遗漏。
明确可疑报文的匹配条件
先定义什么是“可疑”。常见策略包括：
- TCP SYN 包异常频次（如每秒超 100 个）——可配合 recent 模块限速识别
- 源 IP 属于已知威胁情报段（用 ipset 加载黑名单）
- 目标端口非常规（如向 2375 端口发非 Docker 协议数据）
- 报文长度过小（如 TCP payload
推荐使用 raw 表的 PREROUTING 链，避免受连接跟踪干扰：
iptables -t raw -I PREROUTING -p tcp --dport 8080 -m set --match-set suspicious_src src -j NFQUEUE --queue-num 0 --queue-bypass配置 NFQUEUE 行为参数
内核队列默认容量仅 1024，无响应会阻塞整条链路。必须显式控制：
- --queue-bypass：确保用户程序未启动时，报文不被静默丢弃，而是放行（避免业务中断）
- 应用层监听时设置 queue maxlen（如 5000），防止溢出丢包
- 限制复制大小：copy_range 40（仅三层+四层头），减少内存拷贝开销
- 内核 3.6+ 可加 --fail-open，队列满时自动放行而非丢包
应用层处理的关键逻辑
用户程序收到报文后，必须在合理时间内返回 verdict，否则该报文将长期滞留内核队列：
- ACCEPT：放行，报文继续走后续 iptables 链
- DROP：丢弃，不通知发送方
- REPEAT：重入队列（慎用，易循环）
- 高 16 位写入队列号（如 0x00010000 表示队列 1），低 16 位为动作码
注意：未响应的报文不会超时自动释放，必须由程序主动 verdict 或进程退出触发内核清理。
验证与排障要点
上线前务必确认三项状态：
- 检查队列是否注册成功：cat /proc/net/netfilter/nfnetlink_queue，看对应 queue-num 的 use 是否 > 0
- 查看丢包统计：qthreshold 和 dropped 字段，若 dropped 持续增长，说明应用处理慢或崩溃
- 用 tcpdump -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn' 对比原始流量与队列接收量，确认无漏匹配
