一、客户环境 版本信息: AF:8.0.32 AC: 13.0.7 AR 6140:V300R019C10SPC300(华为路由器) 二、现场环境
客户内网一台呼叫中心服务器,外网客户端注册成功后拨打电话,能振铃成功但是接通后无声音。 2.1网络拓扑图
三、处理思路首先当客户反映这个问题的时候,其实我内心是一脸懵逼,我们下一代防火墙及全网行为管理均已桥模式串入网络中,进行流量过滤而已,并不会对这种音频数据流进行恶意阻拦,当然客户反映这些问题,还是要积极响应的,毕竟包括路由器,交换机等等所有的产品都是我们供的,得负责到底 哈哈~。 接下来就是我的排查思路: 收集信息-故障复现-抓包分析-策略优化-故障排除 收集信息 首先收集一下相关信息,包括相关的软件及参数配置,当然是能收集的越多越好了,我先跟呼叫中心的软件工程师对接,沟通出现的问题,及故障复现所需要的相关软件,然后核对好当前路由器的NAT转换配置,及下一代防火墙、全网行为管理配置。 NAT根据呼叫软件的要求做了如下的配置 故障复现
电脑上安装呼叫中心软终端,并配置好相关的参数信息 注册成功后进行呼叫,拨打自己的手机,能响铃:“你是我天边最美的云彩…………”
我接起电话后,喂!喂?喂!,你说话呀,没有声音。 抓包分析
碰到问题后我们需要跟客户沟通,结合获取到的相关信息,分析中间可能会发生问题的故障点在哪个位置,本次内网的软终端连接服务器通话及拨号无任何问题,于是根据呼叫中心软件的工程师反馈及抓包的结果,画了个转发原理图,仅供参考学习。 以上是呼叫过程中数据包及端口的变化过程,通过抓的数据包绘制的转发图,如果有不对的地方还望大家指正,挂机的数据包转发过程没有附入,转发原理基本类似。 大家判断一下,问题可能出在哪个地方呢?同学们一块思考一下吧。 我分析了一下后根据现场情况及能抓包的地方,我选择了在公网软终端也就是我的电脑抓包,AF防火墙Untrust区域也就是从路由器到防火墙的进线位置进行抓包判断,判断中间的数据包出现了什么问题。
电脑端发起往呼叫中心服务器的报文 呼叫中心服务与公网软客户端数据包
大家可以看到呼叫中心服务器没有收到公网软客户端的RTP音频流 呼叫中心服务器与云线路服务商通信报文 通过抓包分析,呼叫中心服务器并没有收到公网软客户端发送的RTP音频数据流,正常交互SIP报文,导致可以工程师的帮助。 策略优化 本阶段通过检查路由器的配置已映射了相关端口,并且也开启了路由器的NAT 应用层网关ALG关于SIP协议的识别,但是还是不行,最后发现标准的SIP协议是UDP的5060,呼叫中心软件工程师修改成了UDP 7089,于是协调呼叫中心软件工程师修改为默认的UDP 5060,但是还是不行,最后华为工程师给的建议可以关闭路由器的ALG 关于SIP的识别功能,只用手动映射的UDP范围测试。 经过一段时间运行发现防火墙有关于呼叫中心服务器被其它省或国家端口扫描及攻击的日志,果断增加了地域访问限制,操作步骤里有说明,通过该方式可以拒绝80%的互联网有效攻击。 故障排除
通过反复测试发现通过关闭路由器的SIP协议识别功能,竟然奇迹般的可以了。看来华为路由器对于SIP协议的识别还是有点问题。 四、操作步骤抓包过程 电脑抓包用wireshak抓包工具,比较简单本实战里就不附入了,直接在电脑打开wireshark开始疯狂输出就可以了。
贴图贴上AF里很实用很傻瓜式的抓包操作 抓包选项配置好要抓的去往服务器IP的数据包及防火墙的进线接口,然后点击开始抓包,抓下来的数据包可以通过wireshak直接打开读取。 五、分析总结
分析故障的时候要尽可能搜集到更多的有用的参考信息,方便分析中间的转发过程,并能快速的缩短故障处理的时间,并结合更多的工具来判断故障点,以实际的数据为依据来判断问题,有更多的说服力,而不是凭借主观的判断解决问题。 |