NOTRACK必须在raw表PREROUTING链配置，因其是唯一能在连接跟踪初始化前介入的表，可真正绕过nf_conntrack；其他表中操作无法避免资源消耗，且需精准匹配并配合filter表显式控制。
配置 NOTRACK 规则不是为了“放行攻击”，而是让特定流量彻底绕过连接跟踪（nf_conntrack），防止内核资源被海量伪造包耗尽。关键在于：必须用 raw 表、必须在 PREROUTING 链、必须 精准匹配，之后还得靠 filter 表显式控制。
为什么只能在 raw 表设 NOTRACK
raw 表是 iptables 中唯一在连接跟踪初始化前介入的表，位于数据包进入内核网络栈的最前端。只有在这里执行 -j NOTRACK，才能真正阻止包写入 conntrack 哈希表。在 filter、nat 或 mangle 表里加 NOTRACK 完全无效——包早已被分配连接条目、占用内存、触发哈希冲突，再丢弃也晚了。
哪些流量适合 NOTRACK 豁免
只对明确无状态、来源可信、且不依赖 NAT 或连接状态放行的流量启用。常见安全场景包括：
- 本地回环通信：
iptables -t raw -A PREROUTING -i lo -j NOTRACK - 已知可信监控流量（如 Zabbix Agent）：
iptables -t raw -A PREROUTING -p tcp --dport 10050 -s 10.0.10.0/24 -j NOTRACK - DNS 响应方向（仅限 sport 53 的 UDP 包）：
iptables -t raw -A PREROUTING -p udp --sport 53 -m state --state ESTABLISHED -j NOTRACK - 高吞吐无状态服务入口（如 NTP 应答）：
iptables -t raw -A PREROUTING -p udp --dport 123 -s 192.0.2.0/24 -j NOTRACK
禁止对公网入向 TCP 新连接、未过滤的 UDP Flood 目标端口、或需 DNAT/SNAT 的流量启用 NOTRACK。
NOTRACK 后必须搭配 filter 显式处理
一旦跳过 conntrack，包就不再有 ESTABLISHED、INVALID 等状态，所有基于 -m conntrack 或 -m state 的规则对其失效。必须改用无状态方式控制：
- 用
-m limit替代状态限速：iptables -A INPUT -p tcp --dport 80 -m limit --limit 50/sec --limit-burst 100 -j ACCEPT - 用
-m hashlimit控制单 IP 速率：iptables -A INPUT -p udp --dport 53 -m hashlimit --hashlimit-above 10/sec --hashlimit-name dns_flood -j DROP - 对已豁免的攻击源直接 DROP：
iptables -A INPUT -p udp --dport 53 -s 203.0.113.0/24 -j DROP
典型错误与规避要点
常见误操作会适得其反：
- 写成
iptables -A INPUT -p udp --dport 53 -j NOTRACK→ 在 filter 表无效，conntrack 已触发 - 宽泛匹配：
iptables -t raw -A PREROUTING -p udp -j NOTRACK→ 所有 UDP（含 DNS 查询响应）失管，服务中断 - 只加 NOTRACK 不加 DROP/ACCEPT → 包按 INPUT 默认策略兜底，极易误放恶意流量
- 对需要 SNAT 的流量启用 NOTRACK → NAT 失效，回程包无法正确转发
