nftables不执行ip头校验和、ttl重算等协议完整性验证，仅基于内核已初筛的合法报文元数据做逻辑一致性判断，如frag-off对齐、ttl/hoplimit合理性、df标志与长度匹配、ct state与tcp标志协同校验、icmpv6类型约束及socket元数据可信度强化。
nftables 本身不执行网络层协议完整性验证，比如 IP 头校验和重算、TTL 合理性检查、分片偏移合法性、IP 选项字段结构解析等。它依赖内核网络栈在进入 Netfilter 钩子前已完成基础校验：无效 IP 包（如校验和错误、版本非 4/6、总长小于 20 字节）通常在 ip_rcv 或 ip6_rcv 阶段已被静默丢弃，根本不会到达 NF_INET_PRE_ROUTING 钩子。
真正可由 nftables 实施的“协议完整性策略”，是基于已通过内核初筛的合法报文元数据，做逻辑一致性与行为合理性判断。这类策略不验证字节级字段正确性，而是防范常见滥用模式和协议误用场景。
聚焦 IP 层字段组合的合理性约束
IP 协议头中多个字段存在语义依赖关系，nftables 可结合 ip 和 ip6 表达式进行交叉校验：
ip frag-off（IPv4 分片偏移）必须为 8 字节对齐值：ip frag-off & 0x7 != 0 drop
（若偏移非 8 的倍数，说明违反 RFC 791，属构造异常包）IPv4
ip ttl过低（如 ≤2）且非本地探测流量，可能指向 traceroute 滥用或扫描行为：ip ttlIPv6
ip6 hoplimit异常小（如 ≤1），同时目标非链路本地地址，大概率是伪造或探测：ip6 hoplimit禁止 IPv4 无分片但设置了 DF 标志（
ip dfrag 0）却携带超大载荷（>1500 字节），这违反路径 MTU 探测逻辑：ip dfrag 0 ip length > 1500 drop
利用连接跟踪状态反推协议行为异常
即使单个 IP 包语法合法，其在网络流中的角色也可能违背协议设计意图：
允许
ct state new的包必须携带tcp flags & (syn|rst|fin) == syn（TCP）或udp length > 0（UDP），否则视为协议混淆：meta l4proto tcp ct state new @th,13,1 & 0x02 == 0x00 drop
（检查 TCP 标志第 2 位 SYN 是否置位）对 ICMPv6，只允许特定类型出现在特定上下文中：
ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert } acceptip6 nexthdr icmpv6 icmpv6 type != { echo-request, echo-reply, nd-neighbor-solicit, nd-neighbor-advert } drop
结合 socket 元数据强化源可信度判断
协议完整性不仅看报文本身，也看其发起者是否符合预期身份：
拒绝非特权进程（UID ≠ 0）发出的
ip protocol 4（IP-in-IP）封装包：meta skuid != 0 ip protocol 4 drop禁止普通用户进程使用
ip protocol 47（GRE）或ip protocol 50（ESP）：meta skuid != 0 ip protocol { 47, 50 } drop对隧道端点地址做白名单约束，防止任意 IP 封装：
ip protocol 4 ip saddr != { 192.0.2.10, 2001:db8::a } drop
避免过度依赖 payload 匹配做完整性验证
虽然 nftables 支持 @nh,offset,len 提取 IP 头字段（如 @nh,0,1 读版本+IHL），但该方式有硬限制：
- 仅适用于首片（non-fragmented 或 first fragment）
- 不支持跨片重组后的逻辑校验
- 偏移计算需手动换算，易出错
因此，真正健壮的完整性策略应以 ip/ip6 内建字段 + ct state + meta skuid 三者联动为主，辅以轻量级 eBPF 做首包深度解析（如验证 IPv4 options 长度是否匹配 IHL 字段），而非在 nftables 规则中堆砌复杂偏移表达式。
