车载防火墙是针对城市轨道交通车载TCMS系统和旗子暗记系统等设计开拓的边界隔离和安全防护产品。产品采取工业级ARM多核处理器芯片的硬件架构和自主知识产权的智能工控安全操作系统（IICS-OS），基于优化的软硬件架构提高报文的处理能力，对主流工业协议进行深度报文解析（DPI，Deep Packet Inspection），利用“白名单+智能学习”技能建立车载数据通信及车载掌握网络区域间通信模型，担保只有可信任的流量可以在网络上传输。产品在供应传统工业防火墙功能的根本上，可适应TCMS系统和旗子暗记系统运用处景，识别列车掌握系统干系协议，并基于协议做访问掌握和安全策略，为车载掌握网络与外部网络互联、车载掌握网络内部区域之间的网络连接供应安全保障。
产品设计之初为自管理形态，即防火墙运用与管理平台运行在同一台物理设备上。项目研发过程中为知足客户新需求，后期又增加了集中管理办法。详细运作办法为，统一安全管理平台支配在地面管理非车载防火墙、日志审计等其他设备；白天列车运行过程中，车载防火墙进入自管理状态，日志数据存储在本地；夜间列车进站后，车载防火墙同时事情在自管理和集中管理状态，须要将白天产生的日志数据上传至地面支配的统一安全管理平台，以实现对日志的统筹管理。
02测试寻衅
原来的自管理形态，对付管理平台而言日志数量相对较少、处理压力较小；对付集中管理，由于地面支配的防火墙、日志审计等设备不是很多，处理起来比较轻松。而车载防火墙在每辆列车上要支配2台，当几十辆乃至上百辆列车同时支配时，集中管理平台就要面临着处理上百台乃至几百台设备的压力，若何去管理这些设备以及这些设备上报的日志怎么处理是亟待办理的问题。
除了设备本身面临的寻衅，测试职员若何去测试这些场景同样是问题关键。当然，空想的情形是真的具备这么多车载防火墙和管理平台进行交互，但在实验室环境下显然是不可能的，设备生产、设备存放、环境搭建、测试实行等操作本钱太高且效率太低，既要验证多设备场景，确保上线后不会涌现严重问题，又要认清现状、面对现实情形。在这种冲突与抵牾之中，急需寻求一种切实可行的测试方案，快速有效地办理实际问题。
03测试构想
车载防火墙与统一安全管理平台交互过程中涉及gatewayID和gatewayIP两个关键字段。个中，gatewayID表示车载防火墙唯一的ID标识；gatewayIP表示车载防火墙管理IP，也是与统一安全管理平台通信所利用的IP地址。单一改变gatewayID相比拟较随意马虎，无论是利用Python脚本还是shell脚本都可以实现。但是，对付集中管理平台而言还是只有一个IP地址与其通信，并且也不便于在管理平台上基于IP地址进行检索剖析。因此须要同时改变gatewayID和gatewayIP以更真实的场景来仿照不同的车载防火墙设备，进而得以验证同一韶光可以上线设备数量（新建速率）以及最多许可多少台设备同时在线（并发数量）。
04测试方案
搭建如图4-1所示的性能测试拓扑，个中Linux客户端可以修正上述gatewayID和gatewayIP，用于仿照多台车载防火墙与统一安全管理平台交互；三层交流机配置ETH0和ETH1于同一VLAN，如VLAN4093，接口VLAN-IF 4093配置多组IP地址，用于实现车载防火墙既可以和管理平台二层通信又可以进行三层通信，适应客户现场不同的组网环境。
图4-1 性能测试拓扑图
测试思路可以分为以下几个步骤：
（1）Linux客户端设定上线策略（如上线数量、上线速率、循环次数、延时等）
（2）Linux客户端修正接口IP地址，即gatewayIP
（3）Linux客户端根据接口IP地址修正gatewayID
（4）Linux客户端仿照车载防火墙上线
如图4-2所示，展示了一个基于shell脚本实现的实例，可以是物理机Linux，也可以是虚拟机Linux。
图4-2 性能测试实例
在测试统一安全管理平台日志剖析性能时，可以在上述根本上直接上传各种类型日志。但在履行过程中碰着新的问题，如图4-3所示，日志内容中GATEWAY_ID字段须要与上述gatewayID逐一对应，否则所有日志都只能关联到同一台设备上，影响下一阶段的日志查询与剖析。这里大家不妨先思考一下如何办理，欲知后事如何，且听下回分解。
图4-3 车载防火墙日志示例
