最近做的一个项目，用linux的tproxy做透明代理，通过iptables和策略路由，在不修改包的情况下将本来要转发的包路由到本地代理上，代理做一些协议分析后，再发送出去，发送的时候源端口是随机的，以FTP命令连接为例说一下：

 client------------tproxy---------------server

其IP地址如下：

client: 172.16.0.2
server: 192.168.89.110
tproxy: 172.16.0.1  192.168.89.107


client发出的包为：        172.16.0.2:6001 ----> 192.168.89.110:21
tproxy从client收到的包为：172.16.0.2:6001 ----> 192.168.89.110:21
tproxy发往server的包为：  172.16.0.2:6002 ----> 192.168.89.110:21

这样在代理服务器的内核里就把一个连接拆成了两个连接，是比较正常的，但这种方种用于FTP了连接的会存在问题，比如主动模式下会被防火墙拦截，就想到了一个比较怪异的方式：就是tproxy在连接服务端时使用与client相同的源端口，这样看起来就是：

client发出的包为：        172.16.0.2:6001 ----> 192.168.89.110:21
tproxy从client收到的包为：172.16.0.2:6001 ----> 192.168.89.110:21
tproxy发往server的包为：  172.16.0.2:6001 ----> 192.168.89.110:21

这样测试的时候也能正常工作，但却有很多想不通的地方，这时，对代理来说，明明有两个连接，但在内核中却只有一个连接（五元组完全一样），查看 /proc/net/nf_conntrack确实只有一个连接，问题是比如client和tproxy的连接已经建立起来，tproxy去连server时要握手，这个过程会不会把前一个连接状态打乱？两个连接传送的数据会不会混在一起？其中一个连接关闭会不会影响另一个？求高手解答。

tproxy透明代理没用过。

不过你为什么不把协议分析的工作放到kernel里呢？在网桥里把包拦下来，直接分析下，而且这时候要修改包的任何信息都是可以的，还省去了把包转来转去的过程。

不懂，学习来了

不太懂，纯粹学习了。