#原创分享#一次客户业务故障的分析和排查方法

      1月4号晚上，客户绿盟WAF下架，下架后，检查客户网络各层设备流量、内存、报错信息等都正常。

     第二天早上客户反馈一个client业务无法访问，我收到消息后第一时间打电话给业务部门运维人员，得知昨晚十点下架绿盟WAF后业务最前面的nginx反代即开始没有任何业务流量。

于是从公网最外层的AD负载开始重新梳理该业务的数据流量走向：

客户端访问域名，域名解析到115.x.x.x，最外层的某公司负载上接收到流量后经过某公司出口防火墙再转给瑞数系统（一个数据包防篡改的系统，反向代理模式部署），最后由瑞数系统转给真实业务服务器。

重新检查了经过的各设备健康状态，无异常信息，防火墙上查看业务无攻击、无拦截、无封禁。

将访问不了的IP在出口防火墙上加白后可以访问，随即进一步缩小测试范围发现出口防火墙针对该业务的的解密功能关闭即可访问。

联系研发得知系防火墙不支持低版本不安全的加密算法所致。

于是设置该业务在防火墙上不做解密，在不同网络环境下测试可以访问了。但业务部门反馈还是不行。

因此进一步分析：

一方面在防火墙和瑞数上分别查看是否有四层的TCP访问日志，发现瑞数上能看到七层的数据包明文，怀疑瑞数bypass也会对业务流量解密再加密，联系瑞数证实了确实只要https流量经过瑞数就会解密再加密。

另一方面，发现只要经过瑞数的https业务，都访问不了，http则可以访问。在防火墙和不能访问的客户端上同时抓包分析，发现SSL握手时报“ Encrypted Handshake MessageError”，

基本确认是客户端和瑞数SSL密钥协商有问题，瑞数和用户的老版本浏览器在密钥交换协商过程中，老版本浏览器使用的低版本算法，瑞数不支持低版本算法导致SSL密钥协商失败。

因此联系瑞数负责人，瑞数反馈在瑞数上针对该业务增加RC4-SHA的支持，增加后发现所有浏览器都可以打开了。此时客户还是反馈业务访问失败。

于是将访问失败的详细报错信息给瑞数分析，瑞数反馈瑞数设备SSL通信的密钥长度是2048位，要增加1024位的支持即可，因此按照瑞数指导，登录瑞数服务器后台修改业务配置文件，但银行端测试依然调用失败。

于是放弃瑞数配置调整的方案，采用第二种测试方案：出口负载节点池绕过瑞数，直接指向业务服务器。出口防火墙和业务服务器iptables均放通公网IP该业务服务器的访问。

负载上将节点池切到业务服务器后，业务部门各人员即刻反馈调用接口调通了。后续待我们的AF打上解密补丁，以及通知瑞数公司人员详细排查和解决他们设备针对SSL算法的问题。