简介：本资源是一套完整的Linux内核级状态检测防火墙课程设计项目，面向计算机、网络安全、人工智能等专业的在校学生、教师及初学者，解决传输层报文过滤与连接状态管理的学习实践需求，可直接用于课程设计、毕业设计、实验教学或安全开发入门。压缩包共30个文件，含15个C源码（涵盖内核模块hooks/cmd、用户态应用uapp、工具函数等）、6个头文件（定义数据结构与接口）、3个Makefile（支持内核模块与用户程序分别编译）、2个JSON配置示例、1份README.md说明文档及LICENSE协议，整体仅59KB，轻量易读。已有280人学习下载，代码经实际编译运行验证，红黑树实现的状态表支持高并发读写，内核模块采用读写锁保障安全性，配套命令行工具可动态增删规则、设置默认策略并记录日志。读者可获得从Netfilter钩子注册、Netlink通信、状态同步到用户交互的全链路C语言实现范例，目录结构清晰分层，适合作为Linux网络编程与内核模块开发的进阶学习素材。

1. 为什么一个不到2000行的C项目，能拿下96分答辩？——它把“状态防火墙”从黑匣子变成了可调试、可验证、可讲清楚的课设范本

很多学生做网络安全课设时卡在第一个坎：不是不会写代码，而是写完不知道怎么证明“它真正在工作”。抓包看到包被丢弃了，但不确定是iptables干的还是你的模块干的；加了一条规则，日志里没反应，也不知道是Netlink没通、红黑树没插进去，还是用户态命令压根没发对。这个RJFireWall项目就是为解决这种“玄学调试”而生的——它用最精简的内核模块（kernel.c+hooks.c）+ 用户态控制程序（uapp/main.c）组合，把传输层状态检测的每个关键环节都暴露出来：连接建立时怎么插入红黑树、超时后怎么回收节点、并发插入时读写锁怎么保护、Netlink消息怎么序列化/反序列化。它不追求功能堆砌，而是让每个设计选择都能在答辩PPT里画出一张图、讲出一句原理、贴出一段可复现的日志。适合计科、网安、通信等专业学生直接用于课程设计、毕设开题或中期演示，也适合作为Linux内核网络子系统学习的“最小可运行锚点”。

2. 总体架构设计：三层解耦结构与四个核心模块的职责边界

这个项目没有采用常见的单体内核模块+裸写ioctl的粗暴方式，而是明确划分为内核空间状态引擎层、Netlink通信中间层、用户态命令解析层三层，并进一步拆解为四个高内聚模块。这种划分不是为了炫技，而是为了让答辩时能清晰回答“你这个功能在哪实现的？改起来要动哪几个文件？”——这是评审老师最常问的问题。

2.1 内核空间状态引擎层：红黑树 + 读写锁的轻量级连接跟踪

状态跟踪的核心逻辑集中在kernel_mod/kernel.c中。它不依赖nf_conntrack，而是自己维护一个红黑树（struct rb_root），每个节点代表一条四元组连接（src_ip, src_port, dst_ip, dst_port, proto）。关键设计点在于：

• 节点结构体struct conn_node显式携带超时时间戳和最后活跃时间，避免依赖jiffies换算带来的精度丢失；
• 所有插入/查找/删除操作均包裹在rwlock_t读写锁内，而非简单互斥锁。这是因为状态查询（如conn_lookup()）远多于修改（新建/超时回收），读写锁允许多个CPU同时查表，仅在插入/删除时阻塞全部读写——这正是项目文档中强调“几乎全面实现并发安全”的技术依据；
• 超时回收不依赖定时器轮询，而是在每次conn_lookup()成功后检查last_active，若超时则主动调用conn_delete()。这种“懒回收”策略大幅降低内核线程开销，也规避了定时器精度问题。

// kernel_mod/kernel.c 片段：红黑树插入逻辑（带锁保护） static int conn_insert(struct conn_node *node) { struct rb_node **p = &conn_tree.rb_node; struct rb_node *parent = NULL; struct conn_node *entry; write_lock(&conn_lock); // 注意：此处必须是 write_lock，非 spin_lock while (*p) { parent = *p; entry = rb_entry(parent, struct conn_node, node); if (conn_cmp(node, entry) < 0) p = &(*p)->rb_left; else if (conn_cmp(node, entry) > 0) p = &(*p)->rb_right; else { write_unlock(&conn_lock); return -EEXIST; // 已存在，拒绝重复插入 } } rb_link_node(&node->node, parent, p); rb_insert_color(&node->node, &conn_tree); write_unlock(&conn_lock); return 0; }

提示：conn_cmp()是自定义比较函数，按四元组字典序比较。这里不使用memcmp()是因为IP地址需按网络字节序处理，端口需ntohs()转换，直接比原始内存会出错。

2.2 Netlink通信中间层：自定义协议族NL_FIREWALL的可靠消息通道

项目没有复用NETLINK_NETFILTER，而是注册了独立协议族NETLINK_FIREWALL（定义在include/common.h中），此举有三重好处：一是避免与系统iptables冲突；二是可完全掌控消息格式；三是便于调试时用nlmon单独抓取本模块流量。消息体结构体struct fw_msg定义清晰，含操作类型（ADD/DEL/LIST）、规则字段（ip掩码、端口范围、协议号）、动作（ACCEPT/DROP）及长度校验字段。

// include/common.h #define NL_FIREWALL 31 // 使用未被占用的协议号 struct fw_msg { __u8 cmd; // FW_CMD_ADD, FW_CMD_DEL, FW_CMD_LIST __u8 proto; // IPPROTO_TCP, IPPROTO_UDP __u16 src_port_lo; // 源端口下界（支持范围匹配） __u16 src_port_hi; __u16 dst_port_lo; __u16 dst_port_hi; __u32 src_ip; // 网络字节序 __u32 src_mask; // 掩码，如 0xffffff00 表示 /24 __u32 dst_ip; __u32 dst_mask; __u8 action; // FW_ACTION_ACCEPT, FW_ACTION_DROP __u8 pad[3]; };

kernel_mod/hooks.c中的netlink_send_to_user()函数负责将内核事件（如连接建立、超时）封装成fw_msg并通过nlmsg_unicast()发送给用户态。注意：该函数在软中断上下文调用，因此必须使用GFP_ATOMIC分配内存，否则会导致内核panic——这是学生实现时最容易翻车的点之一。

2.3 用户态命令解析层：Makefile驱动的编译-加载-测试一体化流程

整个用户态工具链由顶层Makefile统一管理，执行make all即完成：编译内核模块（rjfw.ko）、编译用户程序（uapp/rjfwctl）、插入模块、启动日志监听。这种设计让学生摆脱“先编译哪个、再加载哪个、环境变量怎么设”的混沌状态。uapp/main.c的主循环采用select()监听 Netlink socket 和 stdin，实现交互式命令（如add tcp 192.168.1.0/24 80 drop）与后台日志接收并行处理。

注意：uapp/Makefile中显式指定-I../include和-L../tools，确保头文件与辅助函数（如IP字符串解析）路径正确。若学生自行修改目录结构却忘记同步此路径，编译必报undefined reference to 'parse_ip'错误。

2.4 辅助工具层：tools.c提供可复用的网络基础能力

tools.c封装了课设中高频使用的底层能力：parse_ip("192.168.1.100")返回网络字节序整数、parse_mask("/24")计算子网掩码、port_range_parse("80-8080")解析端口范围。这些函数均经过边界测试（如parse_ip("256.1.1.1")返回错误码），避免学生在规则解析阶段陷入字符串处理泥潭。其价值在于：当答辩被问到“你怎么处理IP掩码的？”时，可直接指向tools.c:line 47，而非现场手写正则表达式。

3. 核心模块实现：状态检测、规则匹配与日志记录的代码级落地

这一章聚焦三个最易被提问的模块：状态检测如何判断ESTABLISHED、规则匹配如何支持掩码与端口范围、日志记录如何保证不阻塞内核路径。每段代码都附带“为什么这么写”的设计说明，而非单纯贴代码。

3.1 状态检测：基于TCP标志位与连接生命周期的双轨判定

项目不依赖nf_conntrack的状态机，而是通过分析TCP报文标志位（SYN/FIN/ACK/RST）与红黑树中节点的存活状态，自主判定连接状态。关键逻辑在kernel_mod/hooks.c的tcp_state_check()函数：

// kernel_mod/hooks.c static enum fw_conn_state tcp_state_check(const struct sk_buff *skb, const struct iphdr *iph, const struct tcphdr *tcph, bool *is_new) { struct conn_node key = {0}, *found; __be32 src_ip = iph->saddr, dst_ip = iph->daddr; __be16 src_port = tcph->source, dst_port = tcph->dest; // 构造反向key：用于查找已存在的连接（如响应包） key.src_ip = dst_ip; key.dst_ip = src_ip; key.src_port = dst_port; key.dst_port = src_port; key.proto = IPPROTO_TCP; read_lock(&conn_lock); found = conn_lookup(&key); // 查找反向连接 read_unlock(&conn_lock); if (found) { // 已存在反向连接，且当前包是ACK（确认建立）或数据包 if (tcph->syn && tcph->ack) { *is_new = false; return FW_CONN_ESTABLISHED; } else if (!(tcph->syn || tcph->fin || tcph->rst)) { // 非控制包，视为数据流延续 *is_new = false; return FW_CONN_ESTABLISHED; } } else if (tcph->syn && !tcph->ack) { // SYN包，新建连接 *is_new = true; return FW_CONN_NEW; } return FW_CONN_INVALID; }

设计说明：此函数返回FW_CONN_NEW或FW_CONN_ESTABLISHED，供后续钩子函数决定是否放行。它不处理FIN/RST的优雅关闭，因课设目标是“检测”，而非“完整连接跟踪”。若学生想扩展，只需在tcph->fin分支中调用conn_delete()即可——这就是模块化设计的好处：改一处，不影响其他。

3.2 规则匹配：支持CIDR掩码与端口区间的高效过滤

规则匹配发生在kernel_mod/hooks.c的rule_match()函数中，它接收一个struct fw_rule（来自用户态）和当前报文五元组，返回是否匹配。关键创新在于掩码计算与端口范围检查的零开销融合：

// kernel_mod/hooks.c static bool rule_match(const struct fw_rule *rule, __be32 src_ip, __be32 dst_ip, __be16 src_port, __be16 dst_port, __u8 proto) { // 1. 协议匹配（精确） if (rule->proto != IPPROTO_IP && rule->proto != proto) return false; // 2. 源IP掩码匹配：(src_ip & rule->src_mask) == rule->src_ip if ((src_ip & rule->src_mask) != rule->src_ip) return false; // 3. 目的IP掩码匹配 if ((dst_ip & rule->dst_mask) != rule->dst_ip) return false; // 4. 端口范围匹配：支持单端口（lo==hi）与区间 if (ntohs(src_port) < ntohs(rule->src_port_lo) || ntohs(src_port) > ntohs(rule->src_port_hi)) return false; if (ntohs(dst_port) < ntohs(rule->dst_port_lo) || ntohs(dst_port) > ntohs(rule->dst_port_hi)) return false; return true; }

设计说明：rule->src_mask是预计算好的掩码值（如/24对应0xffffff00），避免运行时调用inet_cidr_ntop4()。端口范围用ntohs()转换后比较，确保字节序一致。这种写法比逐字符解析字符串快两个数量级，且无内存分配——符合内核模块“零分配”原则。

3.3 日志记录：异步Netlink推送与ring buffer防丢机制

日志不走printk()（会刷屏且难过滤），而是通过 Netlink 异步推送给用户态。为防止高负载下消息丢失，内核侧采用简易 ring buffer（log_ring数组）暂存待发送日志，用户态rjfwctl以recvmsg()循环拉取。kernel_mod/kernel.c中的log_enqueue()函数是关键：

// kernel_mod/kernel.c #define LOG_RING_SIZE 256 static struct fw_log log_ring[LOG_RING_SIZE]; static unsigned int log_head, log_tail; static DEFINE_SPINLOCK(log_lock); int log_enqueue(const struct fw_log *log) { unsigned long flags; spin_lock_irqsave(&log_lock, flags); if ((log_head + 1) % LOG_RING_SIZE == log_tail) { spin_unlock_irqrestore(&log_lock, flags); return -ENOSPC; // 满了，丢弃 } log_ring[log_head] = *log; log_head = (log_head + 1) % LOG_RING_SIZE; spin_unlock_irqrestore(&log_lock, flags); return 0; }

设计说明：spin_lock_irqsave确保中断上下文安全；-ENOSPC返回值提醒用户态“可能丢日志”，促使学生在答辩时主动说明“本设计优先保障防火墙性能，日志为辅助诊断，满则丢弃”。这种坦诚反而体现工程权衡意识。

4. 常见问题排查：五个让90%学生当场卡住的翻车点与血泪解法

做这个项目时，我带过三届学生，发现有五个问题出现频率极高，且一旦卡住，往往需要2小时以上才能定位。这里不讲大道理，只列现象、原因、解法，每条都来自真实调试记录。

4.1 现象：insmod rjfw.ko后dmesg | grep rjfw无任何输出，模块看似加载成功但无反应

原因：mod_main.c中register_netdevice_notifier()或nf_register_hooks()调用失败，但代码未检查返回值，导致钩子未注册。常见于内核版本差异（如5.10+要求nf_hook_ops结构体新增.priority字段）。
解法：在mod_main.c的rjfw_init()函数末尾添加：

if (ret < 0) { printk(KERN_ERR "rjfw: failed to register hooks, ret=%d\n", ret); goto err_hooks; }

然后dmesg必定看到错误，再对照include/uapi/linux/netfilter.h确认NF_INET_PRE_ROUTING等宏定义是否存在。

4.2 现象：./rjfwctl add tcp 192.168.1.0/24 22 accept执行后，./rjfwctl list显示空列表

原因：用户态rjfwctl发送 Netlink 消息时，struct sockaddr_nl的nl_pid字段未置0（应设为0表示内核），导致内核无法识别消息来源，静默丢弃。
解法：检查uapp/main.c中send_nl_msg()函数，确保：

struct sockaddr_nl sa; memset(&sa, 0, sizeof(sa)); sa.nl_family = AF_NETLINK; sa.nl_pid = 0; // 关键！必须为0，表示发给内核

4.3 现象：添加规则后，本该放行的SSH连接仍被拒绝，tcpdump显示SYN包被丢弃

原因：规则匹配逻辑中，rule->proto字段被误设为IPPROTO_TCP，但实际传入的是iph->protocol（已为网络字节序？不，iph->protocol是主机字节序的单字节值）。rule_match()中rule->proto != proto比较永远为真。
解法：在uapp/tools.c的规则解析函数中，确保rule->proto = proto_num;（proto_num来自getprotobyname("tcp")->p_proto，已是主机序）；内核侧rule_match()中proto参数直接取iph->protocol，无需ntohs()。

4.4 现象：并发压力测试（ab -n 10000 -c 100 http://target/）下，dmesg报BUG: scheduling while atomic

原因：在 Netfilter 钩子函数（软中断上下文）中调用了printk()或msleep()等可能引起调度的函数。本项目虽未用msleep()，但若学生自行添加调试printk()到hooks.c的nf_hookfn中，即触发此错。
解法：所有printk()必须加KERN_DEBUG级别，并确认不在in_atomic()上下文中。更稳妥做法是：用log_enqueue()将信息入ring buffer，由独立内核线程（或用户态）消费。

4.5 现象：make clean后重新make all，报错error: redefinition of ‘xxx’

原因：include/下头文件未加#ifndef XXX_H宏卫士，导致kernel.c和hooks.c同时#include "common.h"时，其中的struct fw_rule被重复定义。
解法：在include/common.h开头添加：

#ifndef COMMON_H #define COMMON_H // ... 原有内容 ... #endif

这是C语言基础，但课设学生常忽略，因IDE未报错（头文件只在一个源文件中展开）。

5. 答辩与验收：用三张表、两段日志、一个对比实验让评审信服你的工作量

答辩不是背诵代码，而是证明你理解每一行为什么存在。我带的学生中，拿96分的共同点是：提前准备三张表、两段关键日志、一个可现场演示的对比实验。下面是我要求他们必须做到的验收动作。

5.1 三张核心表格：让设计决策可视化

提示：这三张表必须打印在答辩PPT的“系统设计”页，不要藏在附录。评审老师扫一眼就能判断你是否真做过。

5.2 两段必现日志：证明状态检测与规则生效

第一段：连接建立日志
在终端A执行./rjfwctl log，终端B执行telnet 192.168.1.100 22，终端A应实时输出：

[2023-10-05 14:22:33] NEW TCP 192.168.1.5:54321 -> 192.168.1.100:22 [2023-10-05 14:22:33] ESTAB TCP 192.168.1.5:54321 -> 192.168.1.100:22

第二段：规则拦截日志
先执行./rjfwctl add tcp 192.168.1.0/24 22 drop，再在另一台机器执行telnet 192.168.1.100 22，日志应显示：

[2023-10-05 14:25:11] DROP TCP 192.168.1.200:49152 -> 192.168.1.100:22 (match rule #1)

注意：日志中的(match rule #1)是rule_match()成功后的打印，证明规则引擎在工作。若无此括号，说明规则未命中——此时立刻检查./rjfwctl list输出的src_mask是否为0xffffff00（对应/24），而非0xffffffff（/32）。

5.3 一个对比实验：证明“并发安全”不是空话

这是拿高分的关键动作。准备两台虚拟机（VM1、VM2），VM1 运行防火墙，VM2 执行：

# 在VM2上并发发起100个SSH连接 for i in $(seq 1 100); do timeout 2 ssh -o ConnectTimeout=1 -o BatchMode=yes user@192.168.1.100 exit 2>/dev/null & done wait

同时在VM1上运行./rjfwctl log | grep "NEW\|ESTAB" | wc -l，记录连接数。然后注释掉kernel.c中所有write_lock/read_lock调用，重新编译加载，再跑同样脚本。两次结果对比：

从那以后我每次带学生做内核模块，都强制他们在答辩前跑一遍这个对比实验，并把截图放在PPT最后一页。它不证明代码完美，但证明你真的动手验证过“并发安全”这个核心卖点。希望帮到你。

本文还有配套的精品资源，点击获取