自己动手写防火墙听起来像极了极客的保留节目但当你真正拆开来看它的核心就是一件没那么神秘的事在数据包流经内核协议栈时插入属于自己的裁决逻辑。这篇文章是自研SPIStateful Packet Inspection状态检测防火墙系列的第二篇重点落在HOOK函数的实现上。上一篇我们把整体架构、模块框架和基本策略说清楚了这一篇就直接奔着协议栈里最关键的钩子机制去把真正能跑起来的状态防火墙核心写出来。SPI HOOK函数能做什么简单讲它在数据包进入协议栈的各个节点上“过目”每一个包并且不只看单个包本身而是结合这条连接的历史状态来决定放行、丢弃还是转发。简单说它是一个“带记忆的守门人”。它能解决的问题也很直接防端口扫描、防半开连接试探、防止那些伪造 RST/ACK 包绕过普通包过滤以及为后续更复杂的访问控制打底。适合谁适合想弄懂Linux协议栈、对Netfilter机制好奇、或者打算从零实现一套安全访问控制的开发者。就算你只是想读懂成熟防火墙的实现思路顺着这套理解去拆解也会顺手很多。1. 先理解SPIHOOK函数到底在解决什么问题很多刚接触防火墙的同学会把“HOOK函数”理解成“写一个回调函数挂上去”这没错但停留在“挂在哪、返回啥”是不够的。要搞清楚SPI的HOOK函数为什么是这种设计得先回答一个问题传统包过滤到底漏在哪。1.1 为什么传统包过滤不够用传统包过滤无论是基于iptables的规则还是所谓的ACL本质上是“无记忆”的。一个包来了它就查一遍规则表只根据这个包的IP头、传输层端口、协议类型等独立信息给出放行或丢弃的结论处理完就不管了。这种模式的漏洞很明显。以TCP为例一个完整连接是由SYN、SYN-ACK、ACK、数据包、FIN等多个包组成的。攻击者完全可以不经过三次握手直接构造一个合法的ACK包发进来。从单包来看五元组合法端口也对传统过滤规则会直接放行。但从连接语义来看这根本不属于任何已建立的会话是不折不扣的伪造流量。普通规则表识别不了这种“逻辑上非法”的包因为没有状态可以参考。SPI要补的正是这个缺口。它的思路是维护一张连接状态表记录每个经过的连接从建立到关闭的完整状态。每个包到达时先查这条连接是否存在于状态表中再看它带来的状态迁移是否合理。一个凭空跳出来的ACK包在状态表里找不到对应的连接自然就无法通过“已建立”检验直接被丢弃。拒绝的不仅是“包不合法”而是“这个包出现的时机和背景都不对”。1.2 HOOK函数在Netfilter里的真实位置在Linux系统中Netfilter是内核网络协议栈里的一个框架它把数据包在协议栈中的流动路径固定下来并向开发者暴露了若干“挂钩点”。这些挂载点分布在PRE_ROUTING、LOCAL_IN、FORWARD、LOCAL_OUT、POST_ROUTING等位置覆盖了收包、本地投递、转发和发包的全过程。HOOK函数就是挂在这些点上的回调函数。一个数据包走到某个钩子点时内核就会调用挂载在这里的回调函数把struct sk_buff指针和钩子状态传进来让函数给出裁决结果。Netfilter定义了宏让你可以返回NF_ACCEPT继续后续处理、NF_DROP静默丢弃、NF_STOLEN接管数据包、NF_QUEUE把包交给用户态程序处理等。一般我们会返回NF_ACCEPT或NF_DROP。你可以把整个协议栈想象成一条流水线数据包是流水线上的工件HOOK函数是某个质检工位。工件必须在工位上停下来接受抽检质检员决定它继续往下走、还是直接扔进废品箱。有一个常见误解是“我还用HOOK函数干嘛直接用iptables不就行了”。实际上iptables自身就是构建在Netfilter机制之上的规则引擎它把Netfilter的那几个钩子点封装成规则表。你要自研一套防火墙自然不能只停留在“写iptables规则”而是要回到更底层的HOOK函数本身把连接跟踪、状态判定、策略决策这些逻辑全都掌握在自己手里。这样做的收益是你可以实现比iptables灵活得多的语义比如结合自定义协议字段、整合多个hook点的上下文做复杂判定也不用承担规则链膨胀带来的性能损失。1.3 为什么选内核HOOK而不是应用层方案也经常有人问为什么不用用户态代理或者网络服务的方式做应用层代理需要把流量从内核态反复搬到用户态去解析再搬回来开销天然高而且一旦遇到非标准协议就非常被动只能依赖代理自己能不能识别。而工作在内核态HOOK函数里的SPI检测整个过程没有上下文切换也没有内核态到用户态的拷贝数据包始终在协议栈内部性能优势非常明显。更重要的是SPI关心的是“连接语义”而连接语义本来就出现在网络层和传输层。在网络层做状态检测可以在包到达上层应用之前就把绝大多数非法流量过滤掉既能保护内核进程也能减少应用层的负载。对于个人开发的防御型防火墙来说这个路径是最合理的选择成本可控效果也足够直观。2. 动手前的方案设计连接表、状态机与钩子点编程里有一句话叫“先画状态图再写代码”这句话在写状态防火墙时尤其适用。你连连接表怎么组织、状态怎么迁移都没想清楚就急着写HOOK函数写出来的多半是各种if-else堆起来的死胡同。所以先把设计蓝图落在纸面上。2.1 钩子点应该选在哪些位置Netfilter在IPv4下提供了5个主要钩子点。要做一个适用的状态防火墙不需要全部铺满。从最简单也最实用的组合开始PRE_ROUTING和LOCAL_OUT。PRE_ROUTING是所有外部进入本机的数据包经过的第一个位置也是唯一一个在路由决策前就能检查入站包的地方。把检测放在这里好处是可以在包进入本机或转发路径之前就完成连接建立和状态判定把异常包拦在最前面。LOCAL_OUT则覆盖本机主动发出的流量。很多人第一个版本只注册了PRE_ROUTING结果回包总是被丢原因恰恰是本机外出时没有建立连接记录外部回包回来时状态表里根本没有对应条目。所以你必须在LOCAL_OUT也挂一个HOOK函数把外发包的状态记录补上。对FORWARD钩子的处理取决于拓扑。如果这台防火墙只保护本机FORWARD可以暂时不挂如果有内网转发需求建议在PRE_ROUTING判断完之后让转发包继续往前走到FORWARD节点再挂一个只做转发策略的HOOK函数。谨慎起见第一版先把PRE_ROUTING和LOCAL_OUT跑通FORWARD留给后续扩展。2.2 连接表的数据结构怎么设计才有扩展性既然要“带记忆”核心数据结构就是连接表。我用的一版定义大致长这样#define SP_CONN_HASH_BITS 16 #define SP_CONN_HASH_SIZE (1 SP_CONN_HASH_BITS) enum sp_conn_state { SP_TCPS_SYN_SENT, /* 发出或收到SYN */ SP_TCPS_ESTABLISHED, /* 握手完成 */ SP_TCPS_FIN_WAIT, /* 已发出FIN */ SP_TCPS_CLOSE_WAIT, /* 收到对端FIN */ SP_TCPS_CLOSED, /* 连接关闭 */ }; struct sp_conn { struct hlist_node node; /* 挂到正向哈希槽 */ struct hlist_node rnode; /* 挂到反向哈希槽 */ __be32 saddr, daddr; /* 五元组中的IP */ __be16 sport, dport; /* 五元组中的端口 */ u8 protocol; /* IPPROTO_TCP/UDP/ICMP */ enum sp_conn_state state; /* 当前状态 */ unsigned long last_seen; /* 最后活动时间戳 */ struct rcu_head rcu; /* RCU回收 */ atomic64_t pkt_in, pkt_out; /* 统计信息可选 */ };哈希键我用的是五元组 方向标志的对称做法。正常思路是存方向A→B然后再记录B→A的反向记录。但如果每条连接在表里存两条记录状态同步就麻烦更新状态时还得找到另一条。更好的方案是一个连接只存一条状态但把连接对象同时挂到两个哈希槽里正向哈希槽用saddr,sport,daddr,dport,proto做键反向哈希槽用反向五元组做键。这样无论包从哪个方向来查哈希都只命中一次而且状态始终是同一份。哈希算法直接借用内核的jhash初始化时给一个随机种子。为什么强调随机种子因为如果哈希种子固定攻击者可以故意构造五元组让所有包都落在同一个哈希桶里连接表就退化成链表查询复杂度变成O(n)这是很经典的哈希碰撞拒绝服务。随机化种子之后哈希桶分布不可预测攻击成本大大增加。2.3 状态机的收敛与简化策略TCP的状态机非常庞大完整实现包含CLOSED、LISTEN、SYN_SENT、SYN_RECV、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、CLOSE_WAIT、CLOSING、LAST_ACK、TIME_WAIT这11个状态。在内核模块里把这些状态全部原样复刻不是不行而是容易把自己绕晕。第一版我建议收敛成4个核心状态够用且不容易出错状态触发条件后续处理SYN_SENT发出SYN或收到SYN等待对端确认收到SYN-ACK且序列号合理迁移到ESTABLISHEDESTABLISHED握手完成双向数据可达常规数据包、ACK包全部放行FIN_WAIT本端发出FIN等待对端关闭收到对端FIN或ACK后迁移到CLOSEDCLOSED连接已关闭或超时表项即将被删除UDP没有连接概念但在SPI里仍然要维护“虚拟连接”。方法是第一次看到某个五元组的UDP包就创建一条状态记录之后一段时间内比如30秒五元组匹配的包都算已建立连接超过时间没有新包就回收。ICMP则可以只跟踪echo request / echo reply这类成对出现的类型防止无来源的ICMP响应混入。状态机的核心原则是严禁一个没握过手的包直接进入ESTABLISHED状态。很多实现第一次跑起来发现漏洞多半就是这里太宽松。2.4 超时回收机制不能少有连接表就必然要考虑过期清理。如果不清理攻击者只需不断发起新连接连接表就会无限增长最后要么内存耗尽要么哈希桶退化。我用的方法是启动一个delayed_work内核定时任务每隔固定周期比如10秒扫描一次哈希表把jiffies - last_seen超过阈值的表项摘除。这个扫描没有用锁遍历而是利用RCU延迟释放对数据通路的影响极小。超时阈值怎么设TCP连接可以放宽到120秒因为TCP本身有心跳一时半会儿没有数据不奇怪UDP和ICMP则建议30秒UDP没有维持连接机制30秒已经非常符合经验值。如果你的环境中长连接很多这个数值可以做成可配置项而不是硬编码。2.5 静态规则和状态检测的优先级实际部署时连接状态并不能解决一切问题。比如你本来就想封掉某个端口那么即使状态匹配也该拦截。所以完整的裁决逻辑应该分两级先查静态规则表比如“拒绝所有目的端口是135的包”、“允许特定来源IP访问22端口”静态规则没命中再查连接状态表如果状态合法就放行如果完全陌生则按默认策略决定是否创建新连接。默认策略很关键。建议初始配置为本地主动发出的包允许创建新连接外部发来的陌生包只有目标端口是白名单内才允许创建新连接否则丢弃。这样做可以防止外部扫描器用大量SYN包把连接表打爆。静态规则表不需要第一版做得很花哨先用一个简单的链表或者哈希表承接后续再升级成规则引擎。3. HOOK函数的实现细节与代码骨架设计落地之后写代码就有方向了。这一部分直接展示HOOK函数怎么注册、怎么写以及容易出错的地方。3.1 模块初始化与钩子注册核心是定义一个nf_hook_ops数组把函数指针、协议簇、钩子点和优先级填进去。我建议把优先级设成NF_IP_PRI_FIRST让自研逻辑尽量早执行这样即使后面还有iptables规则我们的判断已经先行一步。static unsigned int sp_fw_hookfn(void *priv, struct sk_buff *skb, const struct nf_hook_state *state); static struct nf_hook_ops sp_fw_ops[] { { .hook sp_fw_hookfn, .pf NFPROTO_IPV4, .hooknum NF_INET_PRE_ROUTING, .priority NF_IP_PRI_FIRST, }, { .hook sp_fw_hookfn, .pf NFPROTO_IPV4, .hooknum NF_INET_LOCAL_OUT, .priority NF_IP_PRI_FIRST, } }; static int __init sp_fw_init(void) { int ret; ret nf_register_net_hook(init_net, sp_fw_ops, ARRAY_SIZE(sp_fw_ops)); if (ret) { pr_err(sp_fw: failed to register hooks\n); return ret; } pr_info(sp_fw: hooks registered\n); return 0; } static void __exit sp_fw_exit(void) { nf_unregister_net_hook(init_net, sp_fw_ops, ARRAY_SIZE(sp_fw_ops)); pr_info(sp_fw: hooks unregistered\n); } module_init(sp_fw_init); module_exit(sp_fw_exit); MODULE_LICENSE(GPL);代码里用的nf_register_net_hook是较新内核版本的接口老内核可能还是nf_register_hook这一点在编译前需要确认自己的内核版本。注册失败时千万不要继续往下跑直接返回错误码给insmod避免留一个半初始化状态的内核模块。3.2 HOOK函数的主流程骨架HOOK函数是防火墙的核心每来一个包都会执行。函数内部的大致框架如下static unsigned int sp_fw_hookfn(void *priv, struct sk_buff *skb, const struct nf_hook_state *state) { struct iphdr *iph; struct tcphdr *tcph; struct sp_conn key, *conn; u32 hash, rhash; /* 模块可配置开关用于逃生 */ if (!sp_fw_enable) return NF_ACCEPT; /* 只处理IPv4其他协议直接放行 */ if (skb-protocol ! htons(ETH_P_IP)) return NF_ACCEPT; iph ip_hdr(skb); if (iph-version ! 4) return NF_ACCEPT; /* 按照协议分支处理 */ switch (iph-protocol) { case IPPROTO_TCP: tcph skb_header_pointer(skb, iph-ihl * 4, sizeof(*tcph), NULL); if (!tcph) return NF_DROP; if (tcph-doff * 4 sizeof(*tcph)) return NF_DROP; /* 填充 key */ key.protocol IPPROTO_TCP; key.saddr iph-saddr; key.daddr iph-daddr; key.sport tcph-source; key.dport tcph-dest; break; case IPPROTO_UDP: /* 类似填充 */ break; case IPPROTO_ICMP: /* 类似填充ICMP用 type/code 充当“端口” */ break; default: return NF_ACCEPT; } hash sp_conn_hash(key); rhash sp_conn_hash_reverse(key); /* 先查表命中则更新状态并放行 */ hlist_for_each_entry_rcu(conn, sp_conn_tbl[hash], node) { if (sp_conn_match(conn, key)) { sp_conn_update(conn, key); return NF_ACCEPT; } } hlist_for_each_entry_rcu(conn, sp_conn_tbl[rhash], rnode) { if (sp_conn_match(conn, key)) { sp_conn_update(conn, key); return NF_ACCEPT; } } /* 没匹配到尝试创建新连接 */ if (sp_conn_create(skb, key) 0) return NF_DROP; return NF_ACCEPT; }这里有几个要点必须强调。第一不要直接用tcp_hdr(skb)这类宏去访问头部。因为skb里的线性数据区域长度可能不够比如分片包或者头部被藏在非线性区的情况直接访问很容易触发内核崩溃。安全做法是用skb_header_pointer它会自动判断线性区域是否足够不够时通过skb_copy_bits安全拷贝到临时变量。我早期就吃过这个亏一个畸形包直接让整个机器panic。第二key只需要是栈上的临时变量不需要额外分配内存。修改连接表项时只需要用sp_conn_update做状态迁移和last_seen更新。第三返回NF_DROP时数据包已经被吃掉对应的上层连接可能感知到超时重传。所以在丢弃陌生包时要有日志但日志不能全打否则高流量场景下dmesg会被刷爆后面会再说。3.3 双向哈希匹配的实现技巧连接表里每个连接对象要有两个hlist_node一个挂正向哈希槽一个挂反向哈希槽。查询时先查正向再查反向两边都命中不了说明不是已有连接。这样设计还有一个好处更新状态时不用同时找两条记录。比如正向包来了直接命中正向哈希槽里的对象这个对象同时也在反向哈希槽里挂着所以反向包来的时候直接命中反向槽里的同一个对象状态是全局一致的。实现时要在创建连接时同时入两个槽释放时从两个槽里摘除。这里有一个并发注意点如果两个方向的数据包同时到达且在哈希表中都没找到现有记录此时要先对连接表加一个很短的自旋锁防止创建出两份相同五元组的记录。不能用互斥锁因为HOOK函数运行在中断上下文不能睡眠。3.4 IPv6的坑别只做了一半防护如果是给真实网络环境用IPv6一定绕不开。上面示例只注册了NFPROTO_IPV4意味着IPv6流量完全不受检测直接绕过防火墙。这在某些混合栈环境下等于开了一个大洞。扩展方式并不复杂再注册一组NFPROTO_IPV6的hook ops解析时改用ipv6_hdr(skb)比较地址用ipv6_addr_equal哈希键的地址部分需要重新定义。难点不在IPv6本身而是要保证连接表能同时容纳IPv4和IPv6条目。一个可行的做法是把地址字段设计成union { __be32 v4; struct in6_addr v6; }再加上一个地址族标志位。这部分完全可以作为第一版完成后再补的模块但心里要一直有这个todo免得最后上线才发现v6裸奔。3.5 安全编码细节不能含糊写内核模块脏数据随便来天然就是攻击面。几个必须刻进肌肉记忆的细节校验IP头长度和传输层长度防止畸形包越界访问所有从包内获取的字段都用网络字节序比较时统一转成主机字节序或统一用网络字节序哈希种子在模块加载时随机生成不要在每台机器上用固定种子创建新连接时使用GFP_ATOMIC而不是GFP_KERNEL因为HOOK回调可能运行在中断上下文GFP_KERNEL会触发睡眠直接导致系统异常不要在HOOK函数里调用printk打每个包要用printk_ratelimited或者自定义的采样日志。4. 调试、性能与常见问题写完代码总要跑起来而内核网络模块的调试往往比写代码更折磨人。这里把最容易踩的坑和对应的排查路径整理出来基本覆盖了从加载到联调的完整过程。4.1 模块加载与断网自救模块加载后第一位要确认的是HOOK到底有没有生效。先用一条简单的命令验证dmesg | tail -20如果看到“sp_fw: hooks registered”之类的输出说明注册阶段没问题。接着测试基本连通性ping 127.0.0.1 ssh localhost如果第一步就全丢包基本可以确定是HOOK函数把所有包都拦截了。排查方向有两个一是HOOK函数里逻辑写死返回NF_DROP二是解析头部时出错导致内部错误。不管哪种第一反应先确认逃生开关能不能用。我建议第一版就内置这样一个/sys/module/sp_fw/parameters/enable参数也就是一个模块参数static bool sp_fw_enable false; module_param(sp_fw_enable, bool, 0644);默认关闭挂在钩子上但不做任何拦截只记录日志。调通后再通过sysfs打开echo 1 /sys/module/sp_fw/parameters/enable这个逃生开关的意义在于万一误配置导致SSH断了还能通过控制台或重启后的模块参数恢复。别小看这一步没有它的版本我曾多少次因为flush了规则又没法远程连接最后只能物理重启。4.2 回包被丢的经典原因做状态防火墙最容易出现的现象是“主动外出建连成功但响应包永远进不来”。排查思路很直接症状常见原因检查点本机curl外网无响应ping不同LOCAL_OUT没注册或外发包没创建连接查LOCAL_OUT钩子是否挂载查连接表里有无外发记录外部主动连接本机服务不通PRE_ROUTING里陌生包默认丢弃确认白名单是否包含目标端口查丢包日志连接过一会就断超时时间设置太短调整TCP超时阈值检查定时器回收逻辑内网转发不通FORWARD路径未处理或状态记录未覆盖转发包在FORWARD节点挂HOOK或确认PRE_ROUTING后放行关于回包问题核心原因通常就是外出时没在LOCAL_OUT建立连接记录导致外部回包在PRE_ROUTING查状态表时命不中被视为陌生包丢弃。解决办法很简单就是前文说的双向注册。如果你不想在同一回调函数里用state-hook区分当前钩子点那就要在函数里判断state-hook NF_INET_LOCAL_OUT时走创建连接分支在NF_INET_PRE_ROUTING时优先查表。4.3 性能调优别把HOOK函数当成万能口袋HOOK函数是数据通路上的“必经关卡”性能敏感度极高。每次调用尽量做到O(1)不要在函数里做大循环、大内存操作更不要睡眠。一个常见误区是在HOOK函数里做复杂的正则匹配或应用层字段解析。SPI只做到传输层就够了再往深走应该把包交给用户态程序或者eBPF程序去做而不是在内核HOOK里用C语言硬解析。内核态职责边界划清楚性能才不会崩。哈希查找本身要保证常量级。如果连接表设计得当每个包经历的路径是计算哈希、遍历一个短链表、比较五元组、更新状态字段、返回。这个开销在万兆网卡下也是可控的。如果发现连接数大了之后CPU飙高重点怀疑两件事哈希桶数量不够导致链表过长或者哈希种子随机化后仍然有碰撞偏斜。可以用perf top观察HOOK函数的开销也可以在HOOK函数里用ktime_get做简单的耗时统计。但别在产品环境长期开这种统计那是给调试用的。4.4 日志风暴比丢包更可怕的问题状态防火墙跑起来后最烦的不是丢包而是日志刷屏。在默认策略“丢弃陌生包”的情况下只要有扫描器扫你HOOK函数每秒可能会触发几百次NF_DROP。如果每次都printkdmesg会在一分钟内塞满内核日志子系统被拖慢反而影响正常包处理。处理办法很简单用内核自带的printk_ratelimited或者pr_info_ratelimitedif (sp_conn_create(skb, key) 0) { printk_ratelimited(KERN_INFO sp_fw: drop unknown TCP %pI4:%u - %pI4:%u\n, key.saddr, ntohs(key.sport), key.daddr, ntohs(key.dport)); return NF_DROP; }这样每个CPU在限频时间窗口内最多打印固定数量的日志既能留痕又不会刷爆系统。此外可以设计独立的日志缓冲区用环形数组记录最近N条丢弃事件用户态工具通过procfs读取比直接打印到dmesg更灵活。4.5 典型问题速查表结合我自己的实操经验把第一版最常见的报错和解决思路整理成表问题表现可能原因解决办法insmod后系统卡死HOOK函数里用了可能睡眠的锁或kmalloc检查是否用了GFP_KERNEL改为GFP_ATOMIC锁换成自旋锁/RCUdmesg提示unknown symbol内核符号未导出或版本头不匹配检查/lib/modules/$(uname -r)/build是否存在用modpost看未解决符号双向流量全被丢只注册了一个hook点且默认丢弃所有陌生包确认PRE_ROUTING和LOCAL_OUT都注册检查连接表创建分支连接表越来越大超时回收任务没启动或条件判断有误确认delayed_work已调度检查last_seen更新位置IPv6直接绕过规则只注册了NFPROTO_IPV4补一组NFPROTO_IPV6的hook ops模块卸载后连接仍异常钩子未正常释放或卸载时序有race在sp_fw_exit里先摘钩子再等待RCU grace period最后释放连接表这里想单独强调RCU的使用。连接表里的条目可能同时被多个CPU的HOOK函数访问写者少读者多用RCU很适合。删除条目时先list_del_rcu再call_rcu延迟释放内存。这样读者在读旧表项时不会因为内存被提前释放而崩掉。代码里有RCU就不要再叠一层大锁否则等于把RCU的并发优势抵消了。5. 从HOOK函数到一套完整的状态防火墙HOOK函数写出来只是万里长征走完了一半。眼前的模块还停留在“内核里跑着一个能拦包的钩子”这个程度离“一套可用的防火墙”还差管理接口、日志审计、策略配置和与系统协作战术。5.1 让用户态能看见连接表procfs管理接口没有管理接口就不知道自己写的防火墙在干什么连接状态对不对、规则有没有命中全都是黑盒。最简单的管理接口是procfs。可以在/proc/net/下建一个自定义文件实现只读的连接表查看static int sp_fw_proc_show(struct seq_file *m, void *v) { struct sp_conn *conn; int i; seq_printf(m, %-8s %-16s %-6s %-16s %-6s %-4s %s\n, proto, src, sport, dst, dport, state, seen); for (i 0; i SP_CONN_HASH_SIZE; i) { hlist_for_each_entry_rcu(conn, sp_conn_tbl[i], node) { seq_printf(m, %-8s %pI4 %-6u %pI4 %-6u %-4d %lu\n, sp_proto_name(conn-protocol), conn-saddr, ntohs(conn-sport), conn-daddr, ntohs(conn-dport), conn-state, conn-last_seen); } } return 0; }这个接口的价值在于调试效率直接翻倍。包丢了不管是不是状态机的问题先看一眼连接表里到底有没有这条记录比满脑子猜靠谱得多。生产环境再考虑换成netlink给上层配置工具提供异步通知能力。5.2 日志审计与告警设计日志字段至少包含时间、方向、协议、五元组、动作放行/丢弃、状态。用环形缓冲区接收事件用户态定期读取不要直接全部写盘避免高负载时的IO抖动。告警方面可以先做一个“端口扫描检测器”如果同一来源IP在短时间内触发大量陌生连接丢失事件超过设定阈值后打一条高级别告警。这个逻辑不需要单独模块复用连接表的丢包日志就能实现只需要从用户态读取丢包记录并做时间窗口统计。5.3 和系统防火墙共存自研HOOK函数和iptables/nftables可以共存但优先级要协商好。priority决定Netfilter在同一个hook点上调用多个回调的顺序。NF_IP_PRI_FIRST优先级最高会在iptables之前执行。如果你希望自研防火墙做前置过滤先处理再用iptables做网络地址转换等逻辑就保持这个优先级。反过来说如果你希望iptables先做NAT或地址转换再让自研模块看到转换后的包就需要把优先级设为NF_IP_PRI_NAT_DST之后。这没有标准答案取决于你要保护的是“原始包”还是“转换后的包”。第一版建议先把顺序定为自研在前这样语义最简单后续再按场景调整。5.4 下一步可以怎么扩展如果这篇的HOOK函数已经稳定跑过一段时间可以试试下面这些方向扩展到IPv6把连接表的地址字段换成带地址族的union做TCP序列号校验把状态检测从“粗略匹配”提升到“防序列号预测攻击”加入DPI初筛在HOOK函数的入口对特定端口的包做特征字符串匹配实现规则的动态热加载用netlink从用户态下发规则而不是改模块代码重新编译做连接配额对同一来源IP限制并发连接数这是防扫描的好手段。这些都是好方向但别同时铺开。先把SPI核心做稳再逐步扩展每一步都能被单独测试出了问题也好定位。最后聊一点个人的体会。实话说内核网络模块的开发里代码本身很少成为瓶颈真正的分水岭是对“连接状态”这件事是否想得足够清楚。我第一版只做TCP连接表用最简单的数组加哈希跑通以后先用本机SSH去验证再通过网桥转发另一台机器去连。整个调试过程里离不开那根逃生开关、限频率日志和procfs连接表少了任何一个都会在断网级别的故障里疯狂掉头发。所以如果你也准备动手别急着把功能做大先把一个能记录连接、能双向查表、能安全卸载的内核HOOK函数跑稳哪怕它能做的只是“认出已建立的连接并放行”你的状态防火墙也已经立住了。剩下的深度学习、规则引擎都是在这个地基上慢慢垒起来的事。