简介天融信网络卫士TopRules技术培训PPT由应用交付产品部张凌云于2012年7月主讲面向网络安全工程师、网闸实施与运维人员旨在帮助读者系统掌握安全隔离与信息交换技术。内容从隔离技术起源、协议隔离与防火墙区别讲起梳理我国隔离政策要求与网闸技术的四个发展阶段随后详解TopRules产品线万兆、千兆、百兆、单向网闸以TR-71166为例说明2U机架、接口数、吞吐量、时延与并发数等性能指标并覆盖访问控制、内容过滤、Web/FTP/邮件/数据库应用控制、文件同步与自定义应用等业务功能突出21系统架构、多机协同与高强度安全防护特色。应用案例与FAQ部分给出了实际部署场景和常见问题解答便于对照学习。资源为单个PPT演示文稿共1个文件大小1.16MB适合技术培训、方案汇报和产品功能梳理。目前已有72人学习下载可作为掌握天融信安全隔离与信息交换系统原理及应用的重要参考。1. 天融信TopRules安全隔离与信息交换系统不是防火墙是“没有路的摆渡船”做过等保三级或者涉密内网项目的工程师应该都遇到过一个被审计逼到墙角的需求内网核心区不能和外部网络有任何TCP/IP连接但业务又必须每天从外网同步数据进来。拿U盘拷被批“物理隔离形同虚设”开个防火墙端口放行又被测评机构直接判不合格。这时候就该上一台安全隔离与信息交换系统业内直接叫网闸。天融信网络卫士TopRules就是这类设备里比较常见的选型名字听起来长本质干的事就一件把网络切成两段数据靠“摆渡”过去而不是靠“通路”传过去。这篇笔记就按我落地过的经验把TopRules的原理、部署、参数和坑一次性讲透适合做集成项目、运维边界设备和过等保评测评的工程师参考。2. 双主机加私有协议TopRules凭什么敢说自己“物理隔离”2.1 先搞懂网闸和防火墙、堡垒机的本质差别很多项目启动会上业务方会问一句我们已经买了防火墙为什么还要再买一台网闸这个问题我在三个项目里被问过每次都得把三者边界重新捋一遍。防火墙的本质是“过滤”它在同一条网络通路上做TCP/IP层面的访问控制数据包从eth0进来经过规则匹配再从eth1出去物理上链路是通的。堡垒机是“运维审计”它管的是人不是数据解决的是谁敢登录服务器、敲了什么命令。而TopRules这类安全隔离与信息交换系统的本质是“断开”内网主机和外网主机之间没有IP通路只有专用的隔离交换硬件在里面做数据摆渡一个包都不可能直接穿过。三者的关系我习惯用一张表给客户解释设备类型对外表现工作层次隔离强度典型应用防火墙有路设卡查车L3-L4部分L7逻辑隔离办公网到DMZ区访问控制堡垒机有门查人证件应用层运维协议人为管控运维人员登录服务器审计TopRules网闸没有路只有摆渡船私有协议剥离TCP/IP物理隔离涉密网/内网与外部交换数据这个表在跟客户讲方案时特别好用一句话浓缩防火墙是在马路上设卡网闸是直接把路挖断只留一条摆渡船过河。TopRules所有数据交换都以“任务”为单位——管理员先定义好谁可以从哪边把什么数据摆渡到哪边设备才执行对应动作而且执行过程中要完成协议剥离、内容过滤、防病毒查杀再在另一端重组会话。2.2 TopRules的硬件构造和“21”逻辑TopRules的整机逻辑是典型的“21”架构内网主机、外网主机、中间隔离交换单元。内网主机连接核心业务内网外网主机连接外部信任网络中间单元是专用硬件不跑通用操作系统不接受任何TCP/IP连接只按固件逻辑完成数据的单向或双向摆渡。实际部署时很多新手会犯一个认知错误以为网闸是一台设备所以只需要一个IP、一个管理界面。真实情况是内网主机和外网主机分别有独立的管理地址、独立的路由表、独立的策略配置两个主机之间永远无法通过管理口互相ping通。登录管理界面时你需要分别登录“内网主机管理口”和“外网主机管理口”在很多型号上两个主机的Web管理界面长得几乎一样但配置内容完全不同千万不能搞混。这就引出一个选型层面的建议测试阶段如果暂时买不起真机天融信部分产品线提供vmware镜像的虚拟化形态可以先在测试环境里把通道逻辑跑通再上真机做物理部署。虚拟化镜像和真机的通道配置思路一致只是硬件摆渡部分由软件模拟适合先练手和给客户做POC演示。2.3 数据摆渡的完整路径一个文件怎么“过河”举一个最常见的文件交换场景外部办公网有一批文件要同步到内网核心区。数据走完的完整路径如下外部客户端把文件推到外网主机的接收目录外网主机侧的策略引擎先做文件类型识别、杀毒扫描、敏感词过滤通过后写入临时存储区。中间隔离交换单元按设定的周期或事件触发主动“抓取”临时区的数据通过私有协议摆渡到内网主机侧。内网主机再按通道配置把文件写落到内网目标服务器上。整个过程中外网主机和内网主机始终没有建立任何TCP连接两端的业务系统甚至感知不到对方的存在。这条逻辑路线听起来不复杂但它决定了后续所有配置的走向配置TopRules本质上是配置“两端主机的网络参数”和“中间交换单元的摆渡任务”。我在项目中见过不少人在这个地方翻车——把网闸当成防火墙去配NAT、配端口映射折腾半天发现数据根本过不去原因就是路径理解错了——网闸不是把数据“转发”过去而是“搬运”过去。3. 把TopRules跑通的最小步骤上架、接线、建通道3.1 物理上架和网络规划三种最常用的接入模式拿到TopRules设备之后第一件事不是登录Web管理界面而是想清楚这台机器怎么接入现有网络。我在集成项目里见过的最常见方案有三种。第一种是串接在两个网络中间。比如政务内网和政务外网的边界内网主机接内网核心交换机外网主机接外网前置交换机业务数据全部经网闸摆渡。这种模式隔离强度最高但链路故障会影响两端业务必须考虑双机热备。第二种是代理模式。外部网络不直接访问内网而是先访问外网主机的某一个IP端口由外网主机把请求“变成任务”摆渡给内网主机内网主机再去访问真正的内网服务器适用于门户网站和邮件系统。第三种是数据库同步模式。拓扑上和第二种类似但交换的对象不是文件或HTTP请求而是数据库查询结果集。接线时最关键的一条经验管理口和业务口一定要分开不要图省事把管理口也接到业务交换机上。管理口IP单独规划一个管理网段平时配置和维护都走管理口业务口按实际业务规划IP两端主机完全独立。如果管理口和业务口混在一起一旦业务侧网络有风暴或者异常流量管理界面会直接卡死连应急处理的机会都没有。3.2 初始配置流程分左右别乱配TopRules首次通电后默认管理地址一般会标注在设备面板或快速入门手册上这里不写具体的默认地址因为不同硬件批次出厂设定不一样。登录后首先改管理员口令然后分别登录内网主机和外网主机的管理界面做三层基础配置。第一步是配置两端的网络接口。内网主机配上内网网段的IP、掩码、网关外网主机配上外部网段的IP、掩码、网关。这一步看起来简单但坑在容易把两端的IP规划成同一个网段——在串接模式下内网主机和外网主机必须属于不同广播域否则管理界面虽通但数据通道建立时会出现路由混乱。第二步是做路由配置。如果内网侧有多个业务网段内网主机上要加静态路由指向内网核心交换机外网侧同理。很多项目配到这一步就认为是“网络通”了但这里有个验证动作值得做分别从两端主机的管理界面做连通性测试内网主机ping内网核心交换机的业务网段网关外网主机ping前置机的网关。两端各自能ping通即可绝对不要尝试让两个主机互相ping通这是架构上被禁止的。第三步是配置通道这是整个TopRules最核心的内容也是最容易被忽视的环节。3.3 最小可用的文件交换通道一步步点出来的作业我一般用一个“最小文件交换任务”来向新人演示TopRules怎么用外部办公网的一台FTP服务器实际是往网闸外网主机的某个落盘目录推送摆渡到一个内网的文件接收服务器。在TopRules的Web管理界面里配置路径通常是“通道配置-新增通道”。通道参数里需要填写这么几项通道名称、数据方向这里选“外网到内网”、源地址外网主机的接收目录所属地址对象、目的地址内网主机要投递到的目标服务器地址、应用类型选FTP或SFTP。填完之后还要在通道下挂具体的“任务”任务类型选文件交换源目录填外网主机上共享给业务方的接收目录目标目录填内网侧目标服务器的落地目录再同步频率上选周期同步还是实时触发。一个典型的最小配置参数如下参数项推荐值说明通道方向外网→内网生产环境最好不要配双向双向排障难源目录/data/exchange/in外网主机上给外部业务方的投递区目标目录/data/exchange/out内网主机落地后往业务服务器投递的缓存同步周期5秒周期太短没意义太长业务会催文件大小上限2048MB超过上限的文件直接丢弃并告警断点续传开启大文件同步必备不然后悔药都没得吃病毒查杀开启等保测评时会查这个开关失败重试3次重试间隔30秒避免并发堆积配好之后从外部业务侧往源目录丢一个测试文件观察内网目标目录是否出现文件。如果出现了最小通道就跑通了。验证脚本我在现场惯用一个bash循环放在一台能同时访问外网主机管理口和内网目标服务器的运维跳板机上逻辑简单但实用#!/bin/bash # 网闸通道连通性验证脚本观察文件摆渡延迟和丢文件情况 # 用法./check_gap.sh /data/testfile.txt TEST_FILE$1 DST_DIR/data/exchange/out # 丢一个标记文件进去 touch $TEST_FILE date %s $TEST_FILE echo 已投递测试文件等待摆渡... # 循环检查目标目录是否出现该文件最多等30秒 for i in $(seq 1 30); do if ls $DST_DIR | grep -q $(basename $TEST_FILE); then echo 文件已在 ${i} 秒内到达目标目录 cat $DST_DIR/$(basename $TEST_FILE) exit 0 fi sleep 1 done echo 文件摆渡超时检查通道配置 exit 1这段脚本的执行逻辑很简单在外部源目录生成一个带时间戳的文件然后每秒钟查一次内网落地目录看文件是否在30秒内出现。脚本里的超时时间按同步周期来调整——如果同步周期设的是5秒30秒足够覆盖整个链路。现场排查时这个脚本能快速区分是“网络链路问题”还是“通道任务问题”文件一直不出现先看两端主机各自的系统日志再看通道任务是否处于启用状态最后检查源目录投递权限。4. 核心参数怎么调文件同步、数据库同步、HTTP应用三类场景4.1 文件交换场景别只改一个目录路径就交付文件交换是TopRules最基础的场景但“基础”不等于“简单”我在多个项目里发现交付后出问题的往往是文件量大、文件数量多、文件名包含特殊字符这三类情况。文件量大时同步周期要按数据量级反向调整。如果每小时产生几十GB的文件同步周期设5秒会让中间存储区被塞爆因为摆渡速度跟不上生产速度。这种场景我一般把同步周期调到30秒到1分钟同时打开“目录轮询”模式让网闸按批次搬运而不是实时触发。文件数量多比如几万个碎文件时瓶颈往往不在网闸而在两端文件系统的inode消耗。外部投递目录如果积累太多文件遍历目录本身就要几十秒看起来像是网闸卡了实际是磁盘性能不够。我的习惯是建议业务方先打包成单一压缩文件再投递或者让网闸开启“完成后清理源文件”的开关避免目录无限膨胀。文件名特殊字符是另一类玄学问题中文、空格、括号在文件摆渡时经常导致目标端落盘失败。TopRules多数版本的策略是“原文件名透传”但某些特殊字符会在私有协议封装时出问题。规避方式很老套跟业务定规矩文件名只用字母、数字、下划线、连字符其他一律不允许在自动交换文件里出现。这个规矩在项目开工会上就要讲清楚不然后面每天都是擦屁股的活。4.2 数据库同步Oracle、MySQL、SQL Server三套配置差异如果说文件交换是网闸的日常数据库同步就是TopRules的高阶用法也是最容易被低估参数的场景。数据库同步的本质是外网数据库里的数据变更通过网闸摆渡到内网数据库内网业务系统读到的数据和外网保持一致但内外网数据库本身没有任何网络连接。配置数据库同步通道时TopRules要求的参数和文件交换完全不同。核心参数包括数据库类型Oracle/MySQL/SQL Server、源端连接信息IP、端口、SID/服务名、目标端连接信息、同步模式增量实时/定时全量、增量字段时间戳字段或序列号字段、冲突处理策略主键冲突时更新或丢弃、日志级别。三类数据库的同步机制差异很大。Oracle的同步通常要求源库开启补充日志和归档模式TopRules通过读取日志增量解析数据变化如果源库没开补充日志同步进程能拉起来但数据变化捕获不全表现为目标端数据一直少几条——这类问题在现场特别难排查因为网络、通道、权限看着全是对的。MySQL的同步则基于binlog要求binlog格式设为ROW否则无法解析到字段级的变更。SQL Server的同步则依赖事务日志且对源库的恢复模式有要求简单恢复模式下也可能抓不到变更记录。这三类“源端数据库日志要求”是配置数据库同步通道前必须跟DBA确认的否则通道建好了同步任务却一直在空转。我给客户的建议是先出一个源端数据库环境检查清单由DBA签字确认补充日志、binlog格式、恢复模式都合格了再让集成商进场配通道。4.3 数据库同步的一致性校验目标端主动核对数据库同步配置完成不代表万事大吉增量同步跑起来之后我养成了一个习惯每天至少做一次源端与目标端的数据一致性校验。这个校验不能在网闸上做因为网闸本身只是摆渡数据两端数据库仍然是隔离的需要在能访问两端数据库的管理机上分别执行SQL对比统计结果。-- 单表校验对比源端和目标端最大增量字段值与记录数 -- 在源端数据库执行 SELECT COUNT(*), MAX(UPDATE_TIME) FROM ORDER_TABLE WHERE UPDATE_TIME SYSDATE - 1; -- 在目标端数据库执行 SELECT COUNT(*), MAX(UPDATE_TIME) FROM ORDER_TABLE WHERE UPDATE_TIME SYSDATE - 1;两端查询出来的记录数和最大时间戳如果对不上说明同步任务存在漏数据。这时第一反应不是去怀疑网络而是回查网闸的同步任务日志看有没有解析失败的记录。数据库同步排查有一条核心经验网闸管理界面上显示“同步成功”只代表任务执行完成不代表数据没有遗漏一锤定音的唯一标准就是两端数据库的校验结果。4.4 应用层透明代理只放必要的HTTP动作除了文件和数据库TopRules还常用来做HTTP访问的代理摆渡。典型场景是外部用户要访问内网的Web系统但内网Web服务器不能直接暴露给外部网络。这时TopRules外网主机监听一个公网端口外部请求到达后由网闸摆渡到内网主机内网主机再以“全新会话”去访问内网Web服务器。配置HTTP代理通道时最常见的安全动作是限制方法白名单和URL特征。很多项目为了图省事直接把所有HTTP方法都放行包括PUT、DELETE、上传接口结果过等保测评时被专家质疑。我一般会让客户明确业务只读还是可写——只读系统就只放GET和POST上传下载类再加PUT和GET的参数过滤。有个细节要提醒HTTP代理模式下内网Web服务器记录到的客户端IP永远是内网主机的地址而不是外部用户的真实IP。这在安全审计上会带来麻烦。解决办法是在HTTP请求头里记录原始IPX-Forwarded-For然后在Web服务器日志里开启对XFF字段的解析这样内网审计系统才能追溯到真正的访问来源排查攻击来源时也不至于两眼一抹黑。5. TopRules常见问题排查几个让人抓狂的坑和解决路径网闸设备有个特点业务一旦不通查起来就头大。原因是链路长、角色多、两端独立管理问题到底是出在内网主机、外网主机、还是中间交换单元很难一眼定位。下面是几个我在现场反复遇到的典型问题每一条都是拿真金白银的割接时间换来的。5.1 通道配置完全正确文件却一直不过去现象通道、任务、目录权限都检查过源端投递了文件目标端一直不出现也没有任何报错。原因最常见的是源端投递方式搞错了。很多业务方习惯用FTP客户端把文件传到一个FTP服务器的目录上但在TopRules的文件交换场景里外部业务文件是直接写落到“外网主机本地文件系统”的投递目录里的不是传到一台独立FTP服务器上。如果源端配置的其实是某台FTP服务器的目录而TopRules外网主机去读这个目录时权限不对或路径不对任务就一直在失败重试中空转。解决先确认投递目录在拓扑上属于谁——是网闸外网主机本地磁盘还是外部网络里的另一台服务器。如果是外部FTP服务器需要先由外网主机通过FTP协议去拉文件这一类通道的外网主机任务类型应选择FTP获取而不是本地目录轮询。同时把任务日志打开失败重试时的具体原因会直接写到日志里不要只盯着数据看。5.2 数据库同步任务显示正常数据却少了几万条现象TopRules管理界面上同步任务状态一直是正常无异常告警但目标端表里数据条数和源端对不上而且没有任何失败记录。原因这个坑我在银行前置项目里踩过最后定位到是源端日志捕获点位问题。Oracle数据库的补充日志没有开启当发生DELETE和UPDATE操作时日志里没有记录足够的前镜像信息网闸的日志解析模块无法还原变更内容只能跳过这条记录。同步任务本身是正常完成了它只是正常完成了“能解析数据”的部分而不是“全部数据”的部分。解决让DBA把源库的补充日志和归档模式打开然后重新做一次全量初始化同步再继续增量。这个坑的防范动作是在配置数据库同步通道之前先跑一下源库日志环境检查脚本确认日志条件达标再开始配置通道。不要等数据对不上再回头查日志那个时间成本足够项目经理失眠好几个晚上。5.3 大文件传一半就断重试仍然失败现象几百MB的文件同步到50%左右就失败了重试多次仍然在同一位置附近失败小文件不受影响。原因网闸文件摆渡时有两处瓶颈一是交换单元的临时存储区大小二是两端主机的会话超时时间。大文件摆渡需要先把整个文件缓存到中间存储区再搬运到目标端。如果中间存储区空间不足搬运就中断。另一类是TCP层会话超时外网主机接收文件时如果速度过慢中间交换单元可能判定会话超时主动断开。解决确认文件大小上限参数大于实际文件体积同时把文件交换任务的“断点续传”打开再根据实际网络带宽调整摆渡并发数。并发线程太多会导致中间存储区快速占满建议先从单线程试起。现场如果文件必须在业务高峰期传输给这个通道单独划分专用带宽不跟其它业务共用物理链路。5.4 双机热备切换后业务直接就断了现象两台TopRules做了HA热备手工做主备切换演练主设备切换后业务中断数据交换全停但设备本身没有任何硬故障。原因热备切换时虚拟服务IP在主备之间漂移但通道任务没有同步过去。网闸的HA只解决“设备级可用性”不解决“配置级同步”。如果主备两台设备的通道配置版本不一致或任务状态不一致切换后就会出现主设备没故障但业务不通的怪现象。解决做HA之前必须先核对主备设备的配置版本确保通道配置完全一致。另外要约定切换后的验证动作——切完不能只看设备状态要看内网目标服务器上的落地文件时间戳是否持续更新、数据库同步任务是否继续写入。养成一个习惯每次切换演练后跑一遍第3章的验证脚本确认数据流恢复再宣布演练结束。5.5 审计日志查不到东西不是没记录是没开启现象安全审计人员来查网闸日志发现管理界面里只有登录记录没有数据交换的操作记录问是不是设备出问题了。原因这才是真的“不是设备问题是配置问题”。数据交换的操作审计开关默认未必是开启状态尤其是通过任务方式触发的自动文件交换可以在不经过任何交互操作的情况下完成数据搬运如果审计策略里没勾选“记录数据交换事件”自然什么都查不到。解决在管理界面的审计策略里开启数据交换日志记录同时配置日志存储位置和保留周期。网闸自带磁盘的日志存储空间有限数据交换频繁的场景建议把日志远程同步到日志审计平台保留周期按等保要求配置。这里有一条运维纪律建议半年导出一次日志做离线归档不是给测评机构看的是给自己留后路——等真出安全问题需要追溯时你才知道设备和日志谁更靠得住。6. 一台网闸能不能长期不翻车拼的是更新和验证习惯TopRules上线交付只是开始真正决定这个项目口碑的是后续每一次策略变更和故障应急。我自己的习惯是所有通道配置变更都不在生产直接改先在测试通道里做灰度验证。比如要新开一个数据库同步任务先在测试通道里跑两天确认数据一致性和延迟都达标再把正式通道切过来。操作时先导出当前配置存档变更后如果业务异常立刻回滚配置并重启对应任务。这个动作看起来“浪费两天时间”实际上给客户省掉的回滚事故成本是十倍以上。日志和审计要定期看不是等出事再看。我在每个TopRules项目里都会定一个“三看”检查项一看被阻断的访问记录判断有没有人试图从外网向内网爬数据二看同步失败的任务清单确认有没有一直重试却没人处理的僵尸任务三看病毒查杀记录确认隔离区有没有检出但未处理的样本。这三个清单正常这台网闸基本不会在关键时刻掉链子。最后说一个干这行不得不提的教训网闸上了生产链路之后一般不会被轻易卸载替换很多项目的网闸设备一跑就是三五年不重启所以配置变更的记录比变更本身更重要。我现在无论给哪家做网闸维护都会在项目交接时强制建立一份“通道配置变更台账”每次改了什么、原因是什么、回滚方案是什么全部记录在案。这个习惯救过我很多次也给接手运维的同事留了一条活路。一台TopRules摆渡数据的能力取决于你对两端网络的所有细节掌控程度。把这个方向做扎实你在隔离交换项目里能吃到的红利比只会在防火墙上加策略的工程师要多得多。希望这篇笔记帮到你。本文还有配套的精品资源点击获取
