本发明涉及网络安全技术领域，具体的说，是一种实现tcp代理完全透明的方法。
背景技术
目前广泛应用于企业网络的安全设备，如行为管理设备、web防火墙等，都需要对tcp流量进行深度的解析处理。安全设备通常是作为“中间人”的角色部署在用户网路中，如果不对tcp连接进行代理，那么安全设备对tcp连接进行控制的粒度是很弱的。
举例来说，非代理型的waf很难做到修改某个http会话报文，而不影响tcp流中的其他报文。要想达到强控制粒度，无可避免的要使用tcp代理技术。tcp代理有很多种，包括正向代理、反向代理、透明代理等。正向代理需要配置客户端，通常不适用网络安全设备的使用场景；反向代理指的是客户端不感知代理设备，从网络角度看，代理设备要取代原来服务器的网络位置，反向代理可以是透明也可以是不透明，如果透明的话，对用户网络配置和业务影响最小。因此透明代理在网络安全设备种应用前景是非常广阔的。
实际上，tcp透明代理在安全设备种应用很广泛，原因是用户一般希望安全设备不改变原来部署好的网络环境，不影响原有业务，不引入复杂的管理。但是目前市场上的安全设备，绝大多数都没有实现真正的tcp透明代理，即同时满足mac地址透明、ip头部透明以及tcp端口透明，而是仅仅实现了ip地址透明。首先mac地址不透明无法使得中间设备在用户网络拓扑中像网桥一样工作，则需要修改用户网络。有的透明代理产品采用网桥抓包的方式完成代理工作，试图达到mac地址透明的目的，但是没有syn缓存，第一条连接还是无法做到mac地址透明。原因是代理设备在回复client的tcp连接请求时，server还没有将报文发向中间设备。ip头部的tos和ttl字段不透明，可能导致用户的诊断工具无法正常工作，或者qos策略出现偏差。tcp端口不透明，可能导致server的网络设备或者tcp服务器本身负载均衡策略出现偏差，也可能使某些用户策略出现判断错误。因此，很多场景下代理设备还是会对用户的网络业务造成影响。
市场上已经存在tcp代理软件:例如haproxy，传统的透明主要指的是ip地址的透明。其做法是中间设备收到client的tcp连接请求后，直接伪装为服务器进行应答，建立client与中间人的连接，然后根据client的请求构造报文发往server，与server建立连接。双向连接建立后对数据内容进行代理。这种代理方式无法实现mac地址透明、tos和ttl透明以及tcp端口透明。有的厂商通过在代理设备中引入bridge，试图达到tcp代理的mac地址透明。其做法大致过程是：
1.arp报文直接通过bridge进行转发，使得client和server可以学到对方的mac地址；
2.代理设备收到client发送来的报文时，记录其目的mac地址；
3.代理回复client时，用2中记录的mac地址替换报文中的源mac地址，伪装为server的mac地址；
4.代理设备收到server发送来的报文时，记录其目的mac地址；
5.代理回复server时，用4中记录的mac地址替换报文中的源mac地址，伪装为client的mac地址。
这种方式有一个问题：server的数据报文使用的源mac地址可能并不是client学习到的mac地址。一个典型场景是代理设备的server连接的路由器，路由器上开了arp代理。另一个场景是，代理设备的server连接到一个做了负载均衡的交换机，交换机将数据均衡到两个路由器。用server回复的报文的目的mac地址替换步骤3中的源mac地址仍然有问题，因为传统方案client与tcp代理设备建立第一条连接时，server端还没有发送回复报文。本专利的mac地址透明方案将解决这一问题。本发明公开一种实现完全透明tcp代理的方法，消除不完全透明代理对用户网络业务造成的不利影响。
技术实现要素：
本发明的目的在于提供一种实现tcp代理完全透明的方法，基于对tcpsyn报文缓存以及mac地址延迟学习，实现的tcp代理mac透明；通过拷贝client的数据，保持tcp代理报文头部中tos/ttl字段透明；通过网络名字空间技术即建立networknamespace，实现tcp代理的端口透明。
本发明通过下述技术方案实现：一种实现tcp代理完全透明的方法，具体包括以下步骤：
步骤f1：tcp代理服务器通过对client流向server的tcpsyn报文进行拦截和缓存，实现mac地址透明；
步骤f2：tcp代理服务器检查并拷贝client和server之间的互发的报文头部字段，实现ip头部tos和ttl字段透明；
步骤f3：tcp代理服务器为client建立networknamespace，实现tcp端口透明。
进一步地，为了更好的实现本发明，所述tcp代理服务器包括相互连接的tcp代理模块、syn_handler模块、bridge，所述tcp代理模块包括tcpproxy_client、tcpproxy_server、fd_binder；
所述步骤f1具体包括以下步骤：
步骤f101：client发出tcpsyn报文请求，试图与server建立连接，bridge学习并记录client的源mac地址；
步骤f102：client发出的tcpsyn报文到达tcp代理服务器，被syn_handler模块拦截并缓存；
步骤f103：syn_handler模块向tcp代理模块发送消息，通知tcp代理模块记录拦截的tcpsyn报文五元组信息并且发起与server的tcp连接；
步骤f104：tcp代理模块中的tcpproxy_client通过bridge向server发送tcpsyn报文，尝试与server建立连接；
步骤f105：tcp代理服务器中的bridge转发tcpproxy_client发出的tcpsyn报文到server，此时tcp代理服务器发出的报文的源mac地址被改成client的mac地址，tcpproxy_client伪装为client；
步骤f106：server回复并通过bridge与tcp代理模块握手建立连接，bridge通过server回复的报文进行二层信息学习，记录server的源mac地址；
步骤f107：bridge转发server回复的报文到tcpproxy_client，同时tcp代理模块发送确认给bridge，并且得到与server连接的文件描述符clientfd；
步骤f108：tcp代理模块的tcpproxy_client向fd_binder提交连接的文件描述符clientfd；
步骤f109：tcp代理模块通知syn_handler模块将步骤f102中client发来的原始tcpsyn报文放行；
步骤f110：syn_handler模块将client发来的原始tcpsyn报文提交到tcp代理模块中；
步骤f111：tcp代理模块回复ack确认报文给client，通过bridge与client交互握手，tcp代理服务器发出的所有交互报文源mac地址被修改为server的mac地址，此时建立tcp代理服务器与client的连接，得到与client连接的文件描述符serverfd；
步骤f112：tcp代理模块的tcpproxy_server向fd_binder提交连接文件描述符serverfd，fd_binder根据五元组信息对文件描述符serverfd和文件描述符clientfd进行关联绑定为fd关联组；
步骤f113：tcpproxy_server和tcpproxy_client通过fd_binder绑定的fd关联组进行数据转发。
进一步地，为了更好的实现本发明，所述步骤f2具体包括以下步骤：
步骤f201：tcp代理服务器检查client发往server的报文头部字段；
步骤f202：所述步骤f201中的报文头部字段的tos和ttl值被tcpproxy_client拷贝到tcp代理服务器发往server的请求报文中；
步骤f203：tcp代理服务器检查server发往client的报文头部字段；
步骤f204：所述步骤f203中的报文头部字段的tos和ttl值被tcpproxy_server拷贝到tcp代理服务器发往client的请求报文中。
进一步地，为了更好的实现本发明，所述client的数量有多个且分别与tcp代理服务器连接，所述networknamespace的数量有多个且与多个所述client一一对应，所述networknamespace分别与bridge连接；
所述步骤f3具体包括以下步骤：
步骤f301：任意一个client发起tcpsyn报文请求，被tcp代理服务器截获；
步骤f302：tcp代理服务器检查收到的tcpsyn报文是否属于某个已经存在的client，如果是，则找到与所述client相对应的networknamespace；如果不是，则为client创建对应的networknamespace；
步骤f303：步骤f301中所述client发出的tcpsyn报文被送往对应的networknamespace中进行处理；
步骤f304：tcp代理模块进程通过在步骤f303中所述networknamespace与server建立连接并通信，tcpproxy_client使用的ip地址和tcp源端口与步骤f301中所述client的完全一致。
工作原理：
1.tcp代理服务器通过对client流向server的数据流和控制流进行拦截和转发，实现mac地址透明。
2.tcp代理服务器检查并拷贝client和server之间的互发的报文头部字段，实现ip头部tos/ttl字段透明。
3.tcp代理服务器为client建立networknamespace，实现tcp端口透明。
本发明与现有技术相比，具有以下优点及有益效果：
（1）本发明实现mac地址透明；
（2）本发明实现ip头部tos/ttl字段透明；
（3）本发明实现tcp头部端口字段透明。
附图说明
图1为mac地址透明代理数据与控制流示意图；
图2为tos/ttl字段透明原理示意图；
图3为tcp端口透明代理示意图。
具体实施方式
下面结合实施例对本发明作进一步地详细说明，但本发明的实施方式不限于此。
实施例1：
本发明通过下述技术方案实现，如图1-图3所示，一种实现tcp代理完全透明的方法，具体包括以下步骤：
步骤f1：tcp代理服务器通过对client流向server的tcpsyn报文进行拦截和缓存，实现mac地址透明；
步骤f2：tcp代理服务器检查并拷贝client和server之间的互发的报文头部字段，实现ip头部tos/ttl字段透明；
步骤f3：tcp代理服务器为client建立networknamespace，实现tcp端口透明。
需要说明的是，通过上述改进，所述client是被代理的tcp客户端，server是被代理的服务器。本发明提供一种实现tcp代理完全透明的方法，原理是利用tcpsyn报文缓存延迟对客户端的应答，先获取到服务器的mac地址，解决握手阶段mac地址不透明的问题，从而实现mac地址透明。
对客户端和服务器之间传递的字段进行拷贝，实现ip头中的ttl和tos字段透明。
利用网络名字空间技术，即在tcp代理服务器中为client建立networknamespace，实现tcp头部中的端口号透明。
本实施例的其他部分与上述实施例相同，故不再赘述。
实施例2：
本实施例在上述实施例的基础上做进一步优化，如图1所示，所述tcp代理服务器包括相互连接的tcp代理模块、syn_handler模块、bridge，所述tcp代理模块包括tcpproxy_client、tcpproxy_server、fd_binder；
所述步骤f1具体包括以下步骤：
步骤f101：client发出tcpsyn报文请求，试图与server建立连接，bridge学习并记录client的源mac地址；
步骤f102：client发出的tcpsyn报文到达tcp代理服务器，被syn_handler模块拦截并缓存；
步骤f103：syn_handler模块向tcp代理模块发送消息，通知tcp代理模块记录拦截的tcpsyn报文五元组信息并且发起与server的tcp连接；
步骤f104：tcp代理模块中的tcpproxy_client通过bridge向server发送tcpsyn报文，尝试与server建立连接；
步骤f105：tcp代理服务器中的bridge转发tcpproxy_client发出的tcpsyn报文到server，此时tcp代理服务器发出的报文的源mac地址被改成client的mac地址，tcpproxy_client伪装为client；
步骤f106：server回复并通过bridge与tcp代理模块握手建立连接，bridge通过server回复的报文进行二层信息学习，记录server的源mac地址；
步骤f107：bridge转发server回复的报文到tcpproxy_client，同时tcp代理模块发送确认给bridge，并且得到与server连接的文件描述符clientfd；
步骤f108：tcp代理模块的tcpproxy_client向fd_binder提交连接的文件描述符clientfd；
步骤f109：tcp代理模块通知syn_handler模块将步骤f102中client发来的原始tcpsyn报文放行；
步骤f110：syn_handler模块将client发来的原始tcpsyn报文提交到tcp代理模块中；
步骤f111：tcp代理模块回复ack确认报文给client，通过bridge与client交互握手，tcp代理服务器发出的所有交互报文源mac地址被修改为server的mac地址，此时建立tcp代理服务器与client的连接，得到与client连接的文件描述符serverfd；
步骤f112：tcp代理模块的tcpproxy_server向fd_binder提交连接文件描述符serverfd，fd_binder根据五元组信息对文件描述符serverfd和文件描述符clientfd进行关联绑定为fd关联组；
步骤f113：tcpproxy_server和tcpproxy_client通过fd_binder绑定的fd关联组进行数据转发。
需要说明的是，通过上述改进，所述步骤f103、步骤f108、步骤f109、步骤f122是对控制流的说明，剩余的步骤是对数据流的说明。本实施例的原理是利用tcpsyn报文缓存延迟对客户端的应答，先获取到服务器的mac地址，解决握手阶段mac地址不透明的问题，从而实现mac地址透明。
所述tcp代理服务器包括相互连接的tcp代理模块、syn_handler模块、bridge，所述bridge是指支持传统网络二层转发的交换机。所述tcp代理模块包括相互连接的tcpproxy_client、tcpproxy_server、fd_binder。客户端client通过tcp代理服务器向服务器server发送tcpsyn报文请求，试图与server建立连接，首先经过bridge，bridge用于学习和记录client的源mac地址。client发送的tcpsyn报文经过bridge到达syn_handler模块，被syn_handler模块拦截并缓存。syn_handler模块向tcp代理模块的tcpproxy_server发送消息，通知tcpproxy_server记录拦截的tcpsyn报文的五元组信息，所述五元组信息包括源ip地址，源端口，目的ip地址，目的端口，和传输层协议。tcp代理模块通过bridge向server发送tcpsyn报文，尝试与server建立连接。tcp代理模块的tcpproxy_client发出的tcpsyn报文到达server，此时tcp代理服务器发出的所有交互报文的源mac地址被改为client的mac地址，tcpproxy_client伪装为client与server通信，所述tcp代理服务器发出的所有交互报文包括tcpsyn报文、ack确认报文。
server收到报文后进行回复，与tcp代理模块握手并建立连接，bridge通过server回复的报文进行二层信息学习并记录server的源mac地址。bridge转发server的回复报文到tcpproxy_client中，tcp代理模块发送确定收到回复报文的消息给bridge，并且得到与server连接的文件描述符clientfd，然后tcpproxy_client向fd_binder提交文件描述符clientfd，tcp代理模块通知syn_handler模块放行client发来的原始tcpsyn报文。syn_handler模块将client发来的原始tcpsyn报文上提到tcp代理模块中，tcp代理模块回复ack确认报文给client，并通过bridge与client交互握手报文。
同样的方式，tcp代理模块的tcpproxy_server回复的tcpsyn报文到达client，此时tcp代理服务器发出的tcpsyn报文的源mac地址被改为server的mac地址，由此伪装为server，得到文件描述符serverfd。tcp代理模块的tcpproxy_server向fd_binder提交serverfd，fd_binder通过五元组信息对serverfd和clientfd进行关联绑定为fd关联组。tcpproxy_server和tcpproxy_client通过fd_binder绑定的fd关联组进行数据转发。
client通过与tcp代理模块建立的代理连接进行数据通信，以为和自己通信的是server，而实际上是tcp代理模块中伪装的tcpproxy_server，server通过建立的连接进行通信，以为和自己进行通信的是client，而实际上是tcp代理模块中伪装的tcpproxy_client。
本实施例的其他部分与上述实施例相同，故不再赘述。
实施例3：
本实施例在上述实施例的基础上做进一步优化，如图2所示，所述步骤f2具体包括以下步骤：
步骤f201：tcp代理服务器检查client发往server的报文头部字段；
步骤f202：所述步骤f201中的报文头部字段的tos和ttl值被tcpproxy_client拷贝到tcp代理服务器发往server的请求报文中；
步骤f203：tcp代理服务器检查server发往client的报文头部字段；
步骤f204：所述步骤f203中的报文头部字段的tos和ttl值被tcpproxy_server拷贝到tcp代理服务器发往client的请求报文中。
需要说明的是，通过上述改进，实现tos和ttl字段透明的方法是client通过tcp代理服务器向server发送报文，tcp代理服务器检查报文的头部字段，tcpproxy_client将报文头部字段的tos和ttl值拷贝到tcp代理服务器发往server的请求报文中。
同样的方式，server通过tcp代理服务器向client发送报文，tcp代理服务器检查报文的头部字段，tcpproxy_server将报文头部字段的tos和ttl值拷贝到tcp代理服务器发往client的请求报文中。
本实施例的其他部分与上述实施例相同，故不再赘述。
实施例4：
本实施例在上述实施例的基础上做进一步优化，如图3所示，所述client的数量有多个且分别与tcp代理服务器连接，所述networknamespace的数量有多个且与多个所述client一一对应，所述networknamespace分别与bridge连接；
所述步骤f3具体包括以下步骤：
步骤f301：任意一个client发起tcpsyn报文请求，被tcp代理服务器截获；
步骤f302：tcp代理服务器检查收到的tcpsyn报文是否属于某个已经存在的client，如果是，则找到与所述client相对应的networknamespace；如果不是，则为client创建对应的networknamespace；
步骤f303：步骤f301中所述client发出的tcpsyn报文被送往对应的networknamespace中进行处理；
步骤f304：tcp代理模块进程通过在步骤f303中所述networknamespace与server建立连接并通信，tcpproxy_client使用的ip地址和tcp源端口与步骤f301中所述client的完全一致。
需要说明的是，通过上述改进，实际上client的数量通常比较多，每个client也可能与server建立多个连接，这样就导致了tcp代理服务器上端口不够用的问题。为了支持超过65536个并发端口，现有的tcp代理服务器通常的做法是配置多个虚拟ip，达到在tcp代理服务器建立新连接时五元组中的源ip地址不同的目的。为不同的client选择不同的虚拟ip地址往往是不可行的，因为通常网络中允许配置的虚拟ip数量有限，但client的数量却非常多。
本发明提出一种新的方式，为每个client建立一个networknamespace，而不是使用不同的虚拟ip地址。每个networknamespace中使用的虚拟ip地址可以相同，端口也可以相同，这样一来networknamespace的隔离性，解决并发连接数量限制问题的同时，也可以做到源端口的完全透明。
假设client的数量有n个，则networknamespace的数量也有n个，并与client一一对应，所述networknamespace简称ns，并且分别与bridge对接，本实施例中的bridge和实施例中所述bridge是同一个模块。当clientx向tcp代理模块发起连接请求时，被tcp代理服务器截获，tcp代理服务器检查收到的报文是否属于某个已经存在的client，如果不是，则为所述clientx创建一个与之对应的networknamespacex。此时clientx向tcp代理模块发送的报文被送往networknamespacex中进行处理，tcp代理模块进程在networknamespacex中与server建立连接并通信，tcpproxy_client使用ip地址和tcp源端口与clientx的完全一致，由此实现tcp端口透明。
本实施例的其他部分与上述实施例相同，故不再赘述。
以上所述，仅是本发明的较佳实施例，并非对本发明做任何形式上的限制，凡是依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化，均落入本发明的保护范围之内。