摘要
在非網(wǎng)關(guān)型負(fù)載均衡器中，通常使用FullNat模式。在這種模式下，客戶端訪問(wèn)后端服務(wù)器的源IP在負(fù)載均衡器上會(huì)被改變，導(dǎo)致在后端服務(wù)器上服務(wù)不能正確確定客戶端的真實(shí)IP地址。在一些應(yīng)用場(chǎng)景下，為了實(shí)現(xiàn)安全或者大數(shù)據(jù)分析等應(yīng)用，需要感知客戶端的真實(shí)IP。本文介紹了一種FullNat模式下負(fù)載均衡的源地址可見方法。
概述
負(fù)載均衡有三種模式：DR，NAT，Tunnel。FullNat模式在NAT模式下增加了源IPNAT。FullNat模式的優(yōu)點(diǎn)：解決了NAT對(duì)Director和RS要求在同一個(gè)vlan的問(wèn)題，適用更復(fù)雜的部署形式不要求配置Director作為網(wǎng)關(guān)，Director與RS可以通過(guò)三層通訊。缺點(diǎn)：RS看不到客戶端真實(shí)IP。
為了解決后端服務(wù)器感知客戶端真實(shí)IP，本文介紹了如下的方法。
四層源地址可見
四層流量通常是TCP和UDP協(xié)議報(bào)文。源地址可見的通常方法是在報(bào)文中某些字段攜帶客戶端的真實(shí)IP。在后端通過(guò)內(nèi)核模塊來(lái)獲取客戶端IP。
TCP源地址可見
TCP流量是TOA來(lái)實(shí)現(xiàn)源地址可見。TOA名字全稱是 tcp option address，是FullNat 模式下能夠讓后端服務(wù)器獲取客戶端IP的一種實(shí)現(xiàn)方式，它的基本原理比較簡(jiǎn)單。
u 客戶端用戶請(qǐng)求數(shù)據(jù)包到達(dá)負(fù)載均衡器時(shí)，負(fù)載均衡器在數(shù)據(jù)包的 tcp option 中插入源IP信息。
u 數(shù)據(jù)包到達(dá)后端服務(wù)器（裝有 toa 內(nèi)核模塊）后，應(yīng)用程序正常調(diào)用 getpeername 系統(tǒng)函數(shù)來(lái)獲取連接的源端IP地址。
u 由于在 toa 代碼中 hook（修改）了inet_getname 函數(shù)（getpeername 系統(tǒng)調(diào)用對(duì)應(yīng)的內(nèi)核處理函數(shù)），該函數(shù)會(huì)從 tcp option 中獲取負(fù)載均衡器填充的源IP信息。
u 這樣后端服務(wù)器應(yīng)用程序就獲取到了真實(shí)客戶端IP，而且對(duì)應(yīng)用程序來(lái)說(shuō)是透明的。
TCP頭部格式如下：
在option選項(xiàng)部分?jǐn)y帶客戶端的IP地址。
IPv4 TOA格式
opcode
opsize
port
clientIP
opcode: opcode = 254
opsize: toa 大小 8 字節(jié)
port: 客戶端端口
clientIP: 客戶端 IP（4 字節(jié)）
注：opsize 大小包含了自身opsize(2B) + port(2B) + ip(4B)
修改option的時(shí)機(jī)
負(fù)載均衡器需要對(duì)每個(gè) tcp 數(shù)據(jù)包都要插入 toa 信息么？如果這樣會(huì)影響到 負(fù)載均衡器 整體性能的，而且后端服務(wù)器也沒必要對(duì)每個(gè) tcp 數(shù)據(jù)包進(jìn)行解析，當(dāng)然也很影響服務(wù)器性能。其實(shí)只需要在第 3 次握手 ack 數(shù)據(jù)包中插入 toa 選項(xiàng)即可，后端服務(wù)器從 ack 數(shù)據(jù)包中解析并獲取即可。
后端服務(wù)器上獲取客戶端IP獲取。
TCP協(xié)議棧中處理三次握手的 ack 數(shù)據(jù)包的函數(shù)是tcp_v4_syn_recv_sock，完成連接的建立，并創(chuàng)建 newsock。在TOA內(nèi)核模塊中修改
1.hook tcp_v4_syn_recv_sock_toa函數(shù)，從TCP的skb中獲取tcp option的攜帶的IP信息，保存到socket中
2. Hook inet_getname，應(yīng)用程序在調(diào)用getpeername時(shí)，會(huì)使用inet_getname_toa函數(shù)處理，從socket中將保存的ip信息返回
源碼參考https://github.com/huaweicloud/huaweicloud-tool-aad-toa
UDP源地址可見
UDP使用UOA來(lái)實(shí)現(xiàn)源地址可見。UDP報(bào)文頭部沒有option字段，通常在IP頭部的option中攜帶客戶端IP。另外UDP是沒有連接的，沒有三層握手，通常是在前面幾個(gè)報(bào)文中攜帶信息。
具體實(shí)現(xiàn)可以參考：https://github.com/bytedance/uoa
七層源地址可見
七層的負(fù)載均衡通常通過(guò)反向代理來(lái)實(shí)現(xiàn)，如Nginx和Haproxy。七層流量通常是HTTP，通過(guò)在HTTP頭中的X-FORWARD-FOR中攜帶客戶端真實(shí)IP，后端服務(wù)器應(yīng)用從HTTP頭的該字段中獲取得到。
X-Forwarded-For是一個(gè) HTTP 擴(kuò)展頭部。HTTP/1.1（RFC 2616）協(xié)議并沒有對(duì)它的定義，它最開始是由 Squid 這個(gè)緩存代理軟件引入，用來(lái)表示 HTTP 客戶端真實(shí) IP。如今它已經(jīng)成為事實(shí)上的標(biāo)準(zhǔn)，被各大 HTTP 代理、負(fù)載均衡等轉(zhuǎn)發(fā)服務(wù)廣泛使用，并被寫入 RFC 7239（Forwarded HTTP Extension）標(biāo)準(zhǔn)之中。
X-Forwarded-For請(qǐng)求頭格式非常簡(jiǎn)單，就這樣：
X-Forwarded-For: client, proxy1, proxy2
可以看到，XFF 的內(nèi)容由「英文逗號(hào) + 空格」隔開的多個(gè)部分組成，最開始的是離服務(wù)端最遠(yuǎn)的設(shè)備 IP，然后是每一級(jí)代理設(shè)備的 IP。
如果一個(gè) HTTP 請(qǐng)求到達(dá)服務(wù)器之前，經(jīng)過(guò)了三個(gè)代理 Proxy1、Proxy2、Proxy3，IP 分別為 IP1、IP2、IP3，用戶真實(shí) IP 為 IP0，那么按照 XFF 標(biāo)準(zhǔn)，服務(wù)端最終會(huì)收到以下信息：
X-Forwarded-For: IP0, IP1, IP2
下面以NGINX為例，說(shuō)明配置方法。
在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會(huì)保存X-Forwarded-For中已有的值，并且追加$remote_addr的值，使用逗號(hào)隔開。
如果之前X-Forwarded-For中沒有值，則修改后X-Forwarded-For中只有$remote_addr的值。
例子：
A(client)—>B(Nginx1)—>C(Nginx2)—>D
A為客戶端，B和C為Nginx反向代理，D為服務(wù)端
A訪問(wèn)B時(shí)，X-Forwarded-For為空，$remote_addr為A的IP，故B轉(zhuǎn)發(fā)到C時(shí)附帶的Header頭X-Forwarded-For即為A的IP；
B訪問(wèn)C時(shí)，X-Forwarded-For為A的IP，$remote_addr為B的IP，此時(shí)C轉(zhuǎn)發(fā)到D附帶的Header頭X-Forwarded-For即為A的IP，B的IP；
C訪問(wèn)D時(shí)，D就可以拿C傳來(lái)的X-Forwarded-ForHeader頭來(lái)分析源IP。
