iptables -t raw 是唯一能在连接跟踪（conntrack）初始化前介入的表，其 prerouting 和 output 链可早于状态跟踪触发 -j notrack，从而避免 conntrack 表溢出与性能问题；filter/nat 表生效时状态已建立，notrack 无效。
iptables -t raw 是唯一能绕过连接跟踪（conntrack）的表，适用于高并发、短连接或扫描类流量场景。直接在 raw 表中用 -j NOTRACK 标记数据包，可避免 conntrack 表溢出、CPU 占用飙升、新建连接延迟激增等问题。
为什么必须用 -t raw 而不是 filter 或 nat
conntrack 在数据包进入协议栈后、路由决策前就被触发，而 raw 表的 PREROUTING 和 OUTPUT 链是唯一能在 conntrack 初始化前介入的位置。其他表（如 filter/INPUT）生效时，conntrack 已完成状态创建，NOTRACK 失效。
-
filter表的INPUT链：conntrack 状态已建立，-m conntrack --ctstate INVALID只能丢弃，无法跳过跟踪 -
nat表的PREROUTING：DNAT 会强制触发 conntrack，哪怕你之前在filter里写了ACCEPT - 只有
raw表的PREROUTING链 +-j NOTRACK才真正“早于”连接跟踪逻辑
-j NOTRACK 的匹配条件和典型用法
它不改变数据包内容，只打上 UNTRACKED 标记，后续所有表（包括 filter）都会跳过该连接的状态检查。常用于以下三类流量：
- ICMP 扫描包（如
ping洪水）：iptables -t raw -A PREROUTING -p icmp -j NOTRACK - UDP 短连接洪泛（如 DNS 反射攻击源）：
iptables -t raw -A PREROUTING -p udp --dport 53 -j NOTRACK - 已知恶意 IP 段的全部入向流量：
iptables -t raw -A PREROUTING -s 192.0.2.0/24 -j NOTRACK
注意：NOTRACK 后仍需在 filter 表中显式 DROP 或 ACCEPT，否则默认策略会接管——它只是跳过状态跟踪，不等于放行。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
容易踩的坑：NOTRACK 不等于 DROP，也不兼容 DNAT/SNAT
一旦标记为 UNTRACKED，该数据包将彻底脱离 netfilter 的状态机，带来几个硬性限制：
-
nat表规则对NOTRACK流量完全无效：不能做 DNAT、SNAT、端口转发 -
filter表中依赖-m conntrack的规则（如--ctstate ESTABLISHED）对其不生效 - 若你同时用了
NOTRACK和iptables -t nat -A PREROUTING -d $VIP -j DNAT，后者会被静默忽略 -
NOTRACK无法撤销：标记后不可恢复为 tracked，只能靠规则顺序控制作用范围
性能影响与部署建议
raw 表规则本身开销极低，但滥用会导致运维盲区：比如你对整个 /24 段 NOTRACK，后续就无法用 conntrack -L | grep 查看其连接状态，监控和排障变困难。
- 优先按协议+端口窄匹配，避免
-p tcp -j NOTRACK这种宽泛写法 - 配合
-m limit控制日志量：iptables -t raw -A PREROUTING -p icmp -m limit --limit 1/sec -j LOG --log-prefix "RAW-ICMP: " - 生产环境上线前，务必用
conntrack -S观察entries和max值变化，确认 conntrack 表压力下降 -
NOTRACK规则必须放在raw表最前面（-I PREROUTING 1），否则可能被其他规则提前处理掉
真正关键的不是加多少条 NOTRACK，而是确保它只覆盖你明确不想进 conntrack 的那部分流量——漏掉会压垮连接表，多加会失去状态可见性。
