网闸这设备做网络集成的同行应该都不陌生。项目里一旦出现“内外网隔离”“生产网和办公网数据交换”“两个安全等级不同的网络之间要通数据”这类需求十有八九最后会落到网闸上。前阵子接了一个多区域安全隔离的项目选型评估之后定了深铠威的网闸从方案设计、设备上架到策略调试、数据摆渡联调整套走下来两周多。今天把深铠威网闸部署的全过程拆开讲讲给准备做安全隔离项目、或者正被网闸配置搞得头疼的同行一个参考。这篇东西不会只讲“点下一步”的操作我会把部署前怎么规划、设备上架后怎么初始化、策略怎么设计、数据摆渡功能怎么配、以及现场最容易踩的坑都过一遍。适合三类人看一是刚接触网闸的运维新人需要建立整体认知二是正在做隔离项目的网络工程师可以对照着补细节三是准备做方案选型的技术负责人看完能明白这设备到底能干什么、不能干什么。1. 部署前的网络规划与架构设计1.1 先搞清楚网闸解决的到底是什么问题网闸和防火墙很多人容易混。防火墙做的是逻辑隔离它在同一张网络里根据五元组、应用层协议做访问控制攻击面理论上是存在的——只要策略有漏洞两边网络仍然能通过IP层互相访问。网闸不一样它的核心是物理隔离整个设备采用“21”架构内网处理单元、外网处理单元、中间隔离交换单元。两侧的主机系统之间不存在物理连通的TCP/IP链路数据先落到一侧的缓冲区域然后通过专用硬件把数据“摆渡”到另一侧整个过程用的是私有协议不依赖IP协议栈。可以用气闸舱来理解网闸人在两舱之间走动两道门永远不会同时打开每次只能走一个缓冲间。网闸传输数据也是这个逻辑内网单元收包、校验、缓存再通过交换矩阵把数据递到外网单元外网单元再转发出去。网络层上两个区域是断开的即使一侧被攻破攻击者也没有一条现成的网络路径直接打到另一侧。所以选型的时候要先想清楚你的场景到底需要什么。需要不同安全域之间做数据交换但又不希望两层网络有直接IP连通性用网闸。需要数据库单向同步、文件单向摆渡、Web服务安全发布且对审计有强要求用网闸。只是普通的企业网关、内网分段、访问控制防火墙就够没必要硬上物理隔离成本高且运维复杂。还有一个判断标准看那两个网络之间出了事能不能接受对方直接互通。如果两边一旦打通就可能造成生产事故或数据泄露那就该上网闸。真实项目里很多单位是“防火墙网闸”串着用防火墙在边界挡常规攻击网闸提供更彻底的隔离边界两层防线各管一段。1.2 部署模式和网络拓扑怎么定网闸的部署模式核心就一句话真正做隔离必须串联。旁路模式不是不能用但它只能用在审计、监控、日志采集这类非关键路径上数据不经过它就谈不上隔离效果。所以大多数正经隔离项目主链路都是串在核心交换设备中间的。单机串联是最常见的拓扑。一条链路拆成两段内网核心交换机接深铠威网闸的内网口网闸外网口接外网区域的接入交换机。这时候内网和外网之间唯一的通道就是网闸所有流量都从网闸走物理断开和逻辑控制才同时成立。管理口要单独规划我一般建议划一个独立管理VLAN从办公网或带外管理网接入千万别跟业务流量混在一个段里。双机热备则是为了高可用。两台深铠威网闸分别接在两套交换设备上中间用HA口互联心跳正常时一台主一台备主设备故障后自动切换。需要注意的点是双机热备不只是网闸之间的事它跟接入交换机的链路聚合、堆叠方式强相关。如果上联交换机做了堆叠网闸的两条上联链路要接在堆叠系统里如果交换机是独立双机网闸就要配合VRRP或者双上行方式来避环路。做方案时先把交换侧的情况摸清楚不然到现场网闸主备一切换整个链路就断了。从部署经验上讲即使当前业务量单台设备够用我也强烈建议预留HA接口和相应线缆。网络架构这个东西事后扩容最难的不是加一台设备而是要调整物理链路和IP规划前期多留一个口、多放两芯光纤能省后面一大堆事。1.3 部署前必做的信息收集清单网闸部署最怕的不是设备出问题而是信息不齐就进场。网闸不像路由器可以上了架再慢慢配它两边是两个隔离的网络一旦接口IP、路由、策略设计错了业务放通和隔离效果都会出问题。我在项目启动前都会让现场按下面这张表把信息收集齐收集项为什么必须搞清楚两侧网络IP地址和掩码网闸接口IP要与两侧网络规划匹配错一个位就ping不通默认网关和静态路由路径网闸对两侧路由不做动态学习需要手工配路径错了数据出不去需要跨网闸的业务服务清单决定放通哪些端口、配置哪类应用代理不知道业务就没法写策略流量方向和大小影响设备选型、双机方案、以及是否需要调MTU/性能参数是否涉及NAT和端口映射涉及发布类业务要提前设计映射关系否则到了现场两头都对不上管理网段规划管理口单独走不能和业务段互踩这是安全红线上下游设备厂家和端口类型决定用光口还是电口、是否需要转接模块、速率是否匹配这里特别提醒一点网闸两侧不建议跑OSPF、BGP这类动态路由协议。原因很简单网闸在物理层把两边断开了动态路由邻居关系根本建立不起来硬要跑只会让路由表一直处于震荡状态。老老实实用静态路由每侧指向对应的下一跳路径清晰排障也方便。2. 深铠威网闸安装与基础网络配置2.1 硬件上架和接口阵列识别深铠威网闸通常是标准的1U或2U机架设备双电源冗余设计。上架这一步看起来简单实际翻车的地方不少。首先要确认电源插槽接入的是不同路供电而不是插同一个PDU上不然一路电断了整台设备跟着断电双电源就成了摆设。机柜内散热也要注意网闸虽然功耗不算高但长时间满负载运行发热明显上下留U位不要在设备缝隙里塞满线缆。接口这块深铠威网闸一般会提供这一组接口内网口接内网侧交换机通常是多个千兆或万兆口可做链路聚合。外网口接外网侧交换机结构上跟内网口完全隔离。管理口独立的管理接口走带外管理网。HA口双机热备专用连接两台设备之间传心跳。Console口串口调试口初始化时必须用它。上架时有个小习惯很管用所有网线、光纤两头都贴标签标注“网闸-内网口1-交换机G1/0/5”这种格式。网闸部署一般都在割接窗口时间紧、操作密没有标签寸步难行。我有一次就是没做标签查一条业务链路不通的原因光核对物理连线就花了一个多小时后面所有项目再没省过这一步。2.2 控制台初始化与网络参数配置新设备开箱后第一次配置建议走Console口。用串口线连上电脑设置波特率、数据位等参数具体值以设备手册为准登录后最先要做的是改名、改管理IP、改默认密码这个没得商量。设备默认密码一般很简单不上线还好一旦接入网络就是风险点所有默认口令都要在初始化阶段换掉。初始化向导每个型号略有差异但核心流程是固定的设置设备名称和管理员账号。配置管理口IP、掩码、网关。配置内网口和外网口的IP地址。选择工作模式透明模式、路由模式、NAT模式。配置默认路由和静态路由。保存配置并重启。工作模式的选择要按现网情况来定。如果两侧网络已经规划好了独立网段用路由模式最清晰每个接口一个三层地址路由指向明确。透明模式的好处是不用改 IP 规划设备像一根网线一样插进去但对二层环境要求高如果现网有环路风险或广播流量很大调试起来会更费劲。NAT模式适合发布类业务把内网真实地址隐藏起来后面做端口映射时常用。我的建议是能路由就路由规划清楚永远比临时省事重要。2.3 网络连通性验证初始化配置完成后先别急着写策略第一步是把链路验证通。我在现场的习惯是分三步从网闸内网口 ping 内网侧网关地址不通就先查接口是否启用、IP是否配错、网线是否插对。 从网闸外网口 ping 外网侧网关地址方法同上。 从管理终端访问管理口的 Web 管理界面确认能够正常登录。三层通了才往下走。网闸这时候还没有策略默认动作是拒绝所以跨两侧的ping不通是正常的别急着怀疑设备坏了。管理界面访问失败时优先查管理终端IP是否和管理口在同一个网段、浏览器是不是有代理设置、以及HTTPS证书是否被本机安全策略拦截。现在的浏览器对自签名证书卡得比较严首次访问需要手工信任证书这个在现场非常常见不是设备故障。3. 安全策略配置与数据摆渡功能实现3.1 访问控制策略默认拒绝最小化放通网闸的安全策略核心原则就八个字默认拒绝最小放通。所有流量在没有显式规则之前都是禁止的需要放行的业务一条条加加的时候明确五元组源地址、目的地址、源端口、目的端口、协议再配合时间段和动作。这样设计的好处是攻击面收敛到最小即使策略出错也容易定位。举个例子内网办公区需要访问外网某段服务器上的Web服务我通常会配置成这样方向源地址目的地址服务/端口动作内网→外网192.168.10.0/24192.168.20.10TCP 80/443允许外网→内网192.168.20.10192.168.10.0/24对应响应流量允许或由状态机制自动匹配写规则时最容易犯的错是把“服务”写得太宽比如为了省事全部用any后面安全审计时根本说不清楚到底放通了什么。还有规则顺序的问题网闸策略一般是顺序匹配从上到下执行。建议把明确的拒绝规则放在前面比如先拒绝某个高危网段的访问再放通其他正常业务避免前面一条放通规则把后面本该拦截的流量给带过去了。我见过不止一次因为规则顺序不对导致敏感网段被意外放通的案例这种问题在界面上看策略列表根本发现不了必须模拟流量测。3.2 典型数据摆渡场景配置网闸的价值体现在各种数据摆渡功能上这也是配置的核心环节。深铠威网闸一般会提供数据库同步、文件传输、HTTP代理等应用代理模式每个场景配置思路不一样。数据库同步是我做隔离项目时最常碰到的需求。两边各有数据库需要把生产库的数据同步到查询库。这个场景用网闸的数据库同步功能做中转代理两侧数据库中间没有直连通道网闸通过自身的摆渡机制把一侧的数据库变更事件封装后传递到另一侧重新写入目标数据库。配置时要确定数据库类型MySQL、Oracle等、端口、同步方向、以及目标库连接账号。这里有个关键经验网闸的数据摆渡有延迟不像局域网内直连一样实时业务侧数据库连接超时参数一定要调大我之前遇到过一次同步任务频繁断掉后来发现就是业务侧默认的connect timeout只有5秒而网闸摆渡高峰时超过8秒调成30秒后问题消失。文件摆渡也是高频场景比如内网服务器需要把报表推送到外网文件服务器。通常的做法是在网闸上配置文件代理服务指定源目录、目标目录、传输协议FTP或SMB再配合传输方向。这里要注意文件摆渡建议做单向比如内网往外网推送文件就只开一个方向的策略外网没有反向写回去的权限。如果确实需要双向也尽量分两个通道方便审计溯源。HTTP发布类业务则是把内网Web服务通过网闸映射出去外部访问网闸外网口的某个端口网闸把请求代理到内网真实服务器。这样对外只暴露网闸IP内网服务器真实地址完全隐藏。配置映射时端口冲突检查要仔细多个服务映射到同一个外网口时外部端口不能重复。3.3 日志、审计和告警别偷懒网闸部署不等于业务通了就完事审计和告警一定要在验收前配好。深铠威网闸本地会记录所有放通和拒绝的流量日志但这些日志存在设备本地空间有限跑上几个月就可能把磁盘占满到时候设备性能会受影响。建议把日志实时转发到独立日志服务器通过Syslog协议对接设备本地保留近期的记录历史日志统一存到日志平台。告警设置也要做比如策略命中异常、设备CPU或内存超阈值、双机切换事件都要能触发邮件或SNMP Trap通知。很多网闸上线后长期没人看出问题全靠业务方反馈运维就很被动。告警跑起来之后至少设备自身异常能在早期暴露。审计日志这块要说一句大实话网闸项目十有八九要应对安全检查没有日志记录就等于白做。日志留存时长各地各行业要求不同但只多不少我自己的习惯是无论要求多久至少给客户留半年以上存储空间不够就扩日志平台别在这块省。4. 常见问题与排查实操4.1 部署阶段三层通但业务流量不通这是现场最让人血压升高的问题。现象很典型网闸两侧网关都能 ping 通管理界面也能打开但业务系统访问就是不通。排这个问题我有一套固定顺序能快速定位。先把业务用的目的地址拉到网闸策略里看是否已经被显式放通。网闸默认拒绝策略漏了一条流量就会在设备上被静默丢弃表现出来就是“超时”而不是“拒绝访问”。 查路由表。数据从内网口进来后如果路由表里没有到目的地址的路径设备不知道怎么转发一样是静默丢弃。路由模式网闸最常错的就是这里只配了接口IP没配具体网段路由。 查NAT映射。涉及端口映射时确认映射的协议和端口是否和策略一致外部端口和内网服务器实际监听端口是否对得上。 最后检查设备会话表。如果会话数满或者表项异常也可能导致新连接无法建立清一下会话表再测。还有一种低级错误是接口物理层正常但协议层被shutdown了或者是光模块类型不匹配、速率协商失败导致接口频繁up/down。用命令行看接口状态能一眼发现问题。4.2 业务运行期文件传输中断与数据库同步延迟设备上线一两个月后开始出幺蛾子这类问题最折磨人因为现象不规律且多半和业务侧环境混在一起。文件传输不定时中断是个典型。一开始我怀疑网闸策略和硬件查了很久没结果后来发现是大包传输时MTU设置不当网闸自身分片重组能力有限加上两侧交换机的MTU不一样导致大文件传到一半触发分片丢失。解决办法是把两侧接口的MTU统一建议用标准1500不要贸然开巨帧。如果业务确实需要大包传输可以把TCP MSS钳制打开强制小包传输。数据库同步延迟大则是摆渡机制本身的特性。网闸不是实时转发中间有缓存、校验、再写入的过程业务侧如果是实时性要求很高的同步链路体验会很难受。这个问题的根治方案是业务侧改成异步同步模式和我们对接的DBA最初总把数据库同步当成局域网内主从复制不断调超时参数后来把同步逻辑改成最终一致性思路配合网闸断点续传机制问题才算闭环。还有一个高频问题高并发业务在高峰期大量连接卡死。网闸的并发连接数是有上限的当业务侧突发连接数超过设备能力时新连接会排队或直接丢弃。这个可以通过设备监控看到会话数指标。短期应急是清会话表长期方案要么是优化业务复用连接要么是换更高规格的设备。如果遇到这种场景不要犹豫设备性能不足这两个字就是原因。4.3 维护操作容易踩的坑网闸后期维护踩坑基本都是人为因素。我总结了一张速查表碰到类似现象可以直接对着找症状常见原因解决思路策略改完后全网业务异常规则顺序错误或误删默认放通立即回滚上一份配置备份再逐条核对双机热备切换失败心跳口中断、抢占模式配置不一致检查HA口链路和心跳报文状态升级固件后管理界面打不开版本不兼容或升级步骤缺失用Console口恢复降级到原版本日志磁盘被占满未配置远程日志或归档策略清历史日志接Syslog服务器设备频繁重启供电不稳或硬件故障检查双电源输入联系售后检测在这里多说两句备份的事。网闸策略一变风险就多一分我给自己定的规矩是任何变更操作前必须先导出一份配置备份改完立即再导出一份留档。这种习惯救过我不少次有时候改完策略当时看着正常过了两天业务才报异常没有备份就只能凭记忆回滚非常被动。5. 部署验收与后续运维要点5.1 验收测试到底测什么网闸部署完验收不能只是“业务能通”就算完我一般会从三个维度做完整测试。功能测试。把规划好的放通策略逐条验证确认该通的通、该拒绝的拒绝。双向策略都要测比如放通内网到外网的服务要同时确认外网侧默认不能主动发起访问。数据摆渡功能要做真实业务数据测试文件传几个大文件、数据库同步跑完整流程不能拿测通一个小包就算通过。性能测试。用打流工具跑一下带宽确认实际吞吐量和设备标称值差异不能太大。这里要提醒标称吞吐是理想条件下的数据实际业务因为小包多、连接频繁吞吐会低不少。测试结果记录下来作为后续扩容的参考基线。高可用测试。双机配置的话一定要在主设备上做主动切换演练看备机能否接住业务。还要测断电恢复把主设备电源拔掉观察业务中断多久、备机是否接管、主设备恢复后能否自动回归。这些测试要提前申请割接窗口不要放在白天业务高峰做。5.2 上线后的日常运维要点上线不是结束而是运维的开始。网闸作为安全设备它的策略需要持续迭代。我建议运维人员每季度做一次策略评审对照业务应用清单看还有哪些规则在用、哪些规则已经失效。很多单位跑了两三年策略列表里躺着几十条早已不用的放通规则这类规则就是安全隐患。设备自身的监控指标也要纳入日常巡检CPU、内存、会话数、磁盘空间、HA状态。用SNMP把指标接入已有的监控平台设置阈值告警不要等设备性能告警了才登录上去看。还有一个容易被忽略的点固件升级。网闸设备会不定期修补安全漏洞升级前仔细看版本更新日志确认是否影响现有策略配置。升级窗口同样要选择业务低峰升级后逐项检查核心业务确认无异常后再观察几天不要升级完就不管了。最后再分享一个我在实际项目里的感受。网闸这设备说难不难做好隔离的关键不外乎规划、策略和习惯。规划阶段把网络拓扑和信息收集做扎实配置阶段守住默认拒绝和最小放通运维阶段做好备份和定期评审这套流程走下来项目基本不会出大问题。尤其是备份和规则顺序这两件事几乎是我所有网闸项目里教训最深的地方。做安全设备谨慎永远比炫技重要留好退路再动手比任何高级配置都有用。