- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
手册下载
H3C SecPath多级安全互联交换平台
故障处理手册
Copyright © 2022新华三技术有限公司 版权所有，保留一切权利。
非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。
除新华三技术有限公司的商标外，本手册中出现的其它公司的商标、产品标识及商品名称，由各自权利人拥有。
本文档中的信息可能变动，恕不另行通知。
2.4 无法给正常通道添加策略、对IP进行操作、停启用通道等平台操作
2.12 FTP应用，平台通道可以停启用，两边连通性也没问题，但是应用不通怎么办？
2.13 oracle应用，平台通道可以停启用，两边连通性也没问题，但是应用不通怎么办？
2.27 SIP通道配置后，信令中的码流接受地址未替换成平台自身IP，怎么办？
2.28 配置TCP通道访问HTTP应用时，两边能够建立TCP会话，但是应用层数据无法交换，业务访问无法实现（页面显示不全或下载内容不完整）如何判断问题？
2.29.3 带宽压力下UDP应用不稳定但TCP应用未出现问题。
2.30 数据库同步，已经配置同步的两个表，更改了表名或删除表，会出现数据库配置无法删除，怎么办？
2.31 平台数据库同步。设备重启时如果业务口链路是断线状态，待启动成功后接线，可能导致同步服务无法启动。
本文档介绍H3C SecPath多级安全互联交换平台产品软、硬件常见故障的诊断及处理措施。
(1) 通道中正在使用此网卡上的IP。
(2) HA设置中正在使用此网卡。
(1) 删除此通道或清空此网卡上IP。
(2) 取消HA加入的此网卡。
(3) 清空此网卡IP绑定的路由。
(1) 选择的网卡上没有填写IP地址。
(2) 网关IP地址网段没有和所选网卡IP地址对应。
(3) 平台内部通信异常，请致电我公司技术支持部，进一步排错指导。
(1) 确认网卡上是否有相应的IP。
(2) 确认编辑路由时各项设置是否正确。
(1) 配置文件不匹配。
(2) 导入的配置文件设置有密码。
(3) 平台内部通信异常，请致电我公司技术支持部，进一步排错指导。
(1) 检查导入的文件是否匹配。
(2) 确认导入的文件是否设置的有密码。
(3) 确认编辑路由时各项设置是否正确。
无法给正常通道添加策略、对IP进行操作、停启用通道等平台操作。
平台内部通信异常，请致电我公司技术支持部，进一步排错指导。
(1) FTP通道上追加的FTP可上传和下载敏感词策略不是txt格式类型。
(2) 平台内部通信异常，请致电我公司技术支持部，进一步排错指导。
使用此类型策略时，建议文件类型使用txt格式。
区别于常用路由交换设备。由于平台属隔离设备，目前不存在也不应该存在网络底层测试工具，能直接确认整体连通性。目前唯一能证明平台联通性的方法，只有使用配置的应用才可确认。
登录进平台停启用通道，如果通道启用过程中存在错误，那么就是平台内部问题了。如果能够正常停启用，至少证明平台内部通讯没有问题，通常问题都出在网络或配置上。
首先确认双机热备服务有没有开启，如果开机前已经是启用状态，并且显示备机状态，那就说明是双机热备程序阻断了平台通讯。请检查配置的监听网口是否都插上网线了。
若远程操作，可以通过网卡状态进行查询。
如果不是双机热备原因，请在CLI命令行页面使用ns netstat –an命令查看监听端口是否开启。如果通道是前置到后置，就看前置监听端口。如果是后置到前置，就查看后置监听端口。
在确认通道有对应监听开启后，需要分两段检查两边网络问题。分别为客户端到平台之间的网络情况，和平台到服务端的网络情况。
客户端到平台之间的网络连通性，可用从客户端telnet平台通道端口来测试。如果telnet通就没问题，如果telnet不到就说明网络有异常。需要找客户来进一步查明原因。检查链路上是否有其它安全产品拦截了，或者路由是否可达。
平台到服务端之间的网络连通性，可以通过界面上的网络诊断工具进行诊断，判断依据同上。
如果两边telnet都通的，那可能就是应用协议或配置上问题了。需要抓包具体分析。
netstat –an 查看详细连接状态或者 ns netstat –an 查看详细连接状态
注：后续演示都以C/S管理模式平台为基础指令，在B/S管理模式平台中自行在前端添加ns
如果连接数太多可以在后面加|more，分行显示，比如：
netstat –an|more 按回车往下翻一行，按空格则往下翻一页（全屏相当于25行）
下面这个命令是统计连接数的，他不会显示具体连接，但是会把每种连接的总数统计出来
netstat -an|awk '/^tcp/{++s[$NF]} END {for(a in s)print a,s[a]}'
小窍门：如果命令太长不方便打，只要在文本上复制下，随后点putty的界面，按下右键就能粘帖上去了。
下面简单说下TCP协议的连接状态
LISTEN 这是服务监听，平台上配了多少通道就有多少个LISTEN。
ESTABLISHED 这是正常的连接。TCP三次握手成功后，正常连接的状态。
TIME_WAIT 连接断开后，会有一段时间的等待。系统每三十秒回收一次。
-------------------------------------------------------------------------------------------------------------------------------
SYN_SENT
SYN_RCV
FIN_WAIT1
FIN_WAIT2
上面4个分别是TCP建立连接和释放连接的临时状态。一般这种状态只存在零点几秒。当然这取决于网络延迟的多少。如果持续5秒以上那肯定有问题了。如果超过1分钟那基本就可以确认为异常连接了。如果要用netstat查看的话可以加写过滤语句，比如
netstat –an | grep SYN 只显示SYN建立连接的状态
netstat –an | grep FIN 只显示FIN关闭连接的状态
--------------------------------------------------------------------------------------------------------------------------------
CLOSE_WAIT 这种就是异常关闭的连接，必须注意。往往就是这种连接状态造成平台宕机
通常来说SYN、FIN、CLOSE_WAIT加起来不超过100的话系统负担不会太大。但如果数量不减少，每隔30秒也不清除，那就很容易造成平台的系统资源被过多占用而宕机。
笔记本需要开启FTP服务，CLI命令行页面操作如下：
ftp 服务器IP 用FTP下上传日志
FTP用户名（根据实际情况调整）
FTP密码（根据实际情况调整）
put 日志名
或者通过SCP工具直接将日志拷贝到本地。
/var/log/adminserver.log web管理端日志
/var/log/exchanger.log 通道日志
/var/log/exchanger-go.log 通道日志
/var/log/filesync.log 文件同步通信日志
/var/log/dbsyncserver.log 数据库同步日志
/var/log/syncweb.log 文件同步和数据库同步web管理日志
/var/log/upgrade.log 升级日志
(1) 直接通过界面查看版本信息。
(2) 在CLI命令行页面执行cat /etc/ferryway-release
检查通道是否选用了FTP类型。检查FTP服务器是否支持被动访问模式。由于FTP应用协议会动态协商数据端口，重新建立连接。而平台出于安全考虑是不允许外部随便连进来的。所以数据端口只能由平台去练服务端，这就要求FTP服务必须支持被动访问模式。同理，客户端的数据端口也只能由平台来连客户端，因此客户端防火墙必须为此做相应调整。
ORACLE服务器如果是Windows平台的，并且使用默认的专用访问模式，那通道类型就要选oracle类型。但如果是UNIX等平台的。使用的是共享访问模式的，通道类型就要选用NULL_tcp类型。
联系公司专人负责远程支持解决
当内部用户需要通过平台访问外部WEB应用服务。如果服务中带有百度地图应用，那么客户端就需要到Internet上找百度的服务器。
（目的IP无法配置域名的版本）解决办法分2步：
(1) 解决DNS解析问题。配一条端口为53的UDP通道，目标IP为外网设置的DNS地址。随后将客户端DNS改成平台前置的这个IP。
(2) 通过抓包比对过平台和不过平台时客户端访问了哪些80端口的地址。百度地图的服务就在这些80端口的连接中。统计不过平台时多出的这些80端口连接。映射相同IP（内网别忘了加路由）。一个一个IP做尝试，直到网页上能打开百度地图。如果用户能提供百度地图的服务器域名和IP就更好了。
（目的IP可配置域名的版本）解决办法：直接将域名填入目的地址，同时注意需要在平台的一端机上配置DNS服务器地址（目的域名在哪侧DNS地址就配置在哪侧），重复上述解决办法的第二步。
当内部用户需要通过域名来访问外部应用时。（无论是用浏览器的Web应用还是某些程序内置应用）
(1) 内部用户修改本机的hosts文件，将域名映射成平台前置IP地址。或用户内部具有DNS解析服务器，将域名解析成平台前置IP地址。
(2) （目的IP无法配置域名的版本）
自行在外网进行解析，将解析后的地址直接配置在目的IP中。注：若域名解析出来的实际地址会发生变动，可能会发生应用无法访问的现象。
(3) （目的IP可配置域名的版本）
直接将域名填入目的地址，同时注意需要在平台的一端机上配置DNS服务器地址（目的域名在哪侧DNS地址就配置在哪侧）。
默认频率为115200，如果不行请尝试9600。不同批次可能默认频率不同。
平台两侧TCP连接正常；源端抓包未发现TCP握手失败的连接；抓包follow内外应用层信息，两边内容一致，但是过平台页面打不开，不过平台就没问题，如何解决？
某些WEB应用访问不是单一会话构成的。可能在访问时会同时建立多个http会话。比如一些认证服务器。某些网站在登录帐号时，会寻求其它认证服务器的验证，因此会额外建立新的会话。由于这些IP和端口可能和原有应用不同，混在众多会话中难以查找和验证。如何跟踪一次WEB应用访问，调查页面卡在哪个url成了关键。
操作方法：使用google chrome浏览器。按F12进入开发模式。然后打开要访问的页面。
右边列表可以轻松看到打开的每个URL。如果有资源连接不上，会显示红色。我们只要查这些红色的url是不是连接了新的域名或IP即可。很有可能服务器反馈了一个新的域名，导致内网无法直接做DNS解析，从而不再发送新的连接，最终导致抓包无法发现问题。
查找302重定向的包，比较容易看到此类现象。比抓包分析要方便。
通道可以添加、修改、启用、停用，但是无法删除。之前没有配过策略。而且CLI命令行页面查看IP都是在的，没有丢失IP的情况。
检查adminserver.log日志，检查表是否有问题
比如发现gap_traffic_speed表需要修复
进入数据库
Mysql –uroot –pJdwa*2003 ferryway
随后后执行:
REPAIR TABLE gap_traffic_speed USE_FRM
若界面仍然无法删除通道，需要先清空表gap_connect_ip_index，再清空表gap_channel（注意，会清空通道配置）执行：
truncate table gap_connect_ip_index；
truncate table gap_channel；
最后重启前后置exchanger.service。
如果从网口进入，只能通过MAN口使用SSH工具登录，端口号默认22。如果从consle口进，频率是默认的115200。
检查前置日志/var/log/upgrade.log，是否有类似update file: x.x.x-x.x.x.rar。正确升级文件应该是.bin后缀，需要解压后再导入升级包。
检查前置日志/var/log/upgrade.log，是否有ssh 241.255.255.242 connect failed.此现象为内部通信不通，确认好内部通信再升级。
“平台配置”>“服务管理”中重启文件同步服务。
尝试没有外键表的优先添加；
表的同步方向和触发器类型尽量相同。
更改电脑分辨率。
先手动选择目录。
重启设备。
按照国标GB/T28181和DB33的标准。平台在处理SIP信令时，需要将点播或录像的码流返回IP替换成平台自身地址。保证码流返回时，流媒体服务器发到平台上，并通过动态转发规则，将码流返回给客户端。而不是从流媒体服务器直接发往客户端IP。
如果抓包发现SIP信令过平台后没有将码流接受IP进行更换，那可能是因为视频厂商在协议中参杂了自定义字段。
目前主要有两种情况：
(1) 半连接情况。两边会话建立起来后，其中一边提前发送了FIN包关闭连接，但另一边还没发送完数据，要等数据全部发送完之后才发送反向FIN包（在没有隔离平台时,TCP允许的）。然而，平台两边只要其中一侧关闭连接，另一边也会立刻关闭。所以会导致后续数据无法通过平台。该问题，最好应用程序改会话控制，保证数据都发送完毕后，再互相发送FIN包关闭连接。需要在通道中配置FIN超时参数，默认30分钟（不是秒，界面显示BUG）。也就是通道在收到其中一侧的FIN包后不急于释放两边的连接，会等待30分钟后再释放，这个FIN等待时间可以按照实际情况调整，界面显示的单位有误，实际为分钟而不是秒。
(2) HTTP请求被重定向或拦截。这种情况抓包后和第一种情况很类似，都是可以先看到一个FIN包，后面跟了很多重传报文。
但是会有区别，如果页面是被重定向的，那HTTP反馈的信息不会是200 OK，而是302 FOUND。其次FIN包发送后，服务器的正常反馈信息才会发送到平台，如下图：
(3) 能够收到不同HTTP服务版本的响应。通常重定向的服务版本和正确的HTTP服务器版本不一样，如下面2图：
图2-1 重定向服务版本
图2-2 正确服务器版本
如果发现相同的目标IP、端口，能够收到2个不同HTTP服务版本的响应，那基本就能认定，发往服务器的包被重定向了。
链路上查找，有没有上网行为管理和准入认证功能的安全产品。比如第二代防火墙、准入系统、上网行为管理设备、安全网关等。让这些安全设备开放白名单，放行所有平台出去的包。
原因：由于内部隔离硬件采用了冗余链路，导致码流信息乱序属于正常情况。如果视频接收端不能处理乱序问题，平台内部交换只能采用单链路才解决这个问题。
隔离部件CLI命令行页面中执行以下命令，
ns ifconfig tun0或tun1 down //tun0和tun1任选一个，部件内外端关闭的接口要保持一致
vi /opt/jdwa/etc/nic.json // 同时修改接口配置文件，两端都要修改，并且保持一致
删除"tun0,"或“tun1”，注意语法合法性，tun0和tun1之间的逗号也要删除。
由于内部隔离线路采用了冗余设计，所以UDP在通过平台后可能产生乱序。由于TCP本身有sequence机制，可以通过内核重组序列，所以不会有这问题。但是UDP协议本身没有序号机制，如果软件工程师在应用层也未做排序重组，可能会碰到乱序问题，测试结果类似于丢包。目前经测试部测试900mbps带宽下UDP丢包率小于0.00001%。主要会在视频应用中碰到此类情况（不一定是SIP视频、其它视频协议都有可能）。
解决办法：类似于SIP视频乱序问题的解决方法，关闭一条内部线路。
命令：
ns ifconfig tun1 down //关闭tun1
vi /opt/jdwa/etc/nic.json // 同时修改接口配置文件，部件内外两端都要修改，并且保持一致
删除“tun1”，注意语法合法性，tun0和tun1之间的逗号也要删除。
用户使用数据库同步的情况下，要避免直接修改配置过同步的数据库表名（包括删除操作），如要修改，必须先删除同步软件上配置的同步任务及数据库，再修改表名，修改完后重新新建同步关联任务。
如果已经删除了同步的表或更改了表名，造成了同步配置无法删除，需要重启设备。如果设备有其它业务在跑，可以到前置执行systemctl restart synweb.service。执行后同步模块会重新按照新表名生成配置。
注意：测试和实施时必须提前告知用户（DBA），尽到告知义务。
解决办法就是重启数据库同步服务。界面重启要等待5-6分钟，配置重新下发。另一个办法是到CLI命令行页面直接重启服务，命令：systemctl restart dbsyncserver.service。先执行后置，再执行前置。
HA备机上线要注意这个问题。
支持
