search

session-replay-tools / tcpcopy

An online request replication and TCP stream replay tool, ideal for real testing, performance testing, stability testing, stress testing, load testing, smoke testing, and more.
http://session-replay-tools.github.io/tcpcopy/
Other
4.38k stars 1.02k forks source link

【问题】 防火墙设置问题 #121

Closed xiujie-jiang closed 11 years ago

xiujie-jiang commented 11 years ago

为什么我的防火墙 这样iptables -I OUTPUT -p tcp --sport 80 -j QUEUE后 从外面telnet 80端口 不通？ lsmod |grep ip_queue ip_queue 44649 0 uname -r 2.6.18-308.el5

flowly commented 11 years ago

应该是intercept截获了80端口的数据包 如果需要ping通 需要设置不截获对应ip

2013/6/4 xiujie-jiang notifications@github.com

lsmod |grep ip_queue ip_queue 44649 0

uname -r 2.6.18-308.el5

— Reply to this email directly or view it on GitHubhttps://github.com/wangbin579/tcpcopy/issues/121#issuecomment-18911132 .

wangbin579 commented 11 years ago

对，intercept默认会drop掉iptables设置的端口的，所以访问测试服务器的80端口是无法访问的。 解决方案如下： 要么设置iptables（参考 http://globaldev.co.uk/2013/01/migrating-memcached/ ）， 要么在intercept设置可访问ip地址列表（通过-x参数)。

大部分情况下，是不需要访问测试服务器的应用的。

xiujie-jiang commented 11 years ago

感谢回复，我的测试端（跨机房）： tcp 0 0 121...223:36524 58...237:35763 ESTABLISHED 12693/intercept

QUEUE tcp -- anywhere anywhere tcp spt:http

lsmod |grep ip_queue ip_queue 44649 1

线上报： 2013/06/04 21:20:13 +468 [notice] session size:4317 2013/06/04 21:20:13 +468 [notice] activate_dead_sessions 2013/06/04 21:20:18 +469 [notice] active:4256,rel reqs:184542,obs del:184542 2013/06/04 21:20:18 +469 [notice] conns:0,resp packs:0,c-resp packs:0 2013/06/04 21:20:18 +469 [notice] send Packets:373340,send content packets:0 2013/06/04 21:20:18 +469 [notice] reconnect for closed :0,for no syn:219 2013/06/04 21:20:18 +469 [notice] retransmit:0 2013/06/04 21:20:18 +469 [notice] successful retransmit:0 2013/06/04 21:20:18 +469 [notice] syn cnt:208287,all clt packs:1255614,clt cont:333158 2013/06/04 21:20:18 +469 [notice] total client content retransmit:0 2013/06/04 21:20:18 +469 [notice] total captured pakcets:7691315 2013/06/04 21:20:18 +469 [warn] no responses after 2876 secends 2013/06/04 21:20:18 +469 [warn] many connections can't be established

tcpdump信息： listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 21:24:31.546590 IP 线上IP.49436 > 测试IP.36524: P 4230767103:4230767111(8) ack 1742600235 win 46 <nop,nop,timestamp 3840299248 1438280634> 21:24:31.547008 IP 221.179.85.215.37709 > 测试IP.http: S 2613233507:2613233507(0) win 19320 <mss 1380,sackOK,timestamp 15332655 0,nop,wscale 1> 21:24:31.550615 IP 线上IP.49423 > 测试IP.36524: P 4233736964:4233736972(8) ack 2162598238 win 46 <nop,nop,timestamp 3840299252 1438280654> 21:24:31.550623 IP 111.194.53.82.netrek > 测试IP.http: S 2120478628:2120478628(0) win 14600 <mss 1452,sackOK,timestamp 12732614 0,nop,wscale 5> 21:24:31.557483 IP 线上IP.49428 > 测试IP.36524: P 4224779269:4224779277(8) ack 4174122425 win 46 <nop,nop,timestamp 3840299259 1438280618> 21:24:31.557625 IP 117.136.20.146.cesdcdman > 测试IP.http: S 2065383641:2065383641(0) win 19320 <mss 1360,sackOK,timestamp 3317408 0,nop,wscale 1> 21:24:31.564287 IP 线上IP.49436 > 测试IP.36524: P 8:16(8) ack 1 win 46 <nop,nop,timestamp 3840299266 1438280634> 21:24:31.564526 IP 180.156.219.208.isoipsigport-2 > 测试IP.http: S 1747618705:1747618705(0) win 65535 <mss 1440,nop,wscale 4,nop,nop,timestamp 898379852 0,sackOK,eol> 21:24:31.568786 IP 测试IP.36524 > 线上IP.49428: . ack 0 win 46 <nop,nop,timestamp 1438280680 3840299227> 21:24:31.580160 IP 测试IP.36524 > 线上IP.49423: . ack 8 win 46 <nop,nop,timestamp 1438280706 3840299252> 21:24:31.589178 IP 测试IP.36524 > 线上IP.49436: . ack 8 win 46 <nop,nop,timestamp 1438280702 3840299248> 21:24:31.597894 IP 线上IP.49423 > 测试IP.36524: P 8:16(8) ack 1 win 46 <nop,nop,timestamp 3840299299 1438280706> 21:24:31.597904 IP 60.7.98.132.29828 > 测试IP.http: S 3512473198:3512473198(0) win 14600 <mss 1440,sackOK,timestamp 11942371 0,nop,wscale 6>

wangbin579 commented 11 years ago

请参考文档： https://github.com/wangbin579/tcpcopy/tree/master/docs 上面的中文文档

QA讲述了如何判断问题出在哪个环节和解决方案

wangbin579 commented 11 years ago

参考QA:

5）机器之间无法复制请求

19）请求数据包都过来了，但服务器还是没有访问记录

wangbin579 commented 11 years ago

其实就是在测试服务器看看请求数据包（不是36524端口的包）过来了没有？上面给的tcpdump，是在线服务器抓的，还是测试服务器抓的？如果是测试服务器抓的，那说明syn包过来了，再通过netstat工具查看是否有相应的syn_recv状态存在，如果测试服务器应用（比如80端口）的tcp状态都不存在，那么就是在ip层被干掉了。

上述内容在文档中均有讲述。

xiujie-jiang commented 11 years ago

测试机上没有接收到除36524端口的包以外的数据包。

wangbin579 commented 11 years ago

如果上述信息准确的话，那就是中途被安全设备给干掉了。 策略： 复制给同一网段的服务器，然后再通过上层服务（比如web服务器代理）转发出去，这是目前比较好的方案

xiujie-jiang commented 11 years ago

感谢

xiujie-jiang commented 11 years ago

12 在同一内网出现一样的 情况：

12 测试机(10.68.229.198)：

IPTABLE Chain OUTPUT (policy ACCEPT) target prot opt source destination
QUEUE tcp -- anywhere anywhere tcp spt:webcache QUEUE tcp -- anywhere anywhere tcp spt:http

cat /proc/sys/net/ipv4/conf/all/rp_filter 0

NETSTAT -N tcp 0 0 10.68.229.198:36524 10.68.229.237:37317 ESTABLISHED tcp 0 0 10.68.229.198:36524 10.68.229.237:37316 ESTABLISHED tcp 0 0 10.68.229.198:36524 10.68.229.237:37319 ESTABLISHED tcp 0 0 10.68.229.198:36524 10.68.229.237:37318 ESTABLISHED tcp 0 0 10.68.229.198:36524 10.68.229.237:37315 ESTABLISHED tcp 0 0 10.68.229.198:36524 10.68.229.237:37314 ESTABLISHED

TCPDUMP 02:35:00.717479 IP 10.68.229.198.36524 > 10.68.229.237.48091: . ack 264 win 46 <nop,nop,timestamp 7431198 2309241523> 02:35:00.750259 IP 10.68.229.237.48092 > 10.68.229.198.36524: P 256:264(8) ack 1 win 46 <nop,nop,timestamp 2309241547 7431194> 02:35:00.750333 IP 10.68.229.198.36524 > 10.68.229.237.48092: . ack 264 win 46 <nop,nop,timestamp 7431231 2309241547> 02:35:00.750621 IP 10.68.229.237.48090 > 10.68.229.198.36524: P 256:264(8) ack 1 win 46 <nop,nop,timestamp 2309241554 7431197> 02:35:00.750824 IP 10.68.229.198.36524 > 10.68.229.237.48090: . ack 264 win 46 <nop,nop,timestamp 7431232 2309241554> 02:35:00.754408 IP 10.68.229.237.48091 > 10.68.229.198.36524: P 264:272(8) ack 1 win 46 <nop,nop,timestamp 2309241561 7431198> 02:35:00.754460 IP 10.68.229.198.36524 > 10.68.229.237.48091: . ack 272 win 46 <nop,nop,timestamp 7431235 2309241561> 02:35:00.760373 IP 10.68.229.237.48092 > 10.68.229.198.36524: P 264:272(8) ack 1 win 46 <nop,nop,timestamp 2309241566 7431231> 02:35:00.760420 IP 10.68.229.198.36524 > 10.68.229.237.48092: . ack 272 win 46 <nop,nop,timestamp 7431241 2309241566> 02:35:00.760981 IP 10.68.229.237.48095 > 10.68.229.198.36524: P 96:104(8) ack 1 win 46 <nop,nop,timestamp 2309241567 7431140> 02:35:00.761028 IP 10.68.229.198.36524 > 10.68.229.237.48095: . ack 104 win 46 <nop,nop,timestamp 7431242 2309241567> 02:35:00.796921 IP 10.68.229.237.48090 > 10.68.229.198.36524: P 264:272(8) ack 1 win 46 <nop,nop,timestamp 2309241603 7431232> 02:35:00.796960 IP 10.68.229.198.36524 > 10.68.229.237.48090: . ack 272 win 46 <nop,nop,timestamp 7431278 2309241603> 02:35:00.802920 IP 10.68.229.237.48093 > 10.68.229.198.36524: P 96:104(8) ack 1 win 46 <nop,nop,timestamp 2309241609 7431110> 02:35:00.802954 IP 10.68.229.198.36524 > 10.68.229.237.48093: . ack 104 win 46 <nop,nop,timestamp 7431284 2309241609>

intercept.log 2013/06/06 02:22:09 +841 [notice] intercept version:0.8.0 2013/06/06 02:22:09 +841 [notice] INTERCEPT_COMBINED mode 2013/06/06 02:22:09 +841 [notice] create delay-table,size:65536 2013/06/06 02:22:09 +841 [notice] msg listen socket:4 2013/06/06 02:22:09 +841 [notice] firewall socket:5 2013/06/06 02:22:12 +597 [warn] sig 2 received 2013/06/06 02:22:12 +597 [notice] release_resources begin 2013/06/06 02:22:12 +597 [notice] destroy router table 2013/06/06 02:22:12 +597 [notice] fd null counter:0 2013/06/06 02:22:12 +597 [notice] destroy delay table,total:0 2013/06/06 02:22:12 +597 [notice] destroy items:0,free:0,total:0 2013/06/06 02:22:12 +597 [notice] create msg list:0,free:0,destr:0 2013/06/06 02:22:12 +597 [notice] total visit hash_find_node:0,compared:0 2013/06/06 02:22:12 +597 [notice] destroy items 0 in table name:delay-table 2013/06/06 02:22:12 +597 [notice] release_resources end except log file 2013/06/06 02:22:22 +711 [notice] intercept version:0.8.0 2013/06/06 02:22:22 +711 [notice] INTERCEPT_COMBINED mode 2013/06/06 02:22:22 +711 [notice] create delay-table,size:65536 2013/06/06 02:22:22 +711 [notice] msg listen socket:4 2013/06/06 02:22:22 +711 [notice] firewall socket:5 2013/06/06 02:22:27 +711 [notice] total resp packs:0, all:0, route:0 2013/06/06 02:22:27 +711 [notice] delay total:0 2013/06/06 02:22:27 +711 [notice] delay delete obsolete :0 2013/06/06 02:22:32 +711 [notice] total resp packs:0, all:0, route:0 2013/06/06 02:22:32 +711 [notice] delay total:0 2013/06/06 02:22:32 +711 [notice] delay delete obsolete :0 2013/06/06 02:22:37 +711 [notice] total resp packs:0, all:0, route:0 2013/06/06 02:22:37 +711 [notice] delay total:0 2013/06/06 02:22:37 +711 [notice] delay delete obsolete :0 2013/06/06 02:22:42 +711 [notice] total resp packs:0, all:0, route:0 2013/06/06 02:22:42 +711 [notice] delay total:0 2013/06/06 02:22:42 +711 [notice] delay delete obsolete :0 2013/06/06 02:22:47 +711 [notice] total resp packs:0, all:0, route:0 2013/06/06 02:22:47 +711 [notice] delay total:0 2013/06/06 02:22:47 +711 [notice] delay delete obsolete :0 2013/06/06 02:22:52 +711 [notice] total resp packs:0, all:0, route:0 2013/06/06 02:22:52 +711 [notice] delay total:0 2013/06/06 02:22:52 +711 [notice] delay delete obsolete :0

12 线上服务器(10.68.229.237)：

tcpcopy.log 2013/06/05 05:39:23 +544 [notice] tcpcopy version:0.8.0 2013/06/05 05:39:23 +544 [notice] target:80-10.68.229.198:80,8080-10.68.229.198:8080 2013/06/05 05:39:23 +544 [notice] TCPCOPY_COMBINED mode 2013/06/05 05:39:23 +544 [notice] set global port for tcpcopy 2013/06/05 05:39:23 +544 [notice] set global port for tcpcopy 2013/06/05 05:39:23 +544 [notice] parallel connections per target:3 2013/06/05 05:39:23 +544 [notice] create address-table, size:32 2013/06/05 05:39:23 +544 [notice] add tunnels for exchanging info:977593798:36524 2013/06/05 05:39:23 +544 [notice] add tunnels for exchanging info:977593798:36524 2013/06/05 05:39:28 +548 [notice] active:659,rel reqs:0,obs del:0 2013/06/05 05:39:28 +548 [notice] conns:0,resp packs:0,c-resp packs:0 2013/06/05 05:39:28 +548 [notice] send Packets:659,send content packets:0 2013/06/05 05:39:28 +548 [notice] reconnect for closed :0,for no syn:43 2013/06/05 05:39:28 +548 [notice] retransmit:0 2013/06/05 05:39:28 +548 [notice] successful retransmit:0 2013/06/05 05:39:28 +548 [notice] syn cnt:647,all clt packs:4017,clt cont:1062 2013/06/05 05:39:28 +548 [notice] total client content retransmit:0 2013/06/05 05:39:28 +548 [notice] total captured pakcets:15841 2013/06/05 05:39:28 +548 [warn] no responses after 5 secends 2013/06/05 05:39:28 +548 [warn] many connections can't be established 2013/06/05 05:39:28 +548 [notice] session size:659 2013/06/05 05:39:28 +548 [notice] activate_dead_sessions

wangbin579 commented 11 years ago

从log来看，还是通信不通畅。tcpcopy发了syn数据包，而测试服务器没有任何响应。 你确信在测试服务器没有抓到tcpcopy发出的syn数据包（tcpdump -i any tcp and port 80 or 8080)？

同一网段非虚拟机器的情况下，在测试服务器端，还没有出现过tcpdump抓不到请求数据包的。

wangbin579 commented 11 years ago

在在线服务器端，也利用tcpdump抓： tcpdump -i any tcp and dst 10.68.229.198 and port 80 or 8080 看看数据包发到在线服务器的数据链路层了没有？

xiujie-jiang commented 11 years ago

昨晚用TCPDUMP抓了一宿数据打算做回放

抓出来的 信息 和下面的 基本一致： listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 21:24:31.546590 IP 线上IP.49436 > 测试IP.36524: P 4230767103:4230767111(8) ack 1742600235 win 46 21:24:31.547008 IP 221.179.85.215.37709 > 测试IP.http: S 2613233507:2613233507(0) win 19320 21:24:31.550615 IP 线上IP.49423 > 测试IP.36524: P 4233736964:4233736972(8) ack 2162598238 win 46 21:24:31.550623 IP 111.194.53.82.netrek > 测试IP.http: S 2120478628:2120478628(0) win 14600 21:24:31.557483 IP 线上IP.49428 > 测试IP.36524: P 4224779269:4224779277(8) ack 4174122425 win 46 21:24:31.557625 IP 117.136.20.146.cesdcdman > 测试IP.http: S 2065383641:2065383641(0) win 19320 21:24:31.564287 IP 线上IP.49436 > 测试IP.36524: P 8:16(8) ack 1 win 46 21:24:31.564526 IP 180.156.219.208.isoipsigport-2 > 测试IP.http: S 1747618705:1747618705(0) win 65535 21:24:31.568786 IP 测试IP.36524 > 线上IP.49428: . ack 0 win 46 21:24:31.580160 IP 测试IP.36524 > 线上IP.49423: . ack 8 win 46 21:24:31.589178 IP 测试IP.36524 > 线上IP.49436: . ack 8 win 46 21:24:31.597894 IP 线上IP.49423 > 测试IP.36524: P 8:16(8) ack 1 win 46 21:24:31.597904 IP 60.7.98.132.29828 > 测试IP.http: S 3512473198:3512473198(0) win 14600

wangbin579 commented 11 years ago

这是在线的tcpdump还是测试的tcpdump？

wangbin579 commented 11 years ago

如果tcpdump是测试服务器的，那还好办，应该还是被测试服务器的ip层干掉了；如果是在线服务器的，而测试服务器没有任何类似于 21:24:31.564526 IP 180.156.219.208.isoipsigport-2 > 测试IP.http: S 1747618705:1747618705(0) win 65535 的数据包，那么就非常奇怪了，因为同一网段一般不会经过中间设备（直接从在线服务器到测试服务器的，不会被drop掉的。

wangbin579 commented 11 years ago

假设在测试服务器的ip层被干掉了， 用curl在10.68.229.237（在线服务器）访问在线服务器，这些请求能否被复制过去？

wangbin579 commented 11 years ago

还有你确信测试服务器有没有外网网卡？曾经遇到过，在没有外网网卡的情况下，复制外网请求过去，测试服务器的ip层是不认这些数据包的。 可以尝试内网请求是否能够复制过去，就能确认这个问题了。

xiujie-jiang commented 11 years ago

服务器都跑在 虚拟机上 但都有内外网网卡

wangbin579 commented 11 years ago

虚拟机，就相当于跨网段

文档中其实也说了： 在同一网段的虚拟机，相当于跨网段的情况。

找厂商吧

我给个例子吧： “非常感谢， 和 Amazon EC2 的人沟通了 ， 在AWS VPC subnet 内部复制流量是可以的， 已经测试验证， 但是使用Elastic IP是不行的， 这个要经过 AWS IGW （公网网关），类似ip 欺骗（spoof）由于安全原因会被丢弃。可以使用的办法可以在本机tcpcopy不同端口，然后由nginx代理转发流量到测试环境。“

wangbin579 commented 11 years ago

具体例子如下：

非常感谢， 和 Amazon EC2 的人沟通了 ， 在AWS VPC subnet 内部复制流量是可以的， 已经测试验证， 但是使用Elastic IP是不行的， 这个要经过 AWS IGW （公网网关），类似ip 欺骗（spoof）由于安全原因会被丢弃。可以使用的办法可以在本机tcpcopy不同端口，然后由nginx代理转发流量到测试环境。

再次表示感谢。

在 2013年3月8日下午4:28，风声 fengsheng.10@gmail.com写道：

谢谢， 给amazon support 提交case了，等他们答复看看吧。

在 2013年3月8日下午3:54，wangbin579 wangbin579@gmail.com写道：

我也看错了，还以为是在测试服务器抓到syn包了，原来是在在线服务器抓到的。

那就说明这些数据包在到达测试服务器的数据链路层之前被干掉了。

可能虚拟机器做了一些限制

2013-03-08

发件人：风声 发送时间：2013-03-08 15:46 主题：Re: Re: 请教关于NAT环境下tcpcopy转发问题 收件人："wangbin579"wangbin579@gmail.com 抄送：

抱歉， 我说明那块可能写错了， ip_queue 这块我是设置在测试服务器的 。 测试服务器是抓不到任何相关的包，所以没法用netstat 看，我个人猜测可能是amazon在网络层面有限制。 再次表示感谢，谢谢您的回复。 我和amazon尝试沟通一下看看是不是有什么限制。

在 2013年3月8日下午3:13，wangbin579 wangbin579@gmail.com写道：

首先指出说明的错误之处吧。 ip queue和iptables设置在测试服务器，而不是在线服务器。

采用公网地址后：

只要客户端ip地址没有变化，就跟NAT没有多少关系。

你这个问题应该出在测试服务器的ip层，你用netstat查看有没有被复制会话的tcp syn_recv状态（在tcpdump能抓到复制包的情况下）

2013-03-08

发件人：风声 发送时间：2013-03-08 14:52 主题：Re: 请教关于NAT环境下tcpcopy转发问题 收件人："wangbin579"wangbin579@gmail.com 抄送：

其实就是一个公网地址对应一个私网地址 10.0.0.1是虚拟机启动就有的地址，另外可以附加（attach）一个公网地址，正场请求是先走到公网， 然后NAT到私网ip 比如 23.45.67.89 --> 10.0.0.1

我简化一下模型，全用私网

client 10.0.0.1 curl http://10.0.0.2:11511/

production 10.0.0.2

modprobe ip_queue iptables -I OUTPUT -p tcp --sport 11511 -j QUEUE

tcpcopy -x 11511-10.0.0.3:11511 -d nginx 跑在11511端口

test 10.0.0.3 intercept -d

nginx跑在11511端口

这种情况正常

假设 三个虚拟机各附加一个公网地址 client 1.1.1.1（10.0.0.1） curl http://1.1.1.2:11511/

production 1.1.1.2（10.0.0.2） iptables -I OUTPUT -p tcp --sport 11511 -j QUEUE

tcpcopy -x 11511-1.1.1.3:11511 -d 或 tcpcopy -x 11511-10.0.0.3:11511 -d

nginx 跑在11511

test 1.1.1.3（10.0.0.3） intercept -d

nginx 跑在11511

此时无法复制请求。

在 2013年3月8日下午2:14，wangbin579 wangbin579@gmail.com写道：

还有，采用公网地址，客户端的ip地址还是和私有地址的一样吗？

要确定问题出在哪个环节，各个环节都有可能出问题的，这些环节都不是tcpcopy本身能控制的。

tcpdump能查看是否到达测试服务器的数据链路层，netstat查看是否能够达到tcp层，通过这些工具，能够查看是否通过最关键的ip层，因为ip层会设置很多东西，比如rp_filter,iptables等等。

2013-03-08

发件人：风声 发送时间：2013-03-08 13:44 主题：请教关于NAT环境下tcpcopy转发问题 收件人："wangbin579"wangbin579@gmail.com 抄送：

Hi， 

首先非常感谢您的开源项目，我有个问题需要请教一下，我在本地（虚拟机）和线上（物理数据中心）测试问题不大，基本上可以部分复制请求。

我在amazon环境（虚拟机）测试，amazon 的环境每个虚拟机都是私有地址，但是会有一个elastic ip (公网ip)绑定，即NAT形式，正常的请求是可以处理的。

一共三台服务器，大概结构：

客户端产生请求 -- > 线上服务器 -- > 测试服务器

如果全部使用（同一个zone的vpc，即私有地址为同一个网段）私有地址，复制正常，但是如果客户端请求线上服务器的公网地址，则不能正常复制请求，tcpdump抓包 线上服务器只能看到一个SYN 发给测试服务器，测试服务器没有捕获到任何包。调整了一些内核参数 forward rp_filter accept_route_source,均无效果，我想问下是不是tcpcopy本身不支持NAT之后的流量复制？

 谢谢。
wangbin579 commented 11 years ago

复制给同一台机器的另外一个端口的web代理，然后通过应用代理转发请求到同一网段的其它服务器

wangbin579 commented 11 years ago

比如tcpcopy -x 80-本机器内网ip地址:端口号

这里需要注意的是本机器内网ip地址，不能是localhost地址，因为外网请求访问127.0.0.1，本机器的ip模块会丢弃掉的

xiujie-jiang commented 11 years ago

非常感谢，我现在通过离线回放进行的测试。

wangbin579 commented 11 years ago

离线回放，压力大的时候，很容易丢包的。除非是利用类似pfring的东西。 不过离线回放一般可以避开这些安全方面的问题。

xiujie-jiang commented 11 years ago

感谢，能对像我这样白的人的耐心指导！