目
录
1 Hillstone 厂商联系方式
Hillstone400 服务热线—— 400 828 6655
2 进行用户环境调查
在解决用户故障前一定要清晰了解用户的现场环境，并生成《 XXX 客户服务过程记录》。
如果已经进行过调查则确认用户环境是否有变化，修改原有《 XXX 客户服务过程记录》，另存为一个新的文档。
3 故障处理基本思路
|
指示灯 |
颜色 |
说明 |
|
PWR |
绿色常亮 |
系统电源工作正常 |
|
橙色常亮 |
电源工作异常 |
|
|
红色常亮 |
电源工作异常，此时系统处于关闭状态 |
|
|
熄灭 |
系统没有供电或处于关闭状态 |
|
|
STA |
绿色常亮 |
系统启动并正常运行 |
|
绿色闪烁 |
系统已启动并且正常工作 |
|
|
红色常亮 |
系统启动失败或者系统异常 |
|
|
ALM |
红色常亮 |
系统告警 |
|
绿色闪烁 |
系统处于等待状态 |
|
|
熄灭 |
系统正常 |
|
|
橙色闪烁 |
系统正在使用试用许可证 |
|
|
橙色 |
试用许可证到期，无合法许可证 |
|
|
HA |
绿色常亮 |
只有一台设备，工作在 master 状态 |
|
绿色闪烁 |
有一主一备两台设备，本设备工作 master 状态 |
|
|
橙色闪烁 |
有一主一备两台设备，本设备工作 slave 状态 |
|
|
红色闪烁 |
HA 工作异常 |
|
|
LNK |
绿色常亮 |
端口与对端设备通过网线或光纤连接且连接正常 |
|
熄灭 |
端口与对端设备无连接或端口连接失败 |
|
|
ACT |
橙色闪烁 |
端口处于收发数据状态 |
|
熄灭 |
端口无数据传输 |
设备不能通过某些 pc 实现管理，原因：
l 查看设备时候配置有可信任主机，并且该地址是否在可信任主机列表中。
web 下位置：系统 - 设备管理 - 可信任主机
cli 下命令： show admin host
l 添加可信任主机及权限方法：
web 下位置：系统 - 设备管理 - 可信任主机 - 新建
cli 下命令： SA(config)# admin host A.B.C.D/M any
如果 Hillstone 山石网科数据中心防火墙的管理员口令丢失，请与当地代理商联系或通过系统复位的方法将密码恢复为出 厂默认值（警告：系统复位的同时所有设备信息都会恢复出厂设置，配置文件会被删除，请谨慎使用！）
l 使用 show vession 命令查看设备版本信息，如果版本低，是否存在 BUG
确定是否是因设备引起的。
在移除设备不会影响网络应用或影响较小容易调整且用户允许的情况下，将怀疑有故障的设备从网络中移出，看应用是否正常。如果还不正常则要怀疑是否有其他故障。建议解决其他故障后再将设备还原回原来状态。
单独测试故障部分链路及应用。
4 各类故障处理
扩展模块出现故障时，请对设备进行以下检查：
l 检查扩展模块是否与背板紧密接触，松不脱螺丝是否已经拧紧。
l 确认当前的 StoneOS 版本为 StoneOS 5.0 。
l 使用 show module 命令查看扩展模块的状态信息，具体请查看《 Hillstone 山石网科数据中心防 火墙命令手册》。
冷却系统包括风扇盘和过滤网。当风扇盘故障或过滤网堵塞时，机箱不能良好散热，导致温度升高， 如果温度过高，系统将自动关闭。
当冷却系统出现故障时，请对设备进行以下检查：
l 使用 show environment 命令查看设备的温度和风扇盘转速，具体请查看《 Hillstone 山石网科 数据中心防火墙命令手册》。
l 查看风扇盘指示灯。风扇正常运行时，指示灯为绿色常亮；当指示灯显示红色，表示一个或更多的 风扇故障，请尽快更换风扇盘，避免系统过热，具体操作参阅冷却系统更换。
用户可以根据电源指示灯的状态来判断产品电源系统是否发生故障，电源指示灯的状态及含义请参照 指示灯含义。电源系统工作正常时，电源指示灯应该保持绿色常亮；电源指示灯不亮时，请对设备进行以 下检查：
l 设备电源线是否连接正确。
l 设备的供电电源与所要求的电源是否一致。
4.1.4 Console 配置系统故障处理
设备上电后，如果配置系统正常，将在配置终端上显示启动信息；如果配置系统出现故障，配置终端 可能无显示或者显示错误信息。
若配置终端无显示信息，请先进行如下检查 :
l 电源是否正常。
l 配置电缆连接是否正确。
l 终端配置是否正确。 若以上检查未发现问题，则可能是配置电缆故障，请进行检查。
此部分主要检查线路是否正常。
故障定位
双绞线：
l 检查网线线序是否符合规范。
l 检查网线接口是否插牢，是否正常。
l 检查指示灯状态是否正常。
l 网线内有断线情况，可能导致指示灯正常但线路不通。
l 检查线路所经路径上是否有大功率设备干扰。
l 检查线缆长度，是否超过 105 米。一般情况下，线路过长很容易引起信号强度下降、线路干扰过大。
光纤：
l 检查光纤接口是否插牢。
l 检查光纤类型和设备接口类型是否相符，单模、多模。
l 如果是单模光纤，如果激光功率太强或太弱也会导致通讯异常。检查是否需要使用衰减器。
解决办法
更换合格的线路。
如果是单模光纤激光强度异常，需要使用测试仪检测，调整强度即可。
如果是激光过强，可以用缠绕光纤的办法进行衰减，可以达到衰减器的效果。
参考资料
RJ45 网线水晶头排线范参考如下：
1 2 3 4 5 6 7 8
T568A 的线序为：白绿，绿，白橙，蓝，白蓝，橙，白棕，棕
T568B 的线序为：白橙，橙，白绿，蓝，白蓝，绿，白棕，棕
不使用 HUB 或交换机两机连接，两端分别用 T568A 和 T568B ；
使用 HUB 或交换机则统一使用 T568B 。
一般情况下，网线只有 1 2 和 3 6 四根线起作用。
传输距离与速度：
超五类双绞线的最大传输距离为 105 米，平均传输速度为 100M （最大峰值 155M ）。前提是双绞线的各项性能指标都要达到超五类双绞线的标准。
故障定位
检查线路通信状态。
使用 PC 或单独设备直连此链路，测试链路质量、速度。
检查用户接入设备状态，运行参数、跳线等是否正常。
如果是端到端设备检查两端设置是否一致。
SDH 网络使用的协议转换器可能因局端作了环路，造成大量广播，现象类似于环路，可能造成防火墙不能正常收发。
案例：
ADSL ：可能因 ADSL 提供商原因造成无法正常通讯，此时使用 PC 直接连接（可能是拨号，也可能是路由），测试线路是否能够正常传输，检查丢包率，测试接入速度。
专线：某单位采用 SDH 专线连接各分支，发现不通，经链路提供商测试物理线路正常。详细了解发现，此单位适用端到端的转换设备（ SDH-ETH ），但两端的转换设备的跳线设置不通，即两端设备的工作模式不同。将两端设备设成同一模式后线路通讯正常。
解决办法
请线路提供商调整线路；
调整接入设备的参数；
调整端到端设备的模式；
故障定位
检查两端设备协商速率及全双工 / 半双工模式。
检查两端设备是否一致。
察看数据包收发数量，查看是否有只有发包没有收包，或收发包差距非常明显的情况。
察看校验错误包是否很多。
解决办法
调整两端设备配置， 100 兆链路推荐设为：两台设备都设为 100M 全双工。
调整设备其他参数。
4.2.1.2.3 MAC 地址表错误
故障定位
检查是否学到真实的 MAC 地址。
本端和对端是否一致。
确认是否有地址冲突。
确认是否有 ARP 攻击。
解决办法
临时解决：
清理错误的 MAC 地址表。
手工绑定 MAC 对应关系。
最终解决：
找到 MAC 地址表错误的原因。
清理网络攻击源。
故障定位
也请参考 : ping
小包能 ping 通，但大包无法 ping 通，很可能是 MTU 问题。
部分应用不通，但其他应用正常也有可能与 MTU 值有关。
可以用 Ping 大包的方式测试是否有 MTU 问题。
故障原因
防火墙接口 MTU 值能小于嵒机 MTU 值，例如：
当防火墙的接口 MTU 值设为 1300 时，主机的 MTU 值缺省为 1500 时，主机穿过防火墙的连接能够打开服务器的相关页面，但修改相关的资料时无法提交成功。分析为防火墙接口 MTU 值比主机 MTU 值小，主机与服务器协商出合适的 MSS 值，但经过 IP 层封装后的某些数据包就会大于 1300 但不大于 1500 ，并且对不大于 1500 的包 DF 位置 1 ，这样的包到达防火墙后就被防火墙丢弃了。因此就会出现能够打开网页，但修改资料无法提交成功及通过网页收发邮件无法上传附件等现象。建议正常情况下要修改防火墙的 MTU 值。
解决办法
尝试调整防火墙 MTU 值，使之符合应用的要求。
可以通过抓包分析判断 MTU 值。
4.2.1.3.1 Vlan 号错误
故障定位
检查 Vlan 的设置，是否有需要的 Vlan 号；
检查接口设置，确认关联接口属于 Trunk 需要的 Vlan 范围。检查接口的 NativeID 。
检查前后设备的 Vlan 配置。
故障原因
防火墙在 Trunk 模式下，如果想要前后设备的 Vlan 通讯，必须在防火墙 Vlan 设置里绑定相应的 Vlan 号。
解决办法
故障定位
检查相邻设备 Vlan 配置， Vlan 号、 Trunk 设置。
注意相邻设备 Trunk 类型。部分路由交换设备的默认协议是 dot1q ，但如果防火墙接入则可能造成无法正常穿越，需要手工将路由交换设备的协议指定为 dot1q 才可以。
解决办法
正确配置防火墙接口、 Vlan 等参数；
遇到前后设备采用默认 Vlan 类型，即便默认类型也是 802.1q ，也要手工设置为 802.1q 。
4.2.1.4.1 自身 ARP 表错误
故障定位
检查防火墙自身 ARP 表是否真实
确认网络中是否有 ARP 攻击，可能因 ARP 攻击造成 IP-MAC 地址对应错误。
部分网络监控、管理软件采用 ARP 攻击原理工作，确认网络是否有类似软件。如：网络执法官、 P2P 控制软件等。
故障原因
ARP 攻击会造成受影响的防火墙及客户端 ARP 表错误，即造成 IP 地址与 MAC 地址对应错误，使得数据报不能正确地发送给真实的主机。
解决办法
在防火墙及所有客户端均进行 ARP 绑定。
清除网络内 ARP 攻击源。
参考资料
要了解故障原理，我们先来了解一下 ARP 协议。
在局域网中，通过 ARP 协议来完成 IP 地址转换为第二层物理地址（即 MAC 地址）的。 ARP 协议对网络安全具有重要的意义。通过伪造 IP 地址和 MAC 地址实现 ARP 欺骗，能够在网络中产生大量的 ARP 通信量使网络阻塞。
ARP 协议是 “Address Resolution Protocol” （地址解析协议）的缩写。在局域网中，网络中实际传输的是 “ 帧 ” ，帧里面是有目标主机的 MAC 地址的。在以太网中，一个主机要和另一个主机进行直接通信，必须要知道目标主机的 MAC 地址。但这个目标 MAC 地址是如何获得的呢？它就是通过地址解析协议获得的。所谓 “ 地址解析 ” 就是主机在发送帧前将目标 IP 地址转换成目标 MAC 地址的过程。 ARP 协议的基本功能就是通过目标设备的 IP 地址，查询目标设备的 MAC 地址，以保证通信的顺利进行。
每台安装有 TCP/IP 协议的电脑里都有一个 ARP 缓存表，表里的 IP 地址与 MAC 地址是一一对应的，如下表所示。
主机 IP 地址 MAC 地址
A 192.168.16.1 aa-aa-aa-aa-aa-aa
B 192.168.16.2 bb-bb-bb-bb-bb-bb
C 192.168.16.3 cc-cc-cc-cc-cc-cc
D 192.168.16.4 dd-dd-dd-dd-dd-dd
我们以主机 A （ 192.168.16.1 ）向主机 B （ 192.168.16.2 ）发送数据为例。当发送数据时，主机 A 会在自己的 ARP 缓存表中寻找是否有目标 IP 地址。如果找到了，也就知道了目标 MAC 地址，直接把目标 MAC 地址写入帧里面发送就可以了；如果在 ARP 缓存表中没有找到相对应的 IP 地址，主机 A 就会在网络上发送一个广播，目标 MAC 地址是 “FF.FF.FF.FF.FF.FF” ，这表示向同一网段内的所有主机发出这样的询问： “192.168.16.2 的 MAC 地址是什么？ ” 网络上其他主机并不响应 ARP 询问，只有主机 B 接收到这个帧时，才向主机 A 做出这样的回应： “192.168.16.2 的 MAC 地址是 bb-bb- bb-bb-bb-bb” 。这样，主机 A 就知道了主机 B 的 MAC 地址，它就可以向主机 B 发送信息了。同时它还更新了自己的 ARP 缓存表，下次再向主机 B 发送信息时，直接从 ARP 缓存表里查找就可以了。 ARP 缓存表采用了老化机制，在一段时间内如果表中的某一行没有使用，就会被删除，这样可以大大减少 ARP 缓存表的长度，加快查询速度。
从上面可以看出， ARP 协议的基础就是信任局域网内所有的人，那么就很容易实现在以太网上的 ARP 欺骗。对目标 A 进行欺骗， A 去 Ping 主机 C 却发送到了 DD-DD-DD-DD-DD-DD 这个地址上。如果进行欺骗的时候，把 C 的 MAC 地址骗为 DD-DD-DD-DD-DD-DD ，于是 A 发送到 C 上的数据包都变成发送给 D 的了。这不正好是 D 能够接收到 A 发送的数据包了么，嗅探成功。
A 对这个变化一点都没有意识到，但是接下来的事情就让 A 产生了怀疑。因为 A 和 C 连接不上了。 D 对接收到 A 发送给 C 的数据包可没有转交给 C 。
做 “man in the middle” ，进行 ARP 重定向。打开 D 的 IP 转发功能， A 发送过来的数据包，转发给 C ，好比一个路由器一样。不过，假如 D 发送 ICMP 重定向的话就中断了整个计划。
D 直接进行整个包的修改转发，捕获到 A 发送给 C 的数据包，全部进行修改后再转发给 C ，而 C 接收到的数据包完全认为是从 A 发送来的。不过， C 发送的数据包又直接传递给 A ，倘若再次进行对 C 的 ARP 欺骗。现在 D 就完全成为 A 与 C 的中间桥梁了，对于 A 和 C 之间的通讯就可以了如指掌了。
故障定位
测试对方设备是否有 ARP 绑定。
询问对方管理人员是否有 ARP 绑定。
可能因对端设备压力较大、运行故障等原因造成对方 ARP 表不能及时更新，表现的现象和 ARP 绑定相似。
故障原因
如果对方存在 ARP 绑定会造成发过去的所有数据包均被丢弃，使得网络不通。
解决办法
要求对方重新绑定。
修改防火墙对应接口 MAC 地址为绑定的地址。
如果是假绑定，多等待一段时间、多重启几次防火墙，或重启对方设备都有可能解决。
4.2.2.1.1
故障定位
通过 Ping 、 Tracert 等方式确定整个路径上的各个节点的工作状态。
定位问题出现在那台设备上。
检查有问题设备的路由表。
检查传输过程中是否有 NAT ，转换是否正常。
一般按照下面的方法进行。
可分为 Ping 小包、 Ping 大包两种方式。
要按照网络拓扑，由近及远，依次 ping 各个 IP 。
ping x.x.x.x -t
ping x.x.x.x -l 1472 -f
ping 长度为 1472 的满包， -f 表示不分片
ping x.x.x.x -l 1473
ping 长度为 1473 的包，此包超过最大单包长度，测试 MTU 问题；
测试线路由近及远的各个节点，目前可能因中间设备导致不通。此方法仅在少数环境下有效。
4.2.2.1.2
路由分析
要从路由中明确数据包的传输路径，分析数据包是否能够正确的传出并返回。
配置时需要用命令行将静态路由发布出去
发布静态路由命令
OSPF redistribute static
还有发布 IP 、发布直连路由
4.2.2.1.3
解决办法
如果路由错误则调整路由表。
如果 NAT 设置错误则调整 NAT 策略。
MTU 问题则须调整 MTU 值。
首先确定服务所使用的协议及端口号；
故障定位
策略
检查防火墙 PF 策略中是否已将相应协议及端口号放开；
检查防火墙通讯策略中是否已将相应协议及端口号放开；
策略
检查防火墙 NAT 策略中是否已将相应地址、协议及端口号进行了正确的转换；
有时会因地址转换后 NAT 和 MAP 不一致导致应用不通。
接收正常，发出的邮件经常被退。
可能因 NAT 和 MAP 不一致，导致地址反解析错误，地址被拒绝。
也请参考 : 考虑双出口路由
部分网络银行的验证比较严格，可能因地址转换导致登陆 IP 与访问的 IP 不同，造成访问被拒绝。
策略
如果是 HTTP 、 FTP 、 SMTP 、 POP3 等服务，检查应用端口绑定中是否有此应用服务的端口。
检查防火墙 DPI 策略中是否已将相应服务放开；
也请参考 : 路由分析
再查 ARP 表
也请参考 : ARP
解决办法
搞清用户需求。
分析数据流程。
调整策略。
4.2.4 设备测试 License 到期重启问题
默认出厂设备有测试 License ，如果设备测试 License 到期后未导入正式 License 或续期测试 License ，重启后则防火墙恢复出厂配置（原配置文件保存在防火墙内，但无法引导）。
4.3.1 CPU 占用率过高
l 查看设备当前吞吐是否到达设备极限，如果到达设备极限，建议通过减少通过设备流量，或者更换其他高性能防火墙的方式来解决。
l 查看设备是否开启太多的统计集，如果统计集功能开启较多会占用较大 cpu ，建议通过关闭统计集的方法来降低 cpu 的使用率。如果确实需要开启统计集，建议在一定时间内开启，待结果统计出来后即刻关闭统计集。
l 查看设备是否开启 debug ， cli 下输入 show debug 如果开启建议关闭 debug ，方法：使用命令 undebug all 。
l 设备开启太多占用 cpu 资源的功能，建议暂时关闭部分功能，或者更换高性能防火墙。
l 查看设备上是否有 DoS/DDos 攻击流量，开启攻击防护中的 SYN Flood 和 UDP Flood 攻击防护功能。
4.3.2 Session 数过高
通过 show session generic 或 web 查看到设备 session 数使用过多，解决方法：
l 在统计集中开启基于用户的 session 数统计，查看具体 session 数字过大的 ip ，手动将该 ip 的 session 删除，命令： clear session src-ip ip-address ，来暂时降低设备的 session 。
l 通过配置 session-limit 的形式来控制用户的 session 数
l 查看设备上是否有 DoS/DDos 攻击流量，开启攻击防护中的 SYN Flood 和 UDP Flood 攻击防护功能。
4.3.3 HA 异常处理
在 HA 正常配置后，如果网络结果不发生变化，很少出现问题。如果出现问题一般是由于 HA 心跳线由于某种原因断开所致。
建议出现问题后先通过下面的几个命令查看 HA 状态，可以先暂时将备用设备的 HA 功能关闭，检查两台设备 HA 部分配置是否一致，确认无误后再开启备用设备的 HA 功能。
查看 HA 状态命令 :
l show ha link status // 查看 HA link 状态 ，确认 HA link 接口状态是否正常。
l show ha group config // 查看 HA group 配置状态 ，确认 HA group 相关配置。
l show ha group 0 // 通过查看 HA group 0 状态 ，确认对端状态是否正常。
l show ha cluster // 查 HA 簇配置信息。
l show ha sync state config // 查看 HA 配置同步状态。
l no ha cluster // 关闭 HA 配置。
l 确认用户到到网关是否丢包，如果内网网关丢包请检查内网交换、路由问题。
l 确认到内网不丢包，到外网网关丢包，请检查从防火墙上到外网网关是否有丢包，如果丢包请联系线路供应商检查链路质量。
l 确认从防火墙上到外网网关不丢包，请检查防火墙 cpu 是否很高，如果 cpu 高请根据 cpu 高的处理方法操作。
l 确认 cpu 不高，请开启接口带宽统计集，查看接口带宽是否占满，如果带宽占满，请考虑通过配置 qos 功能对流量做控制。
l 确认带宽不高，请检查 snat 的转换后地址源端口占用检测，使用命令 show snat resource vrouter trust-vr
4.3.5 目的 NAT 不生效的处理
l 检查服务器本身端口是否开启。
l 检查是否有从外到内的策略是否有放行，源地址为 any 目的地址为映射后的公网地址。
l 检查内网服务器网关配置是否正确
5 debug 诊断与排错
5.1 debug 数据流基本步骤
1 、关闭 debug 信息输出到 console
no logging debug to console
2 、清除缓存 debug 日志信息
clear logging debug
3 、设置 debug 过滤器
debug dp filter {src-ip | src-port | proto | dst-ip | dst-port}
4 、开启 debug 功能
debug dp basic
5 、发起数据流访问
6 、查看 debug 日志信息
show logging debug
7 、关闭 debug
undebug all 或 连击“ ESC ”两次 （必须退出，否则影响 CPU 性能）
8 、查看调试功能开启或者关闭状态
show debug
9 、查看 debug 过滤器
show dp-filter
10 、删除 debug 过滤器
undebug dp filter id
5.2 各种情况下 debug 信息
5.2.1 正常访问 debug 信息 :
hostname(config)# sh log deb
2009-03-04 16:17:39, DEBUG@FLOW: core 0 (sys up 0x8e65ae ms): 001d.7294.e5f6->00
1c.5402.8c00, size 73, type 0x800, vid 0, port ethernet0/0
Switchid is 8(interface ethernet0/0) port ethernet0/0
Start l3 forward
Packet: 192.168.1.12 -> 202.106.0.20, id: 8369, ip size 59, prot: 17(UDP): 3332
-> 53
① No session found, try to create session
----------------First path creating new session-----------------
--------VR:trust-vr start--------
192.168.1.12:3332->202.106.0.20:53
② No DNAT configured for this VR
③ Get nexthop if_id: 10, flags: 0, nexthop: 10.188.9.1
④ Found the reverse route for force revs-route setting
⑤ Matched source NAT: snat rule id:1
Matched source NAT: source port3332->port3332
--------VR:trust-vr end--------
⑥ Pak src zone trust, dst zone untrust, prot 17, dst-port 53.
Policy 1 matches, ===PERMIT===
⑦ Identified as app DNS (prot=17). timeout 60.
flow0 src 192.168.1.12 --> dst 202.106.0.20 with nexthop 0.0.0.0 ifindex 0
flow1 src 202.106.0.20 --> dst 10.188.9.100 with nexthop 192.168.1.12 ifindex 8
flow0's next hop: 192.168.1.12 flow1's next hop: 10.188.9.1
crt_sess->revs_rres.nextop: 192.168.1.12, crt_sess->revs_rres.nexthop 10.188.9.1
Application 7 hasn't been registered, don't need do ALG
APP inited for application 7
The following session is installed
⑧ session: id 99962, prot 17, flag a, created 9332, life 60
flow0(if id: 8 flow id: 199924 flag: 801): 192.168.1.12:3332->202.106.0.20:53
flow1(if id: 10 flow id: 199925 flag: 800): 202.106.0.20:53->10.188.9.100:3332
Session installed successfully
-----------------------First path over---------------------
⑨ Found the session 99962
session: id 99962, prot 17, flag 4a, created 9332, life 60
flow0(if id: 8 flow id: 199924 flag: 811): 192.168.1.12:3332->202.106.0.20:53
flow1(if id: 10 flow id: 199925 flag: 810): 202.106.0.20:53->10.188.9.100:3332
Set fast code to fe proc
Go to fe proc directly
Got mac: ip:10.188.9.1, mac:001c.5400.1dc1
L3 forward, out if is ethernet0/2
msw_dsa_tag_encap_from_cpu: TX packet from interface ethernet0/2, vid 0 cos 0.
-----------------First path creating new session-----------------
--------VR:trust-vr start--------
192.168.1.12:55577->10.188.7.10:53
No DNAT configured for this VR
Failed to get route to 10.188.7.10 ( 找不到路由存在 )
Dropped: Can't find forwarding route. Abort!!
deny session:flow0 src 192.168.1.12 --> dst 10.188.7.10 Deny session installed s
uccessfully
--------VR:trust-vr end--------
-----------------------First path over (session not created)
Droppped: failed to create session, drop the packet
-----------------First path creating new session-----------------
--------VR:trust-vr start--------
192.168.1.12:4716->202.106.0.20:53
No DNAT configured for this VR
Get nexthop if_id: 10, flags: 0, nexthop: 10.188.9.1
Found the reverse route for force revs-route setting
Matched source NAT: snat rule id:1
Matched source NAT: source port4716->port4716
--------VR:trust-vr end--------
Pak src zone trust, dst zone untrust, prot 17, dst-port 53.
No policy set in this ctxt, default ===DENY=== ( 找不到策略允许 )
Dropped: Can't find policy/policy denied. Abort!!
deny session:flow0 src 192.168.1.12 --> dst 202.106.0.20 Deny session installed successfully
-----------------------First path over (session not created)
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/31550410/viewspace-2200301/ ，如需转载，请注明出处，否则将追究法律责任。
