wangbin
wangbin
没有具体的抓包数据和详细log，很难准确得出结论 大致推理如下： 1、intercept报大量的fd is null after session is created，从上面log来看，可能是intercept过滤条件不详细导致的，毕竟还捕获了22端口，35996端口的数据包，带来了判断方面的干扰。 2、由于tcpcopy被终止，可能由于某种原因，target连接还存在，再发送syn数据包过去，target服务器可能会拒绝新建连接，毕竟已经有同样的连接存在了，于是可能回复一个非第二次握手数据包回去。 这个可以通过抓包来确认。 解决方案有如下： １、等后端连接都没有了（ss -s都没有相应tcp状态即可），再重新启动tcpcopy 2、intercept尝试--single，一个tcpcopy只对应intercept 如果上面都无法解决，请在tcpcopy和intercept端加上--with-debug，把相应debug log发到我邮箱，具体来查看原因。
https://github.com/wangbin579/auxiliary/tree/master/docs
新的问题最好提交一个新的issue，在已有问题后面提，不好发现。 还是得抓包分析和推理，从上面来看，貌似是tcpcopy没有捕获数据包
对于如下运行，tcpdump抓不到的问题： ./tcpcopy -x 8084-172.17.11.141:8084 -s 172.17.12.51 -c 172.17.11.142 -d 可以看看tcpcopy的log，特别关注： syn cnt:x,all clt:y,clt cont:z 如果x，y，z都不为0，那么说明tcpcopy抓到8084的数据包了 然后再看看 send:m,send content:n 如果m，n都不为0，那说明tcpcopy已经发送了数据包了，至于tcpdump抓不到，可能就是在被抓到之前已经被干掉了，毕竟tcpdump是在数据链路层抓包的，而tcpcopy发送数据包默认是在ip层发的
这个以后肯定会考虑的
https://github.com/session-replay-tools/mirror 也许适合你
1.0版本默认是不需要iptables的
根据你的特殊环境，如果被测试机器能够设置iptables，那么可以采用tcpcopy传统模式来做，参考地址: https://github.com/session-replay-tools/tcpcopy/issues/279 如果被测试机器也不能够设置iptables，那可以尝试如下方式： 被测试机器，采用双ip的方式，比如IP A和IP B，tcpcopy根据IP A来连接intercept（-s参数），而-c采用ip B，在被测试机器设置路由，把回ip B的响应包路由到非线上机器，也就是不让响应包回到线上机器
intercept运行在test机器，其它还是不变