因微信支付API对IPv6支持不完整引起的一次故障
时间:2018-12-10 18:53 来源:网络整理 作者:墨客科技 点击:次
因微信支付API对IPv6支持不完整引起的一次故障 2017-02-28 07:03 来源:DBAplus社群mp_hb1 微信 /操作系统 /支付 原标题：因微信支付API对IPv6支持不完整引起的一次故障 作者介绍 林伟壕，网络安全DevOps新司机，先后在中国电信和网易游戏从事数据网络、网络安全和游戏运维工作。对Linux运维、虚拟化和网络安全防护等研究颇多，目前专注于网络安全自动化检测、防御系统构建。 众所周知，随着“微信红包”等热门应用的红火，微信支付在我们的生活中已无处不在。今天我要分享的内容，正是关于微信支付面向商户的API 在IPv6支持上的一个问题。关注点不仅在于问题本身，更在排查故障过程中一些思路和方法论。 故障简述 最近有同事反馈去访问微信支付API https://api.mch.weixin.qq.com/pay/unifiedorder有一个奇怪的现象，比如第一次访问url需要等到10-30s不等的时间才有结果返回，之后连续多次访问却又是毫秒级的结果返回。等到一段时间不去访问，在相同环境下再次访问又会出现第一次访问很慢，之后连续多次访问很快返回的现象。因为是比较敏感的应用，所以这样的响应时间是不可接受，我们决定刨根问底彻查一下。 故障详情 发现故障，在处理的第一步经常是做故障重现，先使用shell脚本进行测试： for x in $(seq 6) do curl -o /dev/null -s -w %{time_namelookup}::%{time_connect}::%{time_starttransfer}::%{time_total}::%{speed_download}"n" -d "" "https://api.mch.weixin.qq.com/pay/unifiedorder" done 测试结果如下： 15.527::15.539::15.642::15.642::6.000 0.004::0.016::0.127::0.127::56.000 0.004::0.016::0.121::0.121::300.000 0.004::0.016::0.121::0.121::430.000 0.004::0.016::0.121::0.121::550.000 0.004::0.016::0.121::0.121::880.000 可以看到，第一次连接花费了15秒+的时间，之后都是毫秒级的返回。所以如何定位首次连接耗时过长的问题是当前重点。 处理过程 节点1 由于发生这个问题之前，我们有一个内部应用也有类似问题，比如第一次访问网页需要加载超过10s才能出来，之后访问就非常快了。当时通过抓包的方式定位到同一网络中有其他IP劫持了流量，增加了中间建立连接的时间，后来去除劫持源头后才恢复正常。于是，受过往经验影响，我首先猜想是可能是网络原因或者劫持。按照这个思路，先排查发起请求的客户端所在网络，发现是独立的外网IP，没有NAT等相对复杂的网络环境。同时，切换了一个网络环境进行测试，又发现每次请求响应都很快，测试结果如下： sh test_wxapi.sh 0.006::0.015::0.056::0.056::1952.000 0.006::0.020::0.139::0.139::783.000 0.006::0.024::0.177::0.177::617.000 0.006::0.019::0.129::0.129::845.000 0.006::0.023::0.159::0.159::686.000 0.006::0.019::0.139::0.139::781.000 因此网络问题仍无法彻底排查，于是决定在curl的同时抓包。 tcpdump -w test.pcap 抓包下来，用wireshark打开，看看是怎么连接建立过程是怎样的。
发现第一次请求有TCP重传，于是更加怀疑是网络问题，但从这里又无法直观看到是具体原因。所以开始往客户端所在服务器环境进行排查。 节点2 处理过程中同样是想起，之前遇到一个iptables规则配置不合理导致数据包梳理效率很低的问题，所以一开始在服务器环境排查时优先检查了iptables配置规则，发现也挺合理的，对于首次建立的连接没有set tag，也没有对New有特别设置，然后又临时清除了所有iptables规则发现问题依旧，于是跳过iptables。 iptables -nL Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ... DROP all -- 0.0.0.0/0 0.0.0.0/0 节点3 到了这里，我开始怀疑DNS解析异常也会引起首次建立连接耗时过长的问题。于是开始检查/etc/resolve.conf，不管是检查配置，还是更换DNS服务器问题都是一样的。但是，“有心栽花花不开，无心栽柳柳成荫”，这个过程中我还是抓了包，这么一来，发现IPv6地址解析异常了！
可以看到，DNS服务器返回的IPv6解析结果是”server failure AAAA”，而且耗时超过5s，这里就有问题了。 节点4 下面开始把焦点集中到微信支付域名api.mch.weixin.qq.com的IPv6解析上，发现有SERVFAIL，而且重现率很高。 time dig api.mch.weixin.qq.com AAAA ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59019 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;api.mch.weixin.qq.com. IN AAAA real 0m10.013s user 0m0.008s sys 0m0.004s 同时指定了IPv4的解析，发现A的查询很快： ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35327 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 12 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;api.mch.weixin.qq.com. IN A ;; ANSWER SECTION: api.mch.weixin.qq.com. 245 IN CNAME forward.qq.com. forward.qq.com. 22 IN A 140.207.69.101 forward.qq.com. 22 IN A 140.207.69.102 real 0m0.016s user 0m0.012s sys 0m0.004s 既然确定了IPv6解析有问题，IPv4解析正常，于是修改了相关代码，确认强制域名解析IPv4的话，都是正常的。 原因分析 从DNS原理看问题 1、整个DNS解析过程
|
