★ FEATURED ARTICLE 做网络隔离项目这些年被问得最多的一句话就是我都有防火墙了还上网闸干什么问这话的人里有刚接手机房运维的新人也有干了七八年的老网工。这个问题背后其实藏着一个很实在的分歧防火墙解决的是能不能过的判断题而网闸解决的是物理想连都连不上但数据还得过去这个矛盾题。这两件事压根不在一个维度上。安全隔离网闸行业里一般简称网闸学名安全隔离与信息交换系统。它的核心价值不在于拦攻击而在于用物理层面的断换来逻辑层面的通让两个本来绝对不能互通的网络之间能以一种被严格约束的方式交换数据。这篇文章我打算把网闸的原理掰开揉碎讲清楚重点讲它为什么这么设计、数据到底怎么摆渡过去、选型时那几个参数怎么算、以及实际部署中那些文档里不会写的坑。刚接触这块的朋友可以当入门科普看正在做方案的老手可以直接跳到第 4、6、7 节看参数和排查。1. 先想清楚网闸到底在防什么1.1 防火墙拦不住的那半张网很多人对边界安全的认知停留在防火墙 入侵检测 杀毒这三件套上。这套组合在互联网边界确实够用但它有一个前提假设两边的网络是可以互相通信的我只是决定哪些流量放行。防火墙工作在 TCP/IP 协议栈的三层到七层无论多严格它本质上还是一个转发设备转发的前提是两端存在一条可用的连接通道。问题就出在这条通道上。只要通道存在就有被利用的可能协议栈漏洞、旁路绕过、配置失误导致的规则失效、加密隧道里夹带的东西、零日漏洞打穿应用层。防火墙的规则越复杂出错的概率越高。而工控网络、涉密办公网、医疗核心业务区这些地方恰恰是一次都不允许出事的场景靠规则写得足够好来保证安全这个赌注下得太大。1.2 物理隔离的诱惑与代价最彻底的安全手段当然是物理隔离——两台机器不插同一根网线谁也别想碰谁。早年不少单位真的这么干内外网各一套机器U 盘拷来拷去。但这么做的代价很快就显现出来了数据同步靠人跑慢、易错、不可审计U 盘本身成了最大的病毒载体摆渡病毒这个说法就是这么来的业务上要求实时数据回传的场景人工根本顶不住。所以真实的诉求是一个悖论既要物理上的不通又要数据上的通。安全隔离网闸就是为解这个悖论而生的产品。它不试图判断这个连接该不该建立而是干脆不建立连接用中间的一台专用设备把数据搬过去搬的过程中把外壳剥掉只留内容。1.3 四种边界设备的本质差别新手最容易混淆的就是防火墙、网闸、单向光闸和数据交换平台这四类东西。它们的差别不在性能参数上而在设计哲学上。我整理了一张对照表这个表建议收藏做方案时跟甲方讲清楚能省很多口舌设备类型连接方式数据形态典型时延适用判断防火墙建立真实 TCP 连接按规则转发原始报文原样通过微秒级可信网络之间的访问控制安全隔离网闸两侧独立会话中间断开应用层摆渡剥离协议外壳后传内容毫秒到百毫秒不同安全域之间必须交换数据单向光闸光纤单向发送物理无回传通路只进不出或只出不进毫秒级数据只需要单方向流动数据交换平台通常部署在网闸之上做业务编排业务对象、文件、消息取决于下层多业务、多协议的复杂交换这张表里最关键的一行是网闸那行的中间断开。防火墙和网闸的差别不是规则严不严而是是否存在一条端到端的连接。网闸这条连接是被物理或逻辑上切开的两侧的 TCP 会话各自终结在网闸自己的两个主机上谁也看不到谁。这一点想明白了后面所有的设计就都顺了。防火墙能通我在通路上设关卡网闸不通但我在断点上设搬运工单向光闸根本没法通回来发出去就收不回2. 核心架构拆解那个21到底是什么2.1 双主机加隔离交换单元绝大多数网闸的硬件形态是21结构两块独立的主机板业内叫内端机和外端机中间夹一个专用的隔离交换单元。内端机接内网外端机接外网中间那块板子只做数据搬运不参与协议处理。这个结构不是简单的三块板拼在一起。内端机和外端机是两套独立的操作系统、独立的内存、独立的存储没有任何共享资源可以直接访问。它们之间唯一的物理通路就是中间的隔离交换单元而这个单元在任意时刻只与其中一侧建立连接。也就是说当内端机往隔离单元写数据时外端机在物理或电气上是断开的写完了切换外端机才来读。这个分时切换是网闸区别于所有其他安全设备的根本特征。有人会问切换频率是多少这个参数各家不一样常见的是在微秒到毫秒量级完成一次切换。切换太慢吞吐上不去太快了又容易让两侧出现准连接状态。这也是为什么网闸的时延天生比防火墙高一个数量级——物理上就没法做到零切换开销。注意隔离交换单元不是一块简单的存储芯片。如果只是共享一块存储两侧能同时读写那本质上还是一台双网卡主机安全等级差得远。判断一个产品是不是真网闸看它有没有独立的双主机和单向切换的隔离单元这一条基本能筛掉一批伪网闸。2.2 私有协议把标准协议栈彻底扔掉防火墙转发的是标准 TCP/IP 报文网闸不转发。数据从内端机进来之后内端机会做三件事终止会话、剥离协议、内容还原。剥完之后原始报文里那些 TCP 头、IP 头、各种标志位全被丢掉只留下纯粹的内容比如一个文件的字节流、一条数据库记录、一段 JSON。留下内容之后内端机用一套自己定义的私有协议重新封装交给隔离单元。外端机读出来再用私有协议解包按目标侧的协议重新组装成一个全新的请求发出去。整个过程里两侧没有任何一个字节是原样穿过去的。这个设计的精妙之处在于攻击者在内网侧伪造一个畸形报文希望它穿过边界打在外网的服务器上这个想法在网闸这里彻底失效了因为那个报文的外壳根本没被带过去。想攻击得先攻破内端机的协议解析模块再攻破私有协议本身再攻破外端机的重组模块——三道关且每一道的攻击面都比通用协议栈小得多。代价也很明显任何协议都得单独适配。SMB、NFS、FTP、Oracle、MySQL、OPC、Modbus、HTTP API、邮件每一种都得有对应的代理模块。这就是为什么网闸产品在选型时要重点看支持多少种协议以及自定义协议能不能二次开发。2.3 数据摆渡的完整生命周期把上面两步串起来一条数据的完整旅程是这样的内网主机发起请求TCP 会话在内端机上终结不存在端到端连接内端机的代理模块解析请求做身份认证、内容过滤、病毒扫描、格式校验通过校验的数据被打包成私有格式写入隔离交换单元的缓冲区隔离单元切换通道外端机读取缓冲区外端机解包用目标协议重新发起请求响应数据走反向的同样流程这个流程里第 2 步是安全能力最集中的地方。文件类型白名单、关键字过滤、病毒查杀、文件完整性校验、大小限制、传输频率限制全在这一步做。很多项目的实际效果差问题往往出在这步的策略配得太松——什么类型都放什么关键字都不拦那网闸就退化成了一个带延迟的路由器。第 3 步的缓冲区管理也很讲究。缓冲区满了怎么办丢数据还是阻塞这个行为在不同产品上不一样一定要在测试环境里压测确认。有的产品缓冲区满后会静默丢弃前端只看到发成功了后端根本没收到这在生产环境里是灾难级的隐患。2.4 协议剥离与内容还原的实际效果举个具体例子说明剥离到底剥掉了什么。假设内网侧要往外网侧发一个 HTTP 请求POST /api/upload HTTP/1.1 Host: target.example Content-Type: application/octet-stream Content-Length: 10240 Cookie: sessionxxxx [10240 字节的二进制内容]网闸的内端机会把这个请求完全解构方法、路径、头部字段、body 内容分别提取出来Cookie 这类会话信息通常会被丢弃因为外端机会用自己的一套凭据重新认证。Body 内容会经过文件类型检测不是看扩展名是看文件头魔数、病毒扫描、大小校验。全部通过后只把 body 内容和必要的元信息目标路径、文件名打包成私有格式传过去。外端机收到后用自己配置的外发凭据重新构造一个 HTTP 请求发给目标服务器。目标服务器看到的请求来源是外端机Cookie 是外端机的跟内网那台机器没有任何关系。这里有个容易踩的坑如果目标服务依赖内网侧特有的认证信息比如某个特定的 token而网闸把 Cookie 剥掉了请求就会失败。解决办法是在网闸的策略里配置头部透传白名单只放行必要的字段。但这个口子不能乱开透传的字段多了剥离的意义就打折了。3. 单向传输与文件交换怎么落地3.1 单向导入与双向代理的选择网闸按数据流向大致分两种工作模式选错模式是方案阶段最常见的失误。单向传输模式业内也叫单向导入或单向导出数据只能从一个方向走。内网往外网发外网就绝无可能往里发。这种模式通常配合单向光闸使用物理上就没有回传通路安全等级最高。适合日志外发、监控数据上报、镜像数据推送这类只需要出去的场景。双向代理模式两个方向都能走但每个方向都是独立的摆渡不是一条双向的连接。这是绝大多数项目的实际选择因为业务上往往既需要下发指令又需要回收结果。这里要说一个真实的认知误区很多人觉得双向代理就等于能互访了为了图方便把所有端口都开成双向。这是极其危险的做法。正确做法是按业务最小化开放比如文件上传只开内到外回执只开外到内且限定为特定格式的小消息。我在一个项目里见过有人为了省事把整个网段都放通了结果网闸的性能被广播流量拖垮还带来了一堆无谓的告警。3.2 文件交换的完整链路与校验文件交换是网闸用得最多的功能也是坑最多的功能。一条完整的文件交换链路至少要保证四件事传得过去、传得完整、传得安全、出了问题查得出来。传得完整靠的是校验机制。我一般建议在三个位置做校验源端生成文件时记录 MD5 或 SHA256网闸落盘后计算一次比对目标端接收后再算一次。三次全对才算真的传成功了。只依赖网闸自己的日志说传输成功是不够的因为日志里的成功可能只代表摆渡环节走完了不代表目标端真的落盘正确。传得安全靠的是多道关口文件类型白名单只允许业务真的需要的扩展名配合文件头魔数检测防止改扩展名绕过大小上限单文件限制总量限制防止大文件把缓冲区撑爆病毒扫描接入杀毒引擎但要注意扫描会显著增加时延内容过滤关键字、正则、敏感信息识别防止夹带不该传的东西频率限制防止某个业务把带宽占满查得出来靠的是日志。日志字段至少要有时间、源 IP、目标 IP、文件名、大小、哈希值、各道检查的结果、最终状态。少一项事后排查就多一天。3.3 数据库同步与 API 代理的适配要点数据库同步是另一大主力场景。网闸的做法不是让两边直接连数据库而是在内端机和外端机上各跑一个数据库代理中间通过私有协议同步变更。这里最关键的是增量识别机制。常见的有三种基于时间戳字段、基于自增 ID、基于数据库日志解析。时间戳最简单但容易漏数据同一秒内的多条记录、时钟不同步自增 ID 可靠但要求表结构配合日志解析最准但适配成本高。选哪种取决于业务对数据一致性的要求如果只是报表数据时间戳够用如果是账务类数据必须上日志解析。API 代理相对简单本质上是把 HTTP 请求拆解后重新发起。难点在于有状态接口。如果目标接口依赖会话保持比如先登录拿 token再带 token 调业务接口网闸就得维护一个会话映射表把内网侧的会话和外网侧的会话对应起来。这个映射表有超时机制超时后会话失效业务会报未登录。排查时看到这种报错先去看网闸的会话超时配置多半是配短了。4. 部署形态与选型参数怎么算4.1 串联部署的位置与拓扑网闸必须串联在两个安全域之间这一点没有商量余地。旁路部署只适用于流量镜像分析类设备网闸做的是阻断加摆渡旁路挂上去等于没装。典型拓扑是内网核心交换机出一个口接内端机外端机接外网的接入交换机两侧各自配独立的 IP 段和路由中间不存在任何三层可达路径。内网侧看到的下一跳是内端机外网侧看到的下一跳是外端机两侧的路由表里都不会出现对端的网段。部署位置上有一个经验判断网闸应该尽量靠近数据源或数据目的地而不是放在两个大网的核心之间。原因很实在——摆渡是有成本的链路上任何一个环节的抖动都会放大成业务侧的失败。放得越靠边经过的中间设备越少故障定位越容易。4.2 吞吐、并发、时延三个硬指标的计算选型时最容易被销售话术带偏的就是吞吐量。标注的1Gbps 吞吐通常指的是大包、无过滤、理想条件下的裸转发能力。真实业务里小包为主、开了病毒扫描和内容过滤实际吞吐可能只有标称值的 20% 到 30%。我一般按下面这个思路倒推第一步算业务峰值流量。假设每天要交换 500GB 文件业务集中在 8 小时内完成那平均速率约 17MB/s峰值按 3 倍算约 52MB/s换算成带宽大概 420Mbps。这只是文件流量。第二步加上协议开销。文件交换之外还有数据库同步、API 调用、日志外发这些流量小但包多对新建连接数的要求高。经验上给文件流量留 30% 的余量总需求约 550Mbps。第三步按功能开销打折。开了病毒扫描吞吐按 50% 折开了内容过滤和关键字匹配再打 8 折。所以真正需要的标称吞吐是 550 / 0.5 / 0.8 ≈ 1375Mbps。这时候选千兆设备就不够了得上万兆或者双机负载。第四步算并发和新建速率。数据库同步和 API 代理最吃这个。假设有 200 个业务系统每个系统平均 20 个并发连接就是 4000 并发。新建速率按每秒 500 个算这个指标很多产品手册里藏得很深要专门问厂家要测试报告。延迟方面网闸单次摆渡的时延通常在 1ms 到 50ms 之间取决于文件大小和检查项。如果业务是交互式的比如页面查询时延超过 200ms 用户就会有明显感知这时候要考虑减少检查项或者把交互式业务单独走一条策略。4.3 高可用与集群的问题单台网闸是典型的单点故障。生产环境一般要做双机热备主备之间的切换靠心跳线切换时间通常在秒级。这里有个细节要注意主备切换后正在传输的大文件会中断需要业务侧支持断点续传或者整体重传。如果业务不支持就得考虑集群方案让文件传输任务能在节点间漂移。集群还有个隐藏问题如果两台设备之间没有做状态同步切换后原有的会话全部失效依赖会话的业务会集中报错。这种故障在切换瞬间看不出来往往在切换后几分钟内业务侧告警才爆发出来。做方案时一定要问清楚厂家会话状态是否同步同步的粒度是什么。5. 几个真实场景的落地方案5.1 生产网与办公网之间的数据交换某制造企业的车间生产网和厂区办公网之间要交换工艺参数和质检报告。生产网侧是工控设备协议以 Modbus 和 OPC 为主办公网侧是常规的 Windows 文件共享和一套 MES 系统。方案上生产网侧不直接暴露任何共享服务由网闸的内端机主动去采集工控设备的数据转换成文件或者数据库记录摆渡到办公网侧再写入 MES。反方向办公网下发的工艺参数先落到网闸外端机的缓冲区由内端机定时拉取后写入工控数据库。这里的关键设计是采集和下发都做成拉模式让内端机主动去拿而不是被动接受推送。这样生产网侧永远不监听任何外部端口攻击面降到最低。代价是实时性差一点靠轮询间隔控制实际配的是 30 秒一次业务上完全能接受。5.2 影像数据的外送某医疗机构的影像系统要和区域平台做数据对接。影像文件动辄几百兆一天几千份量非常大。同时这类数据敏感度极高不能有任何闪失。方案上用了单向导出加人工审核的混合模式内网侧生成影像文件后先进入待审队列由专人抽样确认确认通过的文件才由网闸单向导出到外网侧的上传区外网侧的上传服务再去推送到区域平台。这样即使内容检查有遗漏还有一道人工关口。性能上做了两个优化一是大文件分片摆渡避免单个大文件占用缓冲区太久二是按优先级排队急诊影像走优先队列常规体检影像走普通队列。这个优先级机制在业务高峰期救过好几次场。5.3 研发网络的文件单向导入某研发团队的内网不允许访问外部但需要定期从外部获取公开的技术资料和依赖包。做法是外网侧有一个下载区资料先进下载区再由单向光闸推进内网。单向光闸在这里比网闸更合适因为需求本身就是单向的内网根本不需要往外发任何东西物理单向能从根上杜绝数据外泄。内网侧配一个自动同步服务定时扫描接收目录新文件落地后自动分发到各研发环境。这一套下来既满足了研发的资料需求又保证了内网绝对不与外部连通。6. 配置实操从零配一条文件交换策略6.1 基础网络与路由配置先把两侧的基础网络配通注意这里是各自配通不是互相配通。内端机配置示例伪配置各家命令不同逻辑一致# 内端机内网口 interface eth0 ip address 10.10.20.1 255.255.255.0 description to-internal-core-switch no shutdown # 内端机不配置任何指向外网的默认路由 ip route 10.10.0.0 255.255.0.0 10.10.20.254 # 关闭所有非必要服务 service telnet disable service ftp disable service ssh enable外端机同理配置自己的外网地址和路由路由表里不会出现 10.10.0.0/16 这个内网段。这个路由互不可见是验证部署是否正确的最快方法——从外端机 ping 内网任意地址必须不通通了就说明配错了。6.2 交换策略与白名单配置策略配置的核心是最小化。以下是一条文件交换策略的配置逻辑policy: name: 质检报告外发 direction: internal_to_external # 单向不允许反向 source: ip: 10.10.20.50 # 只允许这一台源主机 path: /data/qc/report/*.pdf # 路径和扩展名双重限定 target: ip: 172.16.30.20 path: /upload/qc/ checks: file_type_whitelist: [pdf] # 扩展名白名单 magic_number_check: true # 文件头魔数校验 max_file_size_mb: 50 virus_scan: true content_regex: [身份证号, 手机号] # 命中即拒绝 rate_limit: files_per_minute: 60 bandwidth_mbps: 200 schedule: 08:00-20:00 # 只在这些时段允许这份配置里有几个细节值得说。magic_number_check是必须开的因为只查扩展名太容易被绕过把 exe 改成 pdf 就能混过去。content_regex用来拦截敏感内容但要注意正则的性能开销规则写得太复杂会严重拖慢处理速度。schedule这个时效控制很多人不配实际上很有用非工作时间的传输往往是异常的。6.3 日志采集与审计对接日志一定要外送到独立的日志服务器不要存在网闸本地。原因有两个一是网闸本地存储有限写满了会影响业务二是万一设备被攻破本地日志第一个被删。日志外送本身也要走网闸的摆渡通道形成一个闭环。外送内容至少包括策略命中记录、文件传输记录含哈希、检查拒绝记录、管理登录记录、配置变更记录。其中配置变更记录最容易被忽视但出事之后这是最关键的一条线索——是谁在什么时候改了策略。审计对接方面把网闸日志接入统一的日志分析平台配几条基础告警规则单位时间内拒绝次数突增、非工作时间有传输、某个源 IP 的传输量异常放大、管理账号异地登录。这四条规则能覆盖大部分异常情况。7. 常见问题排查实录下面这张表是我这几年攒下来的基本上现场遇到的八成问题都能在里面找到方向现象优先怀疑排查动作处理方式文件显示发送成功但目标端没有缓冲区满后静默丢弃查网闸缓冲区水位和丢弃计数调大缓冲区或降低发送速率传输速度只有标称值的两成小包为主 检查项过多看包大小分布逐项关闭检查对比精简检查项或升级设备大文件传输到 90% 卡住单文件超时或缓冲区限制查超时配置和分片阈值开启分片或调大超时数据库同步丢数据增量识别用时间戳同秒数据被覆盖比对源表与目标表的记录数改用自增 ID 或日志解析API 调用报未登录会话映射表超时查会话超时配置调长超时或改无状态接口切换后业务集中报错主备会话状态未同步查切换日志和会话表升级为状态同步版本某个业务突然不通源 IP 变更但策略未更新对比策略白名单与实际源地址更新白名单建立变更流程时延忽高忽低病毒扫描引擎在扫描大文件看 CPU 和扫描队列错峰传输或调整扫描策略除了表里的还有几个排查思路值得单独说。先分段再定位。文件传不过去第一步不是去翻网闸日志而是确认问题在哪个环节源端有没有发出去、网闸有没有收到、网闸有没有摆渡、目标端有没有收到。很多产品能看到每一段的计数对着看就知道卡在哪。我见过太多人一上来就怀疑网闸结果查了半天发现是源端程序自己的 bug。用最小化策略复现。策略配得复杂的时候出了问题最好的办法是临时建一条最简单的新策略只放通这一个源 IP 到这一个目标 IP 这一个端口别的检查全关。如果通了说明是策略配置问题逐项往回加如果不通说明是网络或设备问题。这个二分法比盯着日志猜快得多。注意时区和时钟。这个坑我踩过。两侧设备的时钟不同步日志时间对不上明明是一条完整链路的三段日志看起来像是发生在三个不同时间。排查任何跨设备问题之前先把 NTP 配好这一条能省掉大量误判。别忽略看起来无关的流量。有一回某个业务死活同步不了数据库查了两天最后发现是那个业务系统启动时会向另一个网段发一个心跳包那个网段没开策略网闸把整个会话给拦了。这种问题的特征是业务日志报的是超时但网闸日志里没有对应的拒绝记录遇到这种情况要去抓完整的会话看看有没有前置的探测流量在拖后腿。8. 选型和使用中的几个实在经验关于选型我最想说的一点是别只看吞吐量看协议支持清单和二次开发能力。一个项目里如果有个小众协议厂家说不支持但可以开发那这个开发周期和小版本号的稳定性比标称吞吐量重要得多。我见过太多因为协议不能适配而整个方案推倒重来的情况。关于伪网闸的识别有几个快速判断方法。问厂家三个问题隔离交换单元是不是独立硬件、两侧主机的操作系统是不是独立安装、有没有可验证的物理切换机制。这三个问题答不清楚的或者含糊其辞说逻辑隔离的基本可以排除。真网闸不怕被问这些。关于运维我的建议是把网闸当成一个业务系统来管而不是一个网络设备。网络设备配好了基本不用动网闸的策略是跟着业务走的业务一变策略就得变。所以要有变更流程、要有策略评审、要定期做策略清理。我接手过一个项目里面堆了三百多条策略作者都离职了没人知道哪条还有用最后只能一条条试出来。这个教训挺贵的。最后说个容易被忽视的点网闸本身的补丁管理。很多人把网闸装上就忘了它也是台设备也有操作系统也需要打补丁。但网闸又往往部署在离线环境里补丁更新很麻烦。实际做法是建立一个季度更新窗口把设备下线如果是双机就切到备机用离线的补丁包更新更新完做一轮回归测试。麻烦是麻烦但比出了漏洞被通报要强。还有个小技巧分享一下。做双向代理方案的时候我习惯在两侧都部署一个小型的自检脚本每隔五分钟往对端发一个固定内容的测试文件然后校验回执。这个测试文件的传输记录直接在日志平台上看曲线一旦中断或者时延突增十分钟内就能发现比等业务报障快得多。脚本很简单二十行 Python 就够了但省下来的排查时间非常可观。import hashlib, time, os, requests TEST_PAYLOAD bnetgap-heartbeat- str(int(time.time())).encode() def heartbeat(target_url, token): try: r requests.post( target_url, dataTEST_PAYLOAD, headers{X-Token: token}, timeout30, ) if r.status_code 200: return True, r.elapsed.total_seconds() return False, r.status_code except Exception as e: return False, str(e) if __name__ __main__: ok, info heartbeat(http://172.16.30.20/probe, probe-token) print(f{time.strftime(%Y-%m-%d %H:%M:%S)} status{ok} detail{info})这个东西不追求功能多强追求的是简单可靠、不依赖任何三方库之外的组件。部署上去之后网闸这条链路的可用性从被动发现变成了主动感知这个转变对运维心态的影响其实挺大的。
阅读完成 · 觉得有帮助？
