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

      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算法的问题。

感谢楼主分享，楼主的排查思路比较清晰，建议后续遇到一些配置类的问题优先提供一下配置截图或者配置路径等（前提是不泄露客户业务数据等敏感信息），这样可以方便大家后续在遇到此类问题时可以直接参考学习，期待楼主有更加精彩的分享~

我在社区摸爬滚打这么多年，所谓阅人无数，就算没有见过猪走路，也总明白猪肉是啥味道的。一看到楼主的气势，我就觉得楼主同在社区里灌水的那帮小混子有着本质的差别，你一定就是传说中的最强技术牛。

楼主分享的案例很实用，具有典型性，希望有更多这样的干货供我们学习参考，非常感谢！

感谢楼主带来的经验分享                                   

感谢楼主带来的经验分享                                   

打卡学习，感谢分享！！！！

学习了，感谢分享！！！！！！！！！！

排查思路很清晰了，只是文字太多了看的密密麻麻的哈哈，下次建议可以贴一些图片

学习了业务故障的分析和排查方法楼主的排查思路比较清晰，建议后续遇到一些配置类的问题优先提供一下配置截图或者配置路径等

学习了，谢谢分享！有助工作。