硬件网络防火墙详细设计（应用黑名单）

1. 文档目的

本文档用于指导“硬件网络防火墙”项目的详细设计、RTL 实现、验证和上板联调。本文档以“防微信登录”为业务案例，但在设计边界上做明确收缩：

1. 仅针对浏览器访问登录入口域名对应的目标地址进行阻断。

2. 硬件数据面仅解析到 L2/L3，不解析 L4 及以上内容。

3. 域名到 IP 的解析、规则整理与下发由控制面完成。

4. 硬件面只负责对目的 IP 做快速匹配与过滤。

因此，本设计不是一个通用 DPI 防火墙，而是一个面向特定登录入口访问控制的轻量级硬件过滤系统。

本文档作为项目落地的设计输入，支持以下工作：

1. 明确项目需求和工程边界。

2. 明确 L2/L3 数据面处理链路。

3. 明确三种 IP 查表算法的实现方式和优劣。

4. 明确规则装载、验证和上板调试步骤。

---

2. 项目背景

2.1 背景说明

在企业园区网、考试专网、培训专网、受控办公网中，常见需求不是对所有应用协议做复杂识别，而是对某些明确业务入口做确定性阻断。例如：

1. 禁止终端访问某类网页登录入口。

2. 禁止考试环境中访问特定社交平台登录页面。

3. 禁止办公终端接入某类外部认证入口。

若为此引入完整 DPI 或 TLS 深度解析系统，工程成本较高，且对 FPGA 首版实现并不友好。对于“只需要拦住登录入口访问”这一场景，更实际的办法是：

1. 在控制面维护“目标登录域名列表”。

2. 由控制面将域名预解析为 IP 地址集合。

3. 将 IP 集合下发给 FPGA。

4. FPGA 仅根据报文目的 IP 做放行或丢弃决策。

这种方法虽然不具备完整应用层识别能力，但设计简单、时延低、易验证，适合作为课程设计、项目原型或硬件样机的第一版实现。

2.2 案例选择

本文以“防微信登录”为案例。这里的含义被限定为：

1. 管理端预先维护微信网页登录入口域名列表。

2. 控制面定时解析这些域名的 A 记录或 CDN 目标地址。

3. 将解析得到的目标 IP 加入 FPGA 黑名单表。

4. 终端浏览器若访问这些目标 IP，则在 L3 层直接被丢弃。

该设计不尝试在硬件中识别 TLS SNI、HTTP Host 或页面内容，也不尝试覆盖所有微信相关业务流量，而只聚焦在“浏览器访问登录入口”这一个受控目标上。

2.3 设计边界

本项目采用以下边界定义：

1. 硬件面只解析 Ethernet、VLAN、IPv4。

2. 硬件面只提取目的 IP，不关心 TCP/UDP 端口和应用层内容。

3. 域名解析在控制面完成，硬件不解析 DNS。

4. 规则类型只保留“目的 IPv4 精确匹配”。

5. 动作首版只保留 PASS 和 DROP。

以上边界是本次简化的核心。文档后续所有设计都以该边界为准。

---

3. 设计目标与验收指标

3.1 设计目标

设计一个基于 FPGA 的轻量级硬件网络防火墙，对接入链路上的以太网流量进行 L2/L3 解析，并根据目的 IPv4 地址完成快速匹配和过滤，达到以下目标：

1. 支持 Ethernet II、VLAN、IPv4 基础解析。

2. 提取 IPv4 目的地址并构造查表键值。

3. 支持目的 IP 黑名单匹配。

4. 命中规则时直接丢弃，未命中则透传。

5. 支持控制面批量更新 IP 规则表。

3.2 核心验收指标

| 指标项 | 目标值 |

| -------- | -------------------------------------------------- |

| 接口速率 | 1GbE |

| 工作时钟 | 125 MHz |

| 解析层级 | L2/L3 |

| 规则对象 | 浏览器访问登录入口域名解析得到的目的 IP |

| 规则类型 | 目的 IPv4 精确匹配 |

| 查表方式 | 顺序查表、二分法查表、布谷鸟哈希三种方式可切换验证 |

| 动作类型 | PASS / DROP |

| 规则容量 | 不低于 1K 条 IPv4 规则 |

| 统计能力 | 支持总包数、命中数、丢弃数、放行数 |

3.3 非功能目标

1. 结构简单，便于教学展示和调试。

2. 规则格式统一，便于控制面生成。

3. 算法模块接口统一，便于替换与对比。

4. 资源消耗可控，适合中低端 FPGA。

---

4. 需求分析

4.1 业务场景

业务流程定义如下：

1. 管理员维护“微信登录入口域名”列表。

2. 控制面程序定时对这些域名做 DNS 解析。

3. 控制面将解析得到的 IP 地址整理成黑名单表。

4. 控制面将 IP 黑名单下发到 FPGA。

5. 浏览器访问这些目标 IP 时，硬件在 L3 层直接丢弃对应报文。

在这个简化方案下，硬件不关心报文为什么访问该 IP，也不判断应用层协议是否为 TLS，只要目的 IP 命中规则表就执行过滤。

4.2 功能需求

1. 支持以太网帧接收与基本格式校验。

2. 支持 VLAN 可选解析。

3. 支持 IPv4 首部提取。

4. 支持获取目的 IPv4 地址 dst_ip。

5. 支持将 dst_ip 输入查表模块。

6. 支持命中后丢包、未命中后透传。

7. 支持统计计数。

8. 支持规则批量更新。

4.3 非需求说明

以下能力不属于本版实现范围：

1. DNS 报文内容解析。

2. TLS ClientHello/SNI 解析。

3. HTTP Host 解析。

4. 五元组过滤。

5. TCP RST 注入。

6. 深度包检测。

---

5. 总体方案

5.1 系统结构

系统采用“L2/L3 解析 + IP 查表 + 动作执行 + 统计管理”的简化结构：

MAC RX
  -> L2/L3 Parser
  -> dst_ip 提取
  -> IP 查表引擎
  -> 动作执行(PASS/DROP)
  -> MAC TX / DROP
                \
                 -> 统计计数 / 配置接口

5.2 模块划分

1. rx_parser_l23：完成以太网、VLAN、IPv4 解析。

2. ip_key_builder：提取 dst_ip 并形成查表输入键。

3. lookup_seq：顺序查表引擎。

4. lookup_bin：二分法查表引擎。

5. lookup_cuckoo：布谷鸟哈希查表引擎。

6. lookup_ctrl：选择当前启用的查表方式。

7. action_engine：根据命中结果执行 PASS 或 DROP。

8. cfg_if：规则装载和状态读取接口。

9. counter_mgr：统计总包数、命中数、丢包数、放行数。

5.3 关键设计原则

1. 数据面只做目的 IP 精确匹配。

2. 规则表结构对三种查表算法保持统一。

3. 应优先保证时序和可验证性，而不是功能堆叠。

4. 控制面复杂度上移，数据面复杂度下移。

---

6. 微信登录阻断案例建模

6.1 识别对象定义

在本项目中，“微信登录相关流量”被收缩定义为：

1. 浏览器访问登录入口域名所对应的目标服务器 IP。

2. 控制面根据这些登录入口域名解析出的 IPv4 地址集合。

因此，硬件侧真正识别的对象不是域名本身，而是“目标 IP 是否属于预先下发的受限地址集合”。

6.2 控制面规则生成逻辑

控制面流程如下：

1. 维护登录入口域名名单。

2. 周期性解析域名，得到 IP 列表。

3. 过滤重复项、失效项和空结果。

4. 输出规则表文件。

5. 下载到 FPGA 查表模块。

6.3 规则样例

| 规则类型 | 关键字 | 动作 |

| ------------------ | -------------------- | ---- |

| 目的 IP 精确匹配 | dst_ip = A.B.C.D | DROP |

| 白名单 IP 精确匹配 | dst_ip = X.Y.Z.W | PASS |

如无白名单需求，首版可以只保留黑名单精确匹配。

6.4 判决优先级

为避免文档复杂化，本版定义简单优先级：

1. 若启用白名单，则白名单优先。

2. 黑名单次之。

3. 未命中规则则透传。

---

7. 数据面报文处理流程

7.1 报文入口

网口收到报文后，rx_parser_l23 按流接口接收字节流，完成以下步骤：

1. 识别以太网帧起始。

2. 提取目的 MAC、源 MAC、EtherType。

3. 若存在 VLAN，则继续提取 VLAN Tag 并修正偏移。

4. 判断上层协议是否为 IPv4。

5. 提取 IPv4 首部中的目的地址字段。

7.2 规则键构造

本版规则键非常简单，直接定义为：

rule_key = dst_ip[31:0]

如后续需要增加白名单、规则类型或扩展标志，可扩展为：

rule_key = {
  rule_type[3:0],
  dst_ip[31:0]
}

但首版推荐直接使用 32 位目的 IP 作为查表键。

7.3 判决流程

1. 若报文不是 IPv4，则默认透传。

2. 若报文是 IPv4，则提取 dst_ip。

3. 将 dst_ip 输入当前启用的查表模块。

4. 若命中黑名单，则执行 DROP。

5. 若未命中，则执行 PASS。

这种流程保证数据面非常短，便于控制时延和资源。

---

8. 规则格式设计

8.1 表项结构

建议单条规则结构如下：

| 字段 | 位宽 | 说明 |

| ----------- | ---: | -------------- |

| valid | 1 | 表项有效位 |

| dst_ip | 32 | 目的 IPv4 地址 |

| action | 1~2 | PASS 或 DROP |

| counter_idx | 16 | 统计索引 |

如仅实现黑名单丢弃，则 action 字段可以固定不存，表项可进一步简化为：

| 字段 | 位宽 | 说明 |

| ------ | ---: | -------------- |

| valid | 1 | 表项有效位 |

| dst_ip | 32 | 目的 IPv4 地址 |

8.2 动作编码

| 编码 | 动作 |

| ---: | ---- |

| 0 | PASS |

| 1 | DROP |

8.3 存储建议

1. 顺序表和二分表可直接存于 BRAM。

2. 布谷鸟哈希表建议按多表 BRAM 组织。

3. 规则量在 1K 级时，片上存储即可满足首版需求。

---

9. 三类查表算法详细设计

本文保留顺序查表、二分法查表和布谷鸟哈希三种方法，但其匹配对象均已统一为“32 位目的 IPv4 地址”。

9.1 顺序查表

9.1.1 适用场景

顺序查表适用于：

1. 规则数量较少，如 32~128 条。

2. 首版原型验证。

3. 希望快速完成上板闭环。

9.1.2 基本思路

报文提取出 dst_ip 后，从表头到表尾逐条比较：

1. 若 dst_ip == table[i].dst_ip，则命中。

2. 若遍历结束仍未命中，则透传。

9.1.3 硬件实现方法

1. 单比较器串行扫描：每拍读一条规则并比较。

2. 多比较器并行分组扫描：每拍并行比较 N 条规则，再做归约。

9.1.4 推荐接口

module lookup_seq #(
    parameter RULE_NUM = 64
)(
    input  wire        clk,
    input  wire        rst_n,
    input  wire        key_valid,
    input  wire [31:0] dst_ip,
    output wire        hit_valid,
    output wire        hit
);

9.1.5 时延分析

最坏时延近似为：

例如 64 条规则时，最坏需要约 64 拍，适合教学原型，不适合大表高吞吐主路径。

9.1.6 优点

1. 结构最简单。

2. 易写、易仿真、易上板。

3. 适合第一阶段联调。

9.1.7 缺点

1. 规则越多时延越大。

2. 难以扩展到更大规模规则表。

---

9.2 二分法查表

9.2.1 适用场景

二分法查表适合已排序的 IPv4 地址表，适用于：

1. 中等规模目标 IP 黑名单。

2. 规则更新周期较长的场景。

3. 需要在较低资源下获得较快查找速度。

9.2.2 基本思路

将 dst_ip 规则表按数值升序排列。查找时不断比较中间值：

1. 若 dst_ip == table[mid]，则命中。

2. 若 dst_ip < table[mid]，查左半区。

3. 若 dst_ip > table[mid]，查右半区。

9.2.3 硬件实现方法

1. 将排序后的 IP 表写入 BRAM。

2. 通过状态机维护 low、high、mid。

3. 每拍读出中间项并比较。

4. 若命中则结束，否则缩小搜索区间。

9.2.4 时延分析

当 N=1024 时，理论比较层数约 10 层，明显优于顺序查表。

9.2.5 优点

1. 相比顺序查表，时延显著降低。

2. 逻辑不复杂，容易验证。

3. 对资源要求低于多表哈希结构。

9.2.6 缺点

1. 规则更新前需重排序。

2. 不适合高频动态插入。

---

9.3 布谷鸟哈希查表

9.3.1 适用场景

布谷鸟哈希适用于较大规模 IPv4 黑名单，适用于：

1. 目标 IP 数量较大。

2. 希望查找时延接近常数级。

3. 需要作为高性能版本的主查找引擎。

9.3.2 基本思路

对 32 位 dst_ip 计算多个哈希地址，例如：

将同一个 IP 放入多个候选桶位之一。查找时并行读取多个位置，只要其中一个位置命中就判定为匹配。

9.3.3 硬件实现方法

1. 采用 2 表或 4 表 BRAM 结构。

2. 对 dst_ip 同拍计算多个哈希地址。

3. 同拍并行读取多个表项。

4. 通过并行比较判断是否命中。

9.3.4 插入策略

插入由控制面负责：

1. 控制面离线构建哈希表。

2. 解决冲突后生成最终镜像。

3. 批量写入 FPGA。

这样可以避免在 FPGA 数据面中实现复杂的在线踢出逻辑。

9.3.5 时延分析

在并行 BRAM 结构下通常为固定 2~4 拍，适合作为高性能主路径。

9.3.6 优点

1. 查找速度快。

2. 更适合大容量规则表。

3. 容易实现固定时延数据面。

9.3.7 缺点

1. 控制面建表复杂。

2. 规则更新链路比顺序表和排序表复杂。

---

10. 三类查表算法对比与选型

| 维度 | 顺序查表 | 二分法查表 | 布谷鸟哈希 |

| ------------ | -------- | ---------- | ---------- |

| 匹配对象 | 目的 IP | 目的 IP | 目的 IP |

| 查找时延 | 线性增长 | 对数增长 | 近似常数 |

| 实现复杂度 | 低 | 中 | 中高 |

| 更新复杂度 | 低 | 中 | 高 |

| 适合容量 | 小表 | 中表 | 大表 |

| 首版推荐度 | 高 | 中 | 低 |

| 性能扩展能力 | 低 | 中 | 高 |

10.1 推荐选型

结合本次简化目标，推荐实施顺序如下：

1. 首版原型：顺序查表

• 最容易实现。

• 最容易验证。

• 足以完成课程设计和原型演示。

2. 性能优化版：二分法查表

• 在不显著增加复杂度的情况下提升性能。

3. 高性能版：布谷鸟哈希

• 作为扩展版本，用于展示更优查找时延。

因此，本项目的主线建议是：先用顺序查表跑通，再在同一接口下替换成二分法和布谷鸟哈希进行性能对比。

---

11. 详细模块设计

11.1 rx_parser_l23

功能

完成以太网帧、VLAN、IPv4 头部解析，提取目的 IP。

输入

1. s_axis_tdata

2. s_axis_tvalid

3. s_axis_tlast

输出

1. meta_valid

2. is_ipv4

3. dst_ip

4. parse_error

实现说明

按字节偏移状态机实现：

1. 先读目的 MAC、源 MAC、EtherType。

2. 若 EtherType 为 VLAN，则跳过 VLAN Tag。

3. 若上层为 IPv4，则提取 dst_ip。

4. 否则输出 is_ipv4=0。

11.2 ip_key_builder

功能

将 dst_ip 直接作为查表输入键。

说明

本版无需复杂拼接逻辑，仅需完成 meta_valid 对齐与键值锁存。

11.3 lookup_seq

功能

对 dst_ip 执行顺序精确匹配。

11.4 lookup_bin

功能

对排序后的 dst_ip 表执行二分查找。

11.5 lookup_cuckoo

功能

对 dst_ip 执行布谷鸟哈希精确匹配。

11.6 lookup_ctrl

功能

根据配置寄存器选择当前启用的查表方式：

1. 00：顺序查表

2. 01：二分法查表

3. 10：布谷鸟哈希

说明

首版可只启用顺序查表，其余模式保留扩展接口。

11.7 action_engine

功能

根据查表结果执行：

1. 命中 -> DROP

2. 未命中 -> PASS

首版建议

不生成 RST，不做镜像，不做深度异常处理，只保留最小动作闭环。

11.8 cfg_if

功能

支持规则表写入、查表模式选择、统计寄存器读取。

11.9 counter_mgr

功能

维护以下统计项：

1. 总收包数

2. IPv4 包数

3. 命中包数

4. 丢弃包数

5. 放行包数

---

12. 控制面与规则装载设计

12.1 控制面职责

本项目明确将以下复杂工作放到控制面完成：

1. 登录入口域名维护。

2. 域名到 IP 的解析。

3. IP 列表去重和清洗。

4. 查表镜像生成。

5. 规则批量下载。

12.2 规则生成流程

1. 管理员维护域名源文件。

2. 控制面周期解析域名，得到 IPv4 列表。

3. 去重后生成 dst_ip 规则表。

4. 按选用算法生成对应表结构：

• 顺序表镜像

• 排序表镜像

• 布谷鸟哈希镜像

5. 通过 cfg_if 下载到 FPGA。

12.3 更新策略

1. 顺序表支持直接覆盖写。

2. 二分表更新前重新排序。

3. 布谷鸟哈希由控制面离线建表后整体替换。

---

13. 关键实现步骤

13.1 第 1 步：完成 L2/L3 解析模块

先实现 rx_parser_l23，确认：

1. Ethernet II 正常解析。

2. VLAN 报文正常解析。

3. IPv4 目的地址提取正确。

13.2 第 2 步：完成顺序查表最小闭环

实现最小可运行版本：

1. dst_ip 提取

2. 顺序查表

3. 命中丢弃

4. 未命中透传

这是本项目最重要的里程碑。

13.3 第 3 步：增加统计计数

加入基础计数器，便于验证过滤效果。

13.4 第 4 步：实现控制面批量下发

使上位机可将域名解析后的 IP 列表下载到 FPGA。

13.5 第 5 步：实现二分法查表

在同一接口下替换顺序查表为二分法查表，并统计时延提升。

13.6 第 6 步：实现布谷鸟哈希查表

在控制面离线建表的前提下，增加布谷鸟哈希版本，并与前两者做对比。

13.7 第 7 步：上板联调

使用浏览器访问测试目标站点，验证是否被成功阻断。

---

14. 时序与资源估算

14.1 解析路径时延估算

| 模块 | 预计时延（拍） |

| ---------- | -------------: |

| L2/L3 解析 | 8~16 |

| 键值锁存 | 1~2 |

| 顺序查表 | 16~64 或更高 |

| 二分查表 | 8~16 |

| 布谷鸟哈希 | 2~4 |

| 动作执行 | 1~2 |

14.2 资源估算

以下为简化方案的首版估算：

| 模块 | LUT | FF | BRAM | 说明 |

| ---------- | --------: | --------: | ---: | ------------------ |

| L2/L3 解析 | 1200~2500 | 1000~2200 | 1~3 | 明显低于深协议解析 |

| 顺序查表 | 300~1000 | 300~800 | 1~4 | 与规则数相关 |

| 二分查表 | 500~1200 | 400~900 | 2~6 | 需有序表 |

| 布谷鸟哈希 | 1000~2500 | 800~1800 | 4~12 | 与表数相关 |

| 统计与配置 | 300~800 | 300~700 | 1~2 | |

相较于解析到 L4 甚至应用层的方案，本版资源和时序压力都会明显下降。

---

15. 验证方案

15.1 功能仿真

测试激励建议包括：

1. 普通 IPv4 报文，目的 IP 不在黑名单。

2. 黑名单目标 IP 报文。

3. 非 IPv4 报文。

4. 含 VLAN 的 IPv4 报文。

5. 解析异常或截断报文。

15.2 算法对比验证

使用同一组 dst_ip 规则表，对三类查表模块分别统计：

1. 命中正确率。

2. 平均查找拍数。

3. 最坏查找拍数。

4. LUT/FF/BRAM 占用。

15.3 上板验证

1. 控制面解析目标登录域名并下发规则。

2. 浏览器访问受限登录入口。

3. 观察报文被阻断。

4. 读取计数器确认命中数增加。

15.4 误阻断验证

1. 访问不在黑名单中的普通网页。

2. 访问其他 HTTPS 网站。

3. 检查是否误丢包。

---

16. 风险与规避措施

16.1 域名解析结果变化风险

登录入口域名可能对应动态变化的 CDN 地址。

规避措施

1. 控制面定时重新解析。

2. 规则表支持批量更新。

16.2 IP 复用导致误阻断风险

某些 IP 可能同时服务其他业务。

规避措施

1. 缩小目标域名范围。

2. 优先使用确认稳定的登录入口地址。

3. 必要时引入白名单。

16.3 首版覆盖范围有限

由于不解析应用层，若登录入口迁移到新 IP 或复用其他站点地址，可能出现漏拦或误拦。

规避措施

1. 在文档中明确本版能力边界。

2. 后续如有需要再扩展到 L4 或应用层。

---

17. 项目交付清单

1. 详细设计文档 硬件网络防火墙.md

2. L2/L3 解析 RTL

3. 三类目的 IP 查表 RTL 模块

4. 动作执行与统计模块

5. 配置下发接口模块

6. 控制面规则生成脚本

7. 仿真测试平台

8. 上板验证报告

---

18. 结论与推荐实施路线

在“只针对浏览器访问登录入口域名进行过滤”的约束下，将设计收缩为“控制面解析域名，硬件面只做 L2/L3 解析 + 目的 IP 匹配”是更合理的工程路线。这样做有三个直接好处：

1. 大幅降低硬件复杂度。

2. 显著缩短首版开发周期。

3. 便于清晰对比三种查表算法的性能差异。

推荐实施路径如下：

1. 先完成 L2/L3 解析 + 顺序查表 的最小闭环。

2. 再在统一接口下替换为 二分法查表。

3. 最后实现 布谷鸟哈希 版本，用于性能优化和论文/项目展示。

这样既满足当前项目的简化目标，也保留了后续向更高性能版本扩展的空间。