摘要在非网关型负载均衡器中,通常使用FullNat模式。在这种模式下,客户端访问后端服务器的源IP在负载均衡器上会被改变,导致在后端服务器上服务不能正确确定客户端的真实IP地址。在一些应用场景下,为了实现安全或者大数据分析等应用,需要感知客户端的真实IP。本文介绍了一种FullNat模式下负载均衡的源地址可见方法。 概述负载均衡有三种模式:DR,NAT,Tunnel。FullNat模式在NAT模式下增加了源IP NAT。FullNat模式的优点:解决了NAT对Director和RS要求在同一个vlan的问题,适用更复杂的部署形式不要求配置Director作为网关,Director与RS可以通过三层通讯。缺点:RS看不到客户端真实IP。 为了解决后端服务器感知客户端真实IP,本文介绍了如下的方法。 四层源地址可见四层流量通常是TCP和UDP协议报文。源地址可见的通常方法是在报文中某些字段携带客户端的真实IP。在后端通过内核模块来获取客户端IP。 TCP源地址可见TCP流量是TOA来实现源地址可见。TOA名字全称是 tcp option address,是FullNat 模式下能够让后端服务器获取客户端IP的一种实现方式,它的基本原理比较简单。 u 客户端用户请求数据包到达负载均衡器时,负载均衡器在数据包的 tcp option 中插入源IP信息。 u 数据包到达后端服务器(装有 toa 内核模块)后,应用程序正常调用 getpeername 系统函数来获取连接的源端IP地址。 u 由于在 toa 代码中 hook(修改)了inet_getname 函数(getpeername 系统调用对应的内核处理函数),该函数会从 tcp option 中获取负载均衡器填充的源IP信息。 u 这样后端服务器应用程序就获取到了真实客户端IP,而且对应用程序来说是透明的。 TCP头部格式如下: 在option选项部分携带客户端的IP地址。 IPv4 TOA格式
opcode: opcode = 254 opsize: toa 大小 8 字节 port: 客户端端口 clientIP: 客户端 IP(4 字节) 注:opsize 大小包含了自身opsize(2B) + port(2B) + ip(4B) 修改option的时机负载均衡器需要对每个 tcp 数据包都要插入 toa 信息么?如果这样会影响到 负载均衡器 整体性能的,而且后端服务器也没必要对每个 tcp 数据包进行解析,当然也很影响服务器性能。其实只需要在第 3 次握手 ack 数据包中插入 toa 选项即可,后端服务器从 ack 数据包中解析并获取即可。 后端服务器上获取客户端IP获取。TCP协议栈中处理三次握手的 ack 数据包的函数是tcp_v4_syn_recv_sock,完成连接的建立,并创建 newsock。在TOA内核模块中修改 1.hook tcp_v4_syn_recv_sock_toa函数,从TCP的skb中获取tcp option的携带的IP信息,保存到socket中 2. Hook inet_getname,应用程序在调用getpeername时,会使用inet_getname_toa函数处理,从socket中将保存的ip信息返回 源码参考https://github.com/huaweicloud/huaweicloud-tool-aad-toa UDP源地址可见UDP使用UOA来实现源地址可见。UDP报文头部没有option字段,通常在IP头部的option中携带客户端IP。另外UDP是没有连接的,没有三层握手,通常是在前面几个报文中携带信息。 具体实现可以参考:https://github.com/bytedance/uoa 七层源地址可见七层的负载均衡通常通过反向代理来实现,如Nginx和Haproxy。七层流量通常是HTTP,通过在HTTP头中的X-FORWARD-FOR中携带客户端真实IP,后端服务器应用从HTTP头的该字段中获取得到。 X-Forwarded-For是一个 HTTP 扩展头部。HTTP/1.1(RFC 2616)协议并没有对它的定义,它最开始是由 Squid 这个缓存代理软件引入,用来表示 HTTP 客户端真实 IP。如今它已经成为事实上的标准,被各大 HTTP 代理、负载均衡等转发服务广泛使用,并被写入 RFC 7239(Forwarded HTTP Extension)标准之中。 X-Forwarded-For请求头格式非常简单,就这样: X-Forwarded-For: client, proxy1, proxy2 可以看到,XFF 的内容由「英文逗号 + 空格」隔开的多个部分组成,最开始的是离服务端最远的设备 IP,然后是每一级代理设备的 IP。 如果一个 HTTP 请求到达服务器之前,经过了三个代理 Proxy1、Proxy2、Proxy3,IP 分别为 IP1、IP2、IP3,用户真实 IP 为 IP0,那么按照 XFF 标准,服务端最终会收到以下信息: X-Forwarded-For: IP0, IP1, IP2 下面以NGINX为例,说明配置方法。 在Nginx配置文件中添加: proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; $proxy_add_x_forwarded_for会保存X-Forwarded-For中已有的值,并且追加$remote_addr的值,使用逗号隔开。 如果之前X-Forwarded-For中没有值,则修改后X-Forwarded-For中只有$remote_addr的值。 例子: A(client)—>B(Nginx1)—>C(Nginx2)—>D A为客户端,B和C为Nginx反向代理,D为服务端 A访问B时,X-Forwarded-For为空,$remote_addr为A的IP,故B转发到C时附带的Header头X-Forwarded-For即为A的IP; B访问C时,X-Forwarded-For为A的IP,$remote_addr为B的IP,此时C转发到D附带的Header头X-Forwarded-For即为A的IP,B的IP; C访问D时,D就可以拿C传来的X-Forwarded-For Header头来分析源IP。 |
|