车载通信防火墙怎么测？从 CAN 网关过滤到车载以太网访问控制

摘要：车载防火墙测试不是简单验证“某个报文能不能通过”。CAN/CAN FD、以太网交换芯片和 Linux 网络栈看到的报文不同，规则匹配条件也不同。要把测试做扎实，需要先找准执行点，再从通信矩阵提取允许关系，最后用入口报文、规则命中、出口报文和目标服务组成完整证据链。本文以中央网关和区域控制器为例，介绍 CAN 网关过滤、Switch ACL、Linux 防火墙以及相关的异常、性能和生命周期测试方法。

说明：文中的地址、CAN ID、端口和命令均为教学示例，只适用于获得授权的隔离台架。量产项目的规则、阈值和失效策略必须来自正式通信矩阵、安全需求、功能安全分析及 OEM 规范。

一、为什么“能通”和“不通”都不能直接算结论

做过网关测试的人，大多遇到过这种情况：测试端发起连接，等了几秒没有响应，于是报告里写上“防火墙成功拦截”。后来继续排查才发现，目标 ECU 根本没有启动，或者返回路由配错了。

CAN 上也一样。报文没有出现在目标总线，可能是网关规则丢弃，也可能是源总线没收到、网关路由表没有加载、目标通道处于 Bus-Off，甚至测试工具发送的标准帧和规则配置的扩展帧不是同一种帧。

所以，车载防火墙测试首先要回答的不是“通不通”，而是下面四个问题：

1. 测试报文是否到达了防火墙入口；
2. 报文实际经过哪个防火墙执行点；
3. 哪条规则对它作出了允许、拒绝或限流动作；
4. 防火墙出口和目标服务最终发生了什么。

只有这四项能够相互印证，测试结论才站得住。

二、车载通信中的防火墙通常在哪里

今天的中央网关、域控制器和区域控制器往往同时连接 CAN/CAN FD 与车载以太网。一台设备里可能存在多个“防火墙”，分别工作在不同的数据路径上。

图 1：车载通信防火墙的典型部署位置

1. CAN 网关过滤

CAN 防火墙通常是中央网关或区域控制器中的一组转发策略。它决定：

• 哪个 CAN 通道上的报文可以转发到哪个目标通道；
• 哪些 CAN ID 可以通过；
• 标准帧、扩展帧、远程帧或 CAN FD 帧如何处理；
• DLC、数据长度、部分载荷和报文频率是否符合要求；
• 诊断请求能否跨域转发；
• 当前车辆状态是否允许这段通信。

部分产品还会把发送过滤放在端点 ECU、CAN 控制器或安全收发器附近，防止一个被攻陷的软件组件任意向总线注入报文。

这里需要明确一个术语边界：CAN 协议本身没有规定一个名为“CAN Firewall”的标准组件。工程上所说的 CAN 防火墙，通常指网关过滤、发送约束、专用安全收发器或类似的策略执行功能。

2. 车载以太网交换面

以太网交换芯片可以通过 VLAN、端口 ACL、MAC 约束、静态转发表、广播和组播控制、风暴抑制等能力限制二层通信。交换芯片本身不等于防火墙，只有当这些能力被配置为安全策略并承担访问控制职责时，它才成为交换面上的防火墙执行点。

3. Linux 主机和路由防火墙

运行 Linux 的网关或域控制器通常使用 Netfilter 实施三、四层过滤，配置工具可能是iptables，也可能是nftables。常见条件包括接口、IP 地址、TCP/UDP、端口和连接状态。

如果报文由交换芯片直接硬件转发，它可能完全不进入 Linux CPU；如果报文走 Linux bridge，也不能未经确认就把它当作普通三层FORWARD流量。数据路径判断错误，是iptables测试中最常见的问题之一。

4. 协议和服务访问控制

更靠近应用的防火墙还可能解析 SOME/IP、SOME/IP-SD、DoIP 等协议字段，把规则细化到服务、方法、事件或诊断目标。只有产品具备相应解析能力时，测试报告才能声称验证了应用层防火墙。

例如，允许 TCP 13400 只说明 DoIP 常用的网络端口可达，不代表 DoIP 路由激活、诊断授权和 UDS 服务访问已经通过验证。

三、测试要从通信矩阵开始

防火墙规则不是凭经验堆出来的，测试用例也不能只靠扫描工具自动生成。真正的起点应该是通信矩阵、诊断需求和车辆状态模型。

一条可以落地测试的需求，至少应包含这些信息：

下面是一份简化后的教学通信矩阵：

这张表并不复杂，但它能直接导出正向、反向、边界和状态切换测试。相比之下，“验证防火墙可以阻止非法通信”这种需求几乎无法直接执行。

四、综合测试台架怎么搭

一套好用的台架，关键不是仪器有多贵，而是防火墙前后都能观察。