1. 车路云一体化里的“三张网”和绕不开的隔离需求前阵子帮一个车路云先导区的项目做边界安全评审对方开门见山就问我们已经上了防火墙为什么还要在路侧到云平台的链路上再加一台网闸和光闸这个问题如果放到三年前我大概会从合规要求讲起。但干过几个实际项目之后我更习惯直接打开一张现场网络拓扑图指着上面的V2X报文说因为防火墙允许“合法会话”而车路协同里恰恰有大量合法的UDP组播会话这才是攻击者最方便藏身的地方。这篇文章就把网闸和光闸在车路云一体化场景里的定位、原理、选型和踩坑经验一次说清楚。1.1 车路云一体化承载的是哪几类数据很多人把车路云一体化理解成“车连上网、数据上云”但真正落到网络架构上至少能拆出三张网车与路之间的通信网络。车辆通过OBU车载单元与路侧RSU路侧单元通信也有通过5G Uu口直接与平台通信的情况。车路之间的数据包括BSM基本安全消息、RSM路侧安全消息、SPAT信号灯相位与时序消息、MAP地图消息等。路侧到边缘的计算网络。路侧的摄像头、毫米波雷达、激光雷达、信号机和RSU会先汇聚到边缘计算节点。这一层流量大、协议杂视频流、点云数据、结构化V2X消息混在一起。边缘到中心云的骨干网络。边缘节点通过光纤专网或5G与中心云平台互联中心云负责全局调度、数据融合、AI训练和车路协同服务下发。这三张网的安全等级天然不同。车端和公共网络最不可信路侧边缘节点因为部署在开放道路旁、机房条件参差不齐可信度也不高中心云平台是整个系统的“大脑”安全要求最高。边界隔离解决的核心问题就是在这些不同可信等级的网络之间不让“低可信侧”的问题蔓延到“高可信侧”。还有一类数据很容易被忽略运维数据。边缘设备的登录管理、日志采集、固件升级都需要网络通路。很多车路云项目在规划时把业务数据和运维数据混在一起结果后面只能在网闸上临时开一堆端口。这个我在第四章会专门讲。1.2 为什么说“边界”在车路云里没有消失车路云一体化经常被描述为“分布式系统”于是有人觉得边界不存在了或者被软件定义网络虚拟化了。但物理现实是路侧机柜、传输专线、中心机房始终存在任何恶意流量要进入中心平台都得穿过某个物理点。边界并没有消失只是从原来的“单一边界”变成了层层递进的多级边界。边界只要存在就会有横向渗透问题。比如一个边缘节点被攻破攻击者可能利用边缘节点的合法IP直接向中心数据库发起请求把伪造的SPAT消息灌进去。真实问题不是攻击者能不能扫描到端口而是当合法通道本身可被利用时传统防火墙基本拦不住。车路协同又是典型的“数据敏感性”场景。一条伪造的SPAT消息能让车辆在路口收到错误的信号灯状态一段被篡改的高精地图数据可能影响路径规划。所以边界隔离设备要做的事情比“防扫描、防爆破”更深一层是让数据交换本身变慢、变可控、可审计。1.3 防火墙为什么替代不了网闸光闸先明确一点防火墙和网闸光闸不是竞品是不同层面的东西。防火墙的核心能力是包过滤和状态检测它关心“这个会话是否合法”建立会话表后在规定端口上放行。但防火墙默认信任通过端口的数据内容攻击者把恶意载荷藏进合法的GB28181视频流或者MQTT消息里防火墙很难识别。网闸和光闸改变的是数据交换模型。网闸通过协议剥离和异步摆渡让内外网之间不存在物理层以上的直接连接光闸干脆在物理层做到单向。它们更像是“数据检查站”而不是“路口交警”。所以很多希望满足高强度隔离要求的系统宁可多花几万块也要在防火墙后面再串一台网闸不是重复建设而是确实存在需求。还有一点很现实车路云项目的验收和合规审计中边界隔离设备的配置和日志是重要证据。没有网闸光闸你很难证明路侧到中心的数据交换做了强隔离。这一点在项目交付时尤其重要。2. 网闸和光闸到底是怎么“隔离”的原理层面的拆解讲场景之前先把原理捋清楚。很多选型错误归根结底是没搞明白这两种设备的工作方式。2.1 网闸“两套主机加一道旋转舱”网闸的经典架构是“21”也就是内网处理单元、外网处理单元加一个隔离交换单元。内网数据进入网闸后先被深度解析剥离TCP/IP头、剥离会话信息、把原始应用数据提取出来放到隔离交换单元的缓冲区。然后隔离交换单元通过一种“非网络连接”的方式把纯数据搬到外网处理单元由外网处理单元重新封装发送。这个过程中内外网处理单元之间没有网络线缆直连也没有任何一个时刻存在跨内外网的TCP/IP连接。数据像通过一个旋转传送舱在两个房间之间搬运人永远不能直接从房间A走到房间B。这种模式叫“协议代理异步摆渡”也决定了网闸不是简单转发设备它上面不配置路由配置的是通道规则。所以网闸天然有协议适配能力。文件、数据库、HTTP、音视频、通用UDP/TCP不同业务要启用不同的代理模块。这也是为什么我要强调“先熟悉业务协议再选型”网闸对业务的理解程度直接决定它能跑多好。生活里最接近的例子是机场安检的行李传送带传送带上能过箱子但人不能直接走过去传送带两端的控制系统互不连通。网闸就是把“行李”从低安全侧运到高安全侧途中把看起来可疑的东西筛掉。2.2 光闸单向性写在硬件里光闸的原理比网闸更直接。它利用光纤通信的单向发光特性发送端有光发射模块接收端只有光接收模块光纤链路里的信号只能从一个方向走反方向物理上就没有通路。正因如此光闸的反向攻击风险趋近于零发送端即使被完全攻陷也没法主动向接收端发起任何网络请求连TCP握手都做不到。这带来一个重要结论光闸不是“配置成单向”而是“设备本身就是单向的”。你需要从接收端向发送端传数据必须再铺一条反向光路并且通常要单独布置一套光闸设备或者用网闸顶替反向通道。有些项目最后做成“一套光闸正向传视频一套网闸双向传信令”就是被这个物理限制逼出来的。性能上光闸因为少了一层协议重建逻辑单向转发时延一般比网闸低。但这不意味着光闸可以“裸奔”用在所有场景视频流、文件同步、结构化消息都要有对应的数据适配模块否则光闸管理端只能看到一条物理光路在跑里面的内容格式对不对、丢帧多不多都很难感知。注意光闸的反向通道需要单独成对部署不是软件开个开关就能解决的。2.3 一张表看懂网闸和光闸的差异直接把关心的几个维度列出来选型时对着看对比项网闸光闸工作层次应用层代理协议剥离物理层单向传输数据方向双向异步摆渡物理单向需成对布置反向典型时延毫秒级取决于代理模式微秒到百微秒级视协议适配单机吞吐百兆到数十Gbps均有单纤可达数Gbps到数十Gbps反向安全双向都有攻击面但难以实时穿透反向物理隔离攻击面极小组播支持通常不支持需组播转单播或前置转换通常不涉及组播概念适用场景双向业务、数据库同步、请求-响应高吞吐单向采集、视频上传、日志汇集注意表里的“组播支持”一栏现实中很多V2X消息是UDP组播而网闸的标准工作模式是处理“点到点”业务。遇到组播要么在网闸前面做一次协议转换要么找支持组播代理的厂家定制这个坑我在第四章详细展开。3. 实地部署车路云场景里网闸和光闸放在哪、怎么选型很多技术方案书把网闸和光闸写得很简单好像“边缘放一台、中心放一台”就完了。真正部署时才发现数据流向、协议种类、性能余量、运维通道每一项都是问题源头。我的经验是先把数据流画清楚再谈设备。3.1 先画一张车路云数据流矩阵我每到一个项目第一件事不是看方案而是拉着路侧和平台两边的人把数据流整理成一张表。按“业务方向”和“数据类型”两个维度看上行数据路侧到中心路侧视频流、雷达点云、RSU上报的BSM/RSM/SPAT/MAP、信号机状态、设备日志。下行数据中心到路侧信号灯配时方案、高精地图更新、RSU参数配置、AI模型包、远程运维指令。把每个数据项标上“协议、带宽预估、时延要求、方向”。这步做完选型基本就清晰了。比如视频流是持续单向大流量适合走光闸信令控制是双向小流量适合走网闸高精地图更新是低频大文件走文件同步通道即可。还有一个容易漏掉的分支中心平台内部不同安全域之间的数据交换。比如前置区到数据区、数据区到应用区也需要隔离。这个用网闸做数据库同步和文件交换比较常见光闸一般用不到。3.2 我推荐的一种典型拓扑光闸扛大流量网闸走信令在我参与过的一个车路协同项目中最终落地的是“高低速分离”拓扑。路侧边缘节点把本地设备汇聚后分两路接入中心一路是光闸负责视频流、点云和结构化V2X消息的正向上传另一路是小带宽双向网闸负责控制指令、配置下发和运维通道。这样的好处很明显视频这种持续大流量即使被恶意代码污染也只能“出”、不能“进”中心侧不会被视频链路上的攻击反向侵入信令和控制通道数据量小可以用深度包检测和协议白名单做严格限制。代价是成本和运维复杂度上升两套设备都要维护但车路云这种对安全等级要求高的场景我认为值得。如果项目预算有限、风险等级不高那么用一台双向网闸把上行下行都包了也能跑。但前提是搞清楚网闸的吞吐和协议能力别把视频和信令混在一个通道里否则高峰期很容易把视频拥塞传导到控制通道。3.3 选型时重点盯住这几个硬指标很多厂商喜欢宣传“最大吞吐10G”但实际项目里光看这个数是不够的。我建议至少核对以下几项双向还是单向吞吐。大部分网闸标的是双方向总吞吐你要算的是上行视频点云的总带宽最好留出1.5到2倍余量。比如50路1080p视频单路按4Mbps算总带宽200Mbps不考虑其他数据选一台最低500Mbps吞吐的网闸才稳妥。每秒新建连接数。车路云的路侧设备可能成千上万台同时接入尤其车辆OBU上报消息是高频突发。如果网闸新建连接能力弱高峰期可能出现消息排队。协议代理能力。V2X消息是UDP组播还是单播视频是GB28181还是RTSP数据库同步是Oracle还是MySQL先把这些列成清单让厂商逐项确认而不是只听“全协议支持”的宣传。高可用。双机热备是否支持会话同步切换时间多少有没有独立的健康检查链路很多网闸默认只做心跳不做事后同步主备