简介东软NetEye防火墙初始化与配置的实操文档面向网络运维、安全实施及入门学习者解决首次部署时参数配置与策略开通的常见问题。文档按操作流程逐步展开覆盖超级终端经串口控制台线缆连接、初始化设备、主机名/系统时间/语言设置、根管理员口令修改、系统管理员创建及Web/Telnet/SSH登录方式选择、WebUI/CLI配置方式、连接端口IP与缺省路由定义、登录NetEye系统等完整环节并保留命令交互示例方便对照操作。后续章节还延伸至用户管理、接口二层改三层、安全域划分、路由配置、IP与服务对象定义、NAT映射与访问策略配置适合作为现场部署和排错的参考手册。包内仅含1个docx文件压缩包约2.2MB便于离线查阅。目前已有377人学习下载对快速上手东软防火墙配置具有较强实操参考价值。1. 东软防火墙配置从拿到设备到策略上线要跨过的四道门槛接手一台没有文档的东软防火墙第一反应不是敲命令而是先把“流量怎么走”想清楚。很多运维把东软防火墙配置当成“配个地址、加两条策略”两步走结果策略堆了一屏业务还是不通最后在安全域和 NAT 联动上翻车。东软防火墙的配置过程核心是四件事管理面接入、安全域与策略编排、NAT 与路由联动、验证与备份。适合刚接手设备的企业网管、做安全集成的实施工程师也适合被前任配置坑过、想系统性梳理一遍的运维。这篇我按实际配置顺序写每一步都能对照设备操作。2. 配置前的准备管理面接入、基础网络参数与备份基线2.1 Web 管理面和 Console 管理面该从哪条路进去东软防火墙和其他企业级防火墙一样有两条管理通道。Console 走串口线接设备背板上的 console 口用于第一次初始化、密码恢复、以及 Web 管理面失联时的应急排查。Web 管理面走网口日常配置、策略调整、日志查看都在这上面做。新设备到手先别急着猜 Web 地址。很多设备出厂时管理口 IP 在设备铭牌或快速安装手册里常见是 192.168.x.0/24 网段内的某个固定地址。如果你拿到的是被前人配置过的设备铭牌上的地址不一定有效这时候最可靠的路子是用 Console 线接入。Console 线参数一般是 9600 波特率、8 位数据、无校验、1 位停止位。用 SecureCRT 或 Xshell 新建串口会话连上之后能看到设备启动日志和命令行提示符。通过 Console 先确认当前接口地址和配置状态再决定 Web 管理面走哪个网段。# 在Console命令行下查看当前所有接口的IP地址配置 show interface ip brief # 查看当前生效的配置确认Web管理服务绑定在哪个接口 show configuration | include webshow interface ip brief这条命令列出所有三层接口的 IP 地址和状态先把设备当前“长什么样”摸清楚。show configuration | include web是过滤出和 Web 管理相关的配置行判断管理服务是否被限制在某个接口或某个源地址范围内。如果设备从未配置过接口 IP 全是空的那就按 2.2 的步骤从零开始配。2.2 管理 IP、静态路由与 NTP先给设备一个能上网的地址管理面能进去之后第一件事不是加策略而是给设备一个稳定的管理地址和路由。管理地址选内网核心交换机旁边的独立运维网段不要和业务网段混在一起。这样做的好处是后续策略误伤时管理流量有单独通道可以排查。# 进入配置视图不同版本命令行风格略有差异以下以常见CLI风格示例 system-view # 配置管理接口地址接口0/0接内网核心交换机 interface GigabitEthernet 0/0 ip address 192.168.10.2 255.255.255.0 quit # 配置默认路由指向内网核心交换机的网关 ip route-static 0.0.0.0 0.0.0.0 192.168.10.1 # 配置NTP服务器指向公司内网时间源 ntp-service unicast-server 192.168.10.100 # 保存配置避免设备重启后全部丢失 saveinterface GigabitEthernet 0/0进入接口视图ip address后面的两个参数分别是 IP 地址和掩码。这里的 192.168.10.2 是管理地址掩码是 24 位。默认路由0.0.0.0 0.0.0.0表示所有未知目的地址都交给 192.168.10.1 这个网关去转发这个网关通常是核心交换机的 VLAN 接口地址也可能是上联路由器的接口地址。NTP 配置容易被忽略但时间不同步会带来非常实际的麻烦日志时间戳对不上策略生效时间判断错误甚至证书校验类的功能会直接失败。我一般会先在运维网段里找一台 Windows 或 Linux 服务器充当 NTP 服务器没有的话就用设备默认的 NTP 服务器地址等后续网络通了再改。2.3 配置备份基线改之前先把“后悔药”备好安全设备最怕改到一半回不去。东软防火墙的配置导出在 Web 管理面通常在“系统管理—配置管理”里可以导出一个完整配置文件命令行下也可以直接查看全量配置。我养成的习惯是第一次拿到设备先导出一份完整配置存到本地文件名带日期。之后每次变更前再导出一份变更后也导出一份。三份文件放一起对比改了什么一目了然。这个习惯在排查问题时能省下大量时间尤其当你在排障过程中发现设备配置被前几任改得面目全非时一份干净的基线配置就是你的后悔药。# 命令行下查看完整配置并重定向保存 show configurationshow configuration的输出就是设备的完整配置文本。在 SecureCRT 里右键“记录会话”或者直接把回显复制到文本文件就能保存一份基线。Web 管理面导出的文件通常也是文本格式可以直接用文本对比工具打开。保存完基线之后还要确认设备开启了配置自动保存功能。部分版本默认只在执行save后写入启动配置如果你改完策略忘了保存下次停电或重启所有改动全部消失。这个问题在 5.3 节还会专门讲。3. 安全域与策略编排先把流量路径画出来再写上墙3.1 安全域是怎么让流量“默认拒绝”的东软防火墙的安全域机制和主流防火墙一致接口先绑定到安全域域与域之间的流量默认拒绝同域内流量默认放行。常见的安全域划分是 Trust内网、Untrust外网、DMZ服务器区接口按业务归属绑定到对应域。这个设计的安全意义在于不需要你手动写“拒绝所有”这条兜底策略默认行为就是拒绝。实际配置中很多人把三个接口全绑定到 Trust 域结果内网和 DMZ 之间流量全通防火墙变成了一个普通路由器安全隔离形同虚设。# 将接口绑定到安全域 firewall zone trust add interface GigabitEthernet 0/0 quit firewall zone untrust add interface GigabitEthernet 0/1 quit firewall zone dmz add interface GigabitEthernet 0/2 quitfirewall zone trust进入 Trust 域配置视图add interface把物理接口加入该域。一个物理接口只能属于一个安全域不能重复绑定。接口绑定完域域间策略才开始生效。这里有一个容易忽略的点设备自身的管理流量比如你从运维电脑访问 Web 管理面走的是“本地域”逻辑与管理接口所在的安全域不完全是同一回事。如果你是远程通过业务口管理设备需要在策略里放行从管理网段到设备本身的流量这条策略很多人配完就忘结果远程重启设备之后再也登不进去。3.2 策略五元组源、目的、服务、动作和时间段怎么填安全策略本质是一个五元组匹配源地址、目的地址、服务、动作、时间段再加一个日志开关。东软防火墙配置策略的思路是先定义对象再写策略引用对象。对象可以复用避免每条策略里写死 IP后面改地址时到处找。# 定义源地址对象内网用户网段 object-group ip address LAN_192_168_10 0 network 192.168.10.0 255.255.255.0 quit # 定义目的地址对象DMZ区的Web服务器 object-group ip address WEB_SERVER 0 host 10.10.10.10 quit # 定义服务对象HTTPS object-group service service_https 0 tcp 443 quit # 配置策略内网用户访问DMZ区Web服务器放行并记录日志 policy-security name LAN_to_WEB action permit source-object-group LAN_192_168_10 destination-object-group WEB_SERVER service service_https logging enable quit代码里的object-group ip address是地址对象组0 network表示一条网络对象后面跟网段和掩码0 host表示单台主机。object-group service是服务对象组0 tcp 443表示 TCP 协议的 443 端口。写策略时动作只有 permit 和 deny 两种。刚开始配别想太复杂默认拒绝已经在安全域层面兜底了你只需要写“哪些流量允许通过”。日志开关建议在关键的放行策略上打开比如内网访问 DMZ 服务器、内网访问外网这些日志在排查安全事件时是重要依据。全部策略都开日志的话日志量太大会把存储撑爆这个在第 5 章会讲。3.3 策略命中顺序与日志开关先放行谁再观察谁策略不是平行关系的它从上到下逐条匹配命中一条就停止不再往下看。这个机制意味着策略顺序本身就是一个安全维度。常见错误是把一条宽泛的拒绝策略放在前面后面的放行策略全部失效。我一般建议的顺序是先放行关键的、明确的业务流量再放行管理流量最后放行内网到外网的常规流量如果有明确的阻断需求再放在最后。换句话说精确放行在前宽泛放行居中明确拒绝垫底。# 查看当前策略顺序和命中次数 show policy-securityshow policy-security会列出所有策略的编号、名称、动作、源目的对象和服务部分版本还会显示命中计数。命中次数是排查策略问题最直接的工具某条策略明明应该匹配流量但命中计数一直是 0说明流量根本没走到这条策略这一步问题在路由或 NAT 层面。调整策略顺序也是一条命令的事把策略编号调一下就行。比如把策略编号从 5 挪到 2# 调整策略顺序 policy-security move 5 to 2逻辑说明move 5 to 2表示把编号为 5 的策略移动到编号 2 的位置。调整完之后再show policy-security确认顺序。这个操作在 Web 界面上通常有上下箭头按钮点起来更直观但命令行的好处是可回溯、可脚本化。到这里策略编排的基本框架已经搭起来了。但策略放行只是让流量“允许通过”流量能不能真正往返还取决于 NAT 和路由层的联动。4. NAT 与路由联动让双向流量真正打通的关键几步4.1 源NAT和目的NAT方向反了会怎样NAT 是整个配置过程里最容易让人犯迷糊的部分。方向上理清楚就成功了一半源 NAT 解决的是“内网出去时用什么地址”目的 NAT 解决的是“外面进来时怎么找到内网服务器”。内网用户访问外网出口是公网地址如果不做源 NAT内网私有地址段比如 192.168.10.0/24会被运营商直接丢弃因为私有地址在公网上不可路由。源 NAT 就是把内网 IP 转换成接口的公网地址。外部用户访问内网服务器必须先通过公网 IP 的某个端口找到这台服务器这就需要目的 NAT也叫端口映射。把公网 IP 的 443 端口映射到内网服务器的 443 端口。# 源NAT内网网段出接口时转换为接口地址 nat-policy name snat_to_untrust action source-nat source-address 192.168.10.0 255.255.255.0 egress-interface GigabitEthernet 0/1 quit # 目的NAT把公网IP的443端口映射到内网服务器 nat-policy name dnat_web_server action destination-nat destination-address 202.100.1.10 255.255.255.255 translate-to address 10.10.10.10 service tcp 443 quitnat-policy定义一条 NAT 策略action source-nat表示源地址转换egress-interface指定流量从哪个接口出去时执行转换。action destination-nat是目的地址转换translate-to address指定转换后的内网服务器地址。源 NAT 和目的 NAT 可以同时存在。一个典型场景是内网用户通过公网 IP 访问自己的 DMZ 服务器这时候流量既匹配目的 NAT去程转换成内网地址也可能匹配源 NAT回程时把内网源地址再转回来。这种场景最容易出问题后面 5.4 节详谈。4.2 路由、NAT 与策略的联动顺序排查断点从哪开始防火墙处理一个数据包时内部执行顺序大体是先查路由表决定从哪个接口出去再做 NAT 转换最后查安全策略决定放行还是丢弃。不同厂商的顺序可能有细微差别但排障思路是一致的从路由入手逐层往下查。实际排查时我习惯从以下顺序验证第一步看设备有没有到目的网段的路由第二步看 NAT 策略是否命中了这条流量第三步看安全策略是否放行了转换后的流量第四步看会话表里有没有建立双向会话。路由是很多“策略无效”的元凶。比如目的 NAT 配好了安全策略也放行了但防火墙自己到内网服务器没有路由数据包直接被丢弃。这时候你在会话表里看不到任何记录日志也没输出因为包在路由层就被丢掉了。# 查看路由表 show ip route # 查看NAT策略命中情况 show nat-policy hit-counter # 查看当前会话表筛选目的地址 show session table destination-ip 10.10.10.10show ip route看路由表重点确认目的网段的路由下一跳是否正确。show nat-policy hit-counter看 NAT 策略命中计数如果计数为 0说明流量根本没匹配到这条 NAT 规则。show session table是关键它能看到数据包被处理后建立的会话包含源、目的、NAT 转换前后的地址。会话表是防火墙排障的核心工具比看策略配置直观得多。4.3 从 ping 到业务端口逐层验证双向流量配置完成后验证不能只停留在“能 ping 通”。ping 通只代表 ICMP 协议在路由和策略层面被放行了业务端口能不能通是另一回事。在外部测试机上验证端口映射常见做法是用 curl 或 telnet 直接探测目标端口。HTTPS 服务用 curl 带证书校验的方式测试能确认 TCP 握手和 TLS 握手都成功。# 用curl验证HTTPS端口映射是否生效 curl -vk https://202.100.1.10 # 用telnet验证端口是否可连通 telnet 202.100.1.10 443curl -vk中的-v显示详细握手过程-k跳过证书校验适合用来验证端口映射而不是验证证书合法性。telnet 命令更朴素能连上就说明 TCP 443 通了连不上看报错信息区分是超时还是拒绝。验证完端口回到防火墙看会话表。双向流量正常时会话表里应该能看到完整的往返记录NAT 转换前后的地址都清晰可见。如果只有去程没有回程多半是回程路由或回程策略没放行。验证这一步最忌讳的是“感觉应该通了”。把会话表和策略命中计数截图存档和备份配置放在一起后续出问题可以做前后对比。这也是最后一章要讲的日常维护习惯的基础。5. 东软防火墙配置的5个常见问题与避坑记录5.1 策略已配置但业务不通现象安全策略、NAT、路由都配了业务还是不通测试机访问公网地址超时。原因最常见的是多条策略同时匹配前面的拒绝策略先命中后面的放行策略根本没机会执行。另一种原因是策略里的源地址对象写错比如把内网网段写成 192.168.10.0 24 位掩码但实际用户 PC 在 192.168.11.0/24流量匹配不到放行策略被安全域默认拒绝。解决先show policy-security看策略顺序再show policy-security hit-counter看每条策略的命中次数。如果拒绝策略命中计数在增长说明流量确实被它拦了把放行策略往前调整。如果所有策略命中计数都是 0说明流量根本没到防火墙检查上游交换机或路由。5.2 远程配置后管理面失联现象远程通过 Web 管理面修改策略后页面卡死再刷新就进不去了。Console 也连不上如果你人在机房外的话。原因大概率是你在策略里把管理网段的流量 deny 了或者把管理接口换到了另一个安全域导致管理流量被安全域默认拒绝。还有一种情况是改了管理接口的 IP 地址和本地不在一个网段。解决只能用 Console 线到设备面前接入进入命令行后检查安全策略里有没有放行管理网段访问设备本身的策略。没有的话立刻补上一条源地址是运维网段目的地址是设备接口 IP服务是 HTTPS 和 SSH动作放行。这条策略应该排在策略列表的最前面。事后把管理接口的 IP 改回原来地址再通过 Web 确认。5.3 设备重启后所有配置全部丢失现象防火墙因为停电重启开机后发现策略、NAT 全都没了回到出厂状态业务大面积中断。原因配置过程中只执行了临时生效的命令没有保存到启动配置文件。很多命令行在退出时不会自动保存Web 界面改完配置如果不点“保存”或“提交”也不会写入启动配置。解决养成两个习惯。一是配置过程中每完成一个逻辑模块就执行一次save二是配置完成后导出配置文件到本地。Web 界面修改配置后留意页面上有没有“保存配置”或“提交”按钮点了之后才算真正生效。开机后如果发现配置丢失用之前导出的基线配置文件恢复这也是第 2.3 节强调备份基线的原因。5.4 NAT 配置后回程流量丢失现象目的 NAT 配置后外部测试机可以建立 TCP 连接但页面一直加载不出来抓包发现有去程没回程。原因回程流量需要防火墙再执行一次源 NAT 转换把服务器的内网地址转换成公网地址。如果只配了目的 NAT 没配对应的回程转换规则回程包到达防火墙后找不到转换关系直接被丢弃。解决检查 NAT 策略是否覆盖了双向转换。常见做法是目的 NAT 配置时同时指定源地址转换规则让外部访问内网服务器的流量在回程时自动执行源 NAT。另一种情况是内网服务器回去的流量走了另一条路由比如服务器自己配了网关指向别的设备导致回程包没经过防火墙需要检查服务器网关配置。5.5 策略日志刷屏导致存储告警现象防火墙磁盘可用空间持续下降告警邮件不断登录 Web 管理面也变得很慢。原因放行策略上开了日志而这个策略匹配的流量非常大比如内网到外网的宽泛放行策略开启了日志记录每一条新连接都会产生日志日志量迅速膨胀。解决把日志开关精细化。内网到外网的宽泛策略建议关闭日志只对需要审计的敏感访问开启。比如访问财务系统、远程管理设备这类流量保留日志普通网页浏览不记。如果日志已经写满先清理历史日志释放空间再调整策略日志配置。这里补充一句日志不是越多越好能说明问题的日志才有价值。6. 用会话表和配置diff做日常验证让每一次变更都可回溯配置工作做完不是终点日常维护中的变更验证才是真正考验细心程度的地方。我自己的固定流程是每次变更前导出当前配置变更后导出新配置用文本对比工具逐个字段核对差异同时在会话表里观察业务流量是否真的走了新策略。# 变更后导出配置 show configuration config_after_change.txt # 在本地对比变更前后的配置差异 diff config_before_change.txt config_after_change.txtdiff命令输出每一行差异能直接看到新增了哪些策略、修改了哪些地址对象。这条命令在 Linux 环境里直接能用Windows 可以用记事本对比插件或者装一个 diff 工具。我见过的很多线上事故根源都是“以为只改了一条策略”实际上误删了另一条关键放行规则配置 diff 能第一时间发现这类问题。会话表是另一个验证工具。变更 NAT 或路由后在防火墙执行show session table destination-ip筛选目标地址观察新旧会话的转换结果。如果发现会话表中的转换地址和预期不符说明 NAT 策略的匹配顺序有问题需要回滚或调整。还有一个长期维护技巧定期检查策略命中计数清理长期零命中的策略。很多防火墙跑了一两年策略列表里累积了几百条规则大部分已经没人用了。零命中策略不影响转发性能但会让排查变得非常痛苦——你永远不知道这条策略是不是前人在某个特殊场景下加的删了会不会出问题。我建议每季度导出一份策略列表和命中计数把连续三个月命中计数为 0 的策略标记出来跟业务方确认后再清理。清理前先导出配置备份清理后观察一周会话表确认无异常再删下一个。这个节奏虽然慢但安全。回到开头那句话东软防火墙配置不是一个敲命令的活是一个管理预期的活。每次变更都留痕迹每次排障都看会话表和命中计数让配置可回溯、可验证这台防火墙才能真正成为一个可靠的安全边界。这套流程帮我少熬了好几次夜希望帮到你。本文还有配套的精品资源点击获取
