简介：东软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 的策略标记出来，跟业务方确认后再清理。清理前先导出配置备份，清理后观察一周会话表，确认无异常再删下一个。这个节奏虽然慢，但安全。
回到开头那句话：东软防火墙配置不是一个敲命令的活，是一个管理预期的活。每次变更都留痕迹，每次排障都看会话表和命中计数，让配置可回溯、可验证，这台防火墙才能真正成为一个可靠的安全边界。这套流程帮我少熬了好几次夜，希望帮到你。
本文还有配套的精品资源，点击获取
