摘要
在非网关型负载均衡器中，通常使用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的一种实现方式，它的基本原理比较简单。
客户端用户请求数据包到达负载均衡器时，负载均衡器在数据包的 tcp option 中插入源IP信息。
数据包到达后端服务器（装有 toa 内核模块）后，应用程序正常调用 getpeername 系统函数来获取连接的源端IP地址。
由于在 toa 代码中 hook（修改）了 inet_getname 函数（getpeername 系统调用对应的内核处理函数），该函数会从 tcp option 中获取负载均衡器填充的源IP信息。
这样后端服务器应用程序就获取到了真实客户端IP，而且对应用程序来说是透明的。
TCP头部格式如下：
在option选项部分携带客户端的IP地址。
IPv4 TOA格式
opcode
opsize
port
clientIP
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。
