Tcpcopy：[warn] many connections can't be established（阿里云）

由于，最近业务测试需要：需将流量copy到测试环境，这里使用tcpcopy工具。tcpcopy工具这里我就不复述介绍、原理了，官网上都有，安装方式也很详细。
https://github.com/session-replay-tools/tcpcopy，
git://github.com/session-replay-tools/intercept.git
git://github.com/session-replay-tools/tcpcopy.git

我本来在内网环境物理机上已经搭建了一套tcpcopy环境，过程还算顺利。只有在添加路由方面需要注意目标服务器和辅助服务器需在同一个内网。
好！言归正传。
还是业务需求，需在阿里云上也搭建一套同样的环境。
online server：192.168.10.1
assistant server：192.168.10.2
Target Server：192.168.10.3
步骤与之前相同，在同一个内网环境，环境很快就搭建好了。
服务启动！！！
问题来了：[warn] many connections can’t be established
tcpcopy日志：
[notice] active:31,rel:114,obs del:0,tw:16
[notice] conns:0,resp:0,c-resp:0
[notice] resp fin:0,resp rst:0
[notice] send:275,send content:0
[notice] send syn:145, fin:0,reset:130
[notice] reconnect:0,for no syn:119
[notice] retransmit:0
[notice] recv packs after retransmission:0
[notice] syn cnt:26,all clt:1143,clt cont:380
[notice] total cont retransmit:0, frag:0
[notice] total captured packets:104968
[warn] many connections can’t be established

辅助服务器日志：

目标服务器抓包：

在线上服务器、目标服务器上同时抓包，发现只有发送包，却没有返回包。

去网上到处百度找解决方案，在官网GitHub上找了几个方案：

一、阿里云环境下的tcpcopy环境部署参考 #336
云环境下，安全策略可能会干扰测试的进行。
采用如下步骤可以规避麻烦：
1、测试机器和intercept部署到一台机器
2、tcpcopy端-c参数采用tcpcopy所在的线上机器ip地址
3、在线上机器设置iptables黑洞来过滤掉测试服务器的响应包
iptables -I INPUT -p tcp --sport 测试服务的端口 -j DROP -s 测试服务所在机器的ip地址
4、千万要注意在测试服务器不要设置路由了，否则会受到干扰

问题依旧！pass！

二、在部分云平台环境下，需要用到传统架构，1.0版本如何编译？ #279
tcpcopy方式不变，intercept需要如下改变：
如何configure：
./configure --traditional，这种方式等同于1.0以下版本的默认方式
intercept 将采用iptables的方式来获取响应包，并干掉响应包

具体运行方式：
如果采用IP Queue模块（内核<3.5，默认采用IP Queue）:
1 # modprobe ip_queue # if not running
2 # iptables -I OUTPUT -p tcp --sport port -j QUEUE
3 # ./intercept
or
如果采用 NFQueue模块（内核>=3.5，默认采用NFQueue）:
1 # iptables -I OUTPUT -p tcp --sport port -j NFQUEUE
2 # ./intercept
这里需要注意，iptables命令中的port是变量，应根据具体应用项目而定。
然而，出现了其他问题，pass！

三、看到有人说在云环境中，需要在vpc中设置路由。也去试了，发现没什么用。

重点

最后，在官网issue中看到这篇解答：

新架构解决方案：
先在在线服务器端telnet到测试服务器的端口，看看网络路径是是否是通的，如果不通，先解决掉这个问题再继续下面的诊断。

假设tcpcopy测试过程中，测试服务器上面的上层应用没有收到任何请求

判断第一次握手数据包,即syn数据包,能否到达测试服务器

1、如果syn数据包能够到达测试服务器,分为如下几种情况:

1.1) 抓包仅仅只有syn数据包
在测试服务器利用tcpdump 抓包，能看到被复制的syn数据包都过来了，说明已经到达了测试服务器的数据链路层。
如果利用netstat 查看是否有应用的连接，如果没有，说明数据包在IP 层给drop 掉了，请查看是否有rpfilter 设置，如果有，去掉此设置，一般即可解决此问题。
如果没有设置rpfilter，那么确认一下iptables 设置有没有冲突，如果有，请先整理好iptables 相关规则。

1.2) syn数据包后面紧跟reset数据包(注意：同一个session中,syn和reset数据包相隔不到1s)说明路由设置有问题或者有冲突,导致了响应包直接返回给真实的客户端了.

1.3）测试服务器有响应包（第二次握手数据包）
去辅助服务器进行抓包，看看第二次握手数据包有没有到达辅助服务器：
a）如果没有到达，也说明路由设置没有生效，因此intercept捕获不到第二次握手数据包，回放就无法继续下去，通常可以采用的方案是让intercept直接运行在测试服务器上面（注意：路由设置不变，且tcpcopy的-c参数不能设置成tcpcopy连接intercept所用的ip地址，否则tcpcopy连接不上intercept）
b）如果捕获到了第二次握手数据包，查看是否有ip forward设置，如果设置了，需要关掉此设置，否则这些响应包会直接返回客户端，干扰测试的进行

2、如果不能到达测试服务器,又分为两个部分:

2.1) 在在线服务器利用tcpdump抓包,能抓到tcpcopy转发的数据包
如果能够抓到，说明路途过程中被干掉了，可以尝试利用tcpcopy的-c参数，修改客户端ip地址成合法的ip地址，最极端一点的就是修改成tcpcopy所在机器的ip地址（注意：存在nat的问题，而且如果intercept运行在测试服务器，需要注意tcpcopy的-c参数不能设置成tcpcopy连接intercept所用的ip地址，否则tcpcopy连接不上intercept）

2.2) 在在线服务器利用tcpdump抓包,不能抓到tcpcopy转发的数据包
2.2.1） 在tcpcopy的log内，看不到任何all clt:xx信息，说明tcpcopy无法从ip层抓包这种时候就采用–pcap-capture的方式来抓包，设置-F参数（例如’tcp and dst port 80 and dst host 10.100.1.2’)和-i参数（网络接口），避开默认的ip层抓包，改为从数据链路层抓包。

2.2.2） 在tcpcopy的log内，能够看到all clt:xx，xx >0，说明tcpcopy抓到数据包了。
这种情况说明tcpcopy发送数据包后，在在线机器的ip层被过滤掉了,检测iptables对output chain的限制等内容。如果是iptables的问题,而在线又不允许修改,采用–pcap-send从数据链路层的方式来发包（有一定难度，可以参考http://blog.csdn.net/wangbin579/article/details/10148247 ）.

将辅助服务器和目标服务器放到一起，然后在此机器上设置一条路由：route add -host 192.168.10.100 gw 192.168.10.3
注：192.168.10.100 为内网同网段没有使用的固定ip。
在线上服务器：
/usr/local/tcpcopy/sbin/tcpcopy -x 8011-192.168.10.1:8207 -s 192.168.10.3:36526 -c 192.168.10.100 -l ./tcpcopy.log -d

查看日志，数据正常了
抓包数据也正常了，测试端收到数据。
至此问题解决。