Categories
程式開發

eBay流量管理之DSR在基礎架構中的運用及優化


一、背景

在現代企業內部, 負載均衡器 (LoadBalancer,以下簡稱 LB )被大量使用。負載均衡器的常用模式如下圖1所示:

eBay流量管理之DSR在基礎架構中的運用及優化 1

圖1 負載均衡的常用模式(代理模式)

負載均衡的常用模式可概述為下(詳情可見:分享 | eBay流量管理之負載均衡及應用交付):

  1. 客戶端向負載均衡器提供的虛擬IP地址VIP發送請求 (CIP → VIP)
  2. 負載均衡器從提前配置的多個子網IP地址中選擇一個(SNAT IP),替代客戶端請求的源IP,並依據負載均衡算法,選擇一個服務器IP作為目的IP,發送請求 (SNIP → SIP)
  3. 服務器處理後將響應結果發回負載均衡器 (SIP → SNIP)
  4. 負載均衡器將最終結果返回給客戶端 (VIP → CIP)

但負載均衡器的這種 經典SNAT模式 ,在基礎架構運維中有以下 缺點

  1. 由於信息量的因素,網絡請求的回包往往會比請求包大很多。一般達到 10倍 [1], 20 Mbps 的請求,其回包可能達到 200 Mbps 。這樣一來,由於回包也是經過LB,就會大量增加LB的帶寬使用,減小LB的有效處理容量。
  2. 基礎架構的服務(DNS,MAIL,LDAP等)工作在TCP/UDP傳輸層之上,所以無法像其它工作在HTTP協議以上的應用那樣,用HTTP header裡邊的X-Forwarded-For字段來保存客戶端真實IP。 這些基礎架構服務的請求包在被LB進行SNAT之後,客戶端的真正IP被替換為LB的SNAT IP。這樣造成的結果就是,後端服務器無法知道真實的客戶端IP是什麼,給問題排查、攻擊檢測、運行指標統計等運維活動帶來極大不便。

而DSR (Direct Server Return,服務器直接返回)技術 (其在Layer 2實現時叫Direct Routing,F5稱之為nPath), 顧名思義,就是讓後端服務器繞開LB直接回包給客戶端 (如下圖2[2]),從而實現節省LB帶寬和獲取客戶端真實IP的目標。

eBay流量管理之DSR在基礎架構中的運用及優化 2

圖2 DSR數據流圖

二、原理

那麼DSR又是通過怎樣的獨到之處,跟LB的看家本領SNAT叫板的呢? 原來,在DSR模式下,當網絡請求包到達LB時,LB並不做SNAT,而是把包的源IP地址原封不動​​地轉發給後端服務器。當後端服務器拿到請求包以後,由於包裡邊攜帶了客戶端的源IP地址,它就可以直接將回包通過網絡路由給這個源IP地址,到達客戶端手中。

不過,等等,這幸福來得也太突然了吧?讓我們來仔細分析一下,看看這中間的重重險阻在哪裡。

設想一下,服務端如果傻傻地用[src=SIP;dst=CIP]回包,那麼客戶端收到這個包以後,會怎麼樣? ——當然是丟掉。為什麼?因為客戶端也不傻,它知道自己請求的是VIP,所以期待的是VIP給它的回包。至於這個服務端SIP又是個什麼鬼?不需要,丟棄即可。因此,為了繞過客戶端這道安全防線,聰明的工程師們想到了一個絕好的辦法, 就是讓服務端偽裝自己的IP地址為VIP,用[src=VIP;dst=CIP]回包,以期能騙過客戶端,讓客戶端誤以為是LB的VIP回复給它的

那是不是我們直接在服務端網卡上配置VIP,讓服務端通過該網卡應答就可以?答案是No,因為這樣雖然確保了客戶端收到的應答包是[src=VIP,dst=CIP],但帶來的問題是:服務端和LB將同時應答ARP,引發IP地址衝突。所以,服務端偽裝VIP可以,但一定要低調,萬萬不可讓其他人知道—— 有一個絕好的辦法,就是將VIP偷偷地配置到loopback網卡或者tunl0這些本地的網絡接口上 ,既騙過了內核,讓它以為真的有這個合法IP地址,又不會被外邊的設備發現,一石二鳥,想想都激動。

還有一個問題,怎麼樣才能讓服務端內核以[src=VIP,dst=CIP]的組合回包呢?由於內核是嚴格按照(src→dst, dst→src)的方式進行回包的,那讓服務端內核如此回包的最好辦法,當然是讓LB轉發[src=CIP,dst=VIP]的包給服務端的內核啦。但是,這聽上去有點像天方夜譚,服務端的VIP是一個“偷偷摸摸”的配置,所以LB發出的[src=CIP,dst=VIP]的IP包,在路由時,一定是找到了LB上的VIP,絕無可能被路由到服務端去。怎麼辦?我可太“南”了…

針對上述問題,有一個辦法,就是LB跳過L3三層路由,直接把[src=CIP, dst=VIP]的IP包,塞到一個目標MAC地址為服務端網卡MAC地址的L2網絡包裡,送達服務端網卡 (相當於將從客戶端到LB的L2數據包更換一下目標MAC地址。對應於NAT,這種實現方法也被稱作MAT,即MAC Address Translation[3],參見圖3)。

eBay流量管理之DSR在基礎架構中的運用及優化 3

圖3 L2 DSR替換請求包的目標MAC地址

這個方法實現簡單,但有一個硬傷,就是當LB和後端服務器不在同一個L2網絡的時候就無能為力了。所以我們還是回到L3網絡來考慮這個問題,也就是如何讓LB把[src=CIP,dst=VIP]的IP包轉發給服務端的內核。 如果把網絡通信類比於傳統信件,那我們現在的需求就是,讓LB送一封“收件人”為VIP的信件,並且保證該信件是送到服務端而不是LB自己。通過這一類比,我們不難想出一個好辦法,就是讓LB給服務端送一封信([dst=SIP]),然後在這封信裡再嵌入一封“收件人”為VIP的信([dst=VIP]);同時在外層信封上標註——這裡邊裝的不是TCP,也不是UDP,而是另外一封信(協議)。這樣當服務端收到外邊的信封以後,它繼續拆開裡面的信,就可以獲取到[src=CIP,dst=VIP]的數據了。

事實上,這種做法就是 網絡隧道(Network Tunnel) 的概念——將一種網絡協議包(inner packet)作為payload嵌入外層網絡協議包中,並利用外層網絡協議進行尋址和傳輸,從而實現原本割裂的內層網絡像隧道一樣被打通了的效果。

最常見的網絡隧道就是我們使用的VPN :當撥入VPN之後,我們就可以訪問10.x.x.x這種內網地址了。很顯然是10.x.x.x這種IP包被封裝進了某種特殊的通道,也就是一些基於公網VPN協議的網絡隧道。 類似於VPN,在DSR這種場景下,我們就是要將訪問VIP的IP包通過至SIP形成的隧道進行傳輸。 Linux支持的IP in IP協議主要有 IPIPGRE 兩種,IPIP隧道不對內層IP數據進行加密[4],所以它最簡單,效率最高,如圖4所示。由於是內網可信網絡,因此選用IPIP這種最簡單高效的隧道協議。

eBay流量管理之DSR在基礎架構中的運用及優化 4

圖4 IPIP隧道協議

我們可以讓LB生成這樣的一個IPIP包[src=CIPdst=SIPprotocol=IPIPpayload=[src=CIPdst=SIPprotocol=IPIPpayload=[src=CIPdst=SIPprotocol=IPIPpayload=[src=CIPdst=SIPprotocol=IPIPpayload=[src=CIP, dst=VIP] ]並發出去。由於外層的IP包目標地址是服務端IP,所以外層IP包順利到達服務端內核;服務端內核拆包一看,這裡邊又是一個IPIP包,於是進一步解包,發現是[src=CIP,dst=VIP]的包。 這時內核檢查dst=VIP是本地一個合法的IP地址(因為本地網卡已經配置了VIP),於是欣然接受,並根據TCP/UDP的目標端口轉給應用程序處理。而應用程序處理完,就順理成章地交由內核,按照(src→dst, dst→src)的原則,產生[src=VIP, dst=CIP]的IP包進入網絡路由至客戶端,問題解決!此時的數據流圖參見下圖5:

eBay流量管理之DSR在基礎架構中的運用及優化 5

圖5 使用IPIP隧道的DSR數據流圖

三、探究

下面,我們以業界普遍使用的 F5負載均衡器 LTM + CentOS 7 為例,實戰分析探究一下DSR配置的關鍵技術。

Step 1

如下所示,在LB上配置一個有2個成員的負載均衡池(pool),並創建一個VIP對應到該pool:

  • 該pool指定的profile為IPIP,表示LB和該pool的成員通訊,走IPIP隧道;
  • 要關閉PVA-Acceleration,因為DSR模式下,client不再直接與VIP建立TCP連接,所以用不到L4的PVA硬件加速;
  • 該VIP指定translate-address disabled,表示不對請求該VIP的流量進行SNAT。

eBay流量管理之DSR在基礎架構中的運用及優化 6

Step 2

此時,我們在server端先不做任何配置,直接從client去telnet VIP,並且從server端分別用VIP和CIP抓包(如表1),看有什麼現象發生。

eBay流量管理之DSR在基礎架構中的運用及優化 7

表1 分別用VIP和CIP作為條件抓包

從wireshark中可以看到,LB在收到[CIP,VIP]的請求後,產生一個IPIP的包[src=CIPdst=SIPprotocol=IPIPpayload=[src=CIPdst=SIPprotocol=IPIPpayload=[src=CIPdst=SIPprotocol=IPIPpayload=[src=CIPdst=SIPprotocol=IPIPpayload=[src=CIP, dst=VIP] ]。這時候,由於我們還沒有從服務端正確地配置IPIP Tunnel和VIP, 所以這個包無法正確地被識別和處理, 導致了3次SYN包的重傳和1次RST(圖6中的包3,5,7和9),同時服務端以ICMP的形式告訴client,由於目標IP地址無法抵達的緣故,之前的包無法被正常傳遞[5](圖中包2,4,6,8,10)。

eBay流量管理之DSR在基礎架構中的運用及優化 8

圖6 LB通過IPIP隧道發到服務端的數據包

Step 3

進一步分析,由於服務端的內核還沒有加載IPIP模塊,所以它不能識別Protocol=IPIP的數據包,無法解析出嵌入在IPIP包裡的內層IP數據包。由於VIP只出現在內層IP包裡,因此以VIP作為filter抓包,自然是抓不到了。 現在我們嘗試讓內核加載IPIP模塊並再次抓包,看它能否識別並解開內層IP包

eBay流量管理之DSR在基礎架構中的運用及優化 9

我們重新做一次表1的telnet和tcpdump,相比於上一次的抓包,這次我們以VIP作為filter就可以抓到內層IP包了。 這說明內核加載IPIP模塊後就可以識別Protocol=IPIP的數據包了。但到這裡,由於我們並沒有在服務端的任何網絡接口(interface)上配置VIP,所以服務端仍然未作出回包處理。

Step 4

下一步,就是將VIP配置到tunl0或者lo上,讓內核識別到這是一個合法的IP地址。在F5提供的參考配置文檔[6]中,就是將VIP配置到loopback網卡lo:1上,並在tunl0上配置SIP。但是仔細思考一下,F5官方提供的這個配置並不令人十分滿意——根據我們前邊的分析,我們只要在loopback或者tunl0這類本地網卡上配置VIP,讓內核認為只是一個合法的地址就行了,為什麼還要多此一舉地往tunl0上配置SIP?

既然有這個疑問了,我們索性逐步推進,看看, 如果不在tunl0上配置SIP到底會發生什麼?

Step 4.1

首先,我們在lo:1上配置VIP,並且不在tunl0上配置任何IP地址。

eBay流量管理之DSR在基礎架構中的運用及優化 10

再次重做telnet,並用CIP作為filter抓包(語句見表1),結果如圖7所示,只能抓到客戶端到服務端的請求包(奇數行為eth0收到的外層包,偶數行為tunl0收到的內層包, 總共是1次SYN+3次SYN重傳,和1次RST )。

eBay流量管理之DSR在基礎架構中的運用及優化 11

圖7 服務端未回包

可見服務端內核確實收到了[dst=VIP]的包,但既沒有送給應用程序,也沒有回包,那是內核將這些包丟棄了嗎?此時用dmesg命令檢查一下內核日誌,發現在對應時間段有 5條 下述日誌:

eBay流量管理之DSR在基礎架構中的運用及優化 12

這個報錯是什麼意思呢?原來,網絡攻擊者(例如DDOS)在攻擊時,都會偽裝自己的IP地址(IP Address Spoofing),以繞開IP源地址檢查或是防止DDOS回包回到自身。由於源地址無法路由可達(route back),這時服務端就會不斷保持連接並等待,直到連接超時,造成資源耗竭無法正常提供服務。

為了應對這種攻擊,Linux內核加上了一個叫做 反向路徑過濾(reverse path filtering [7])的機制,這個機制會檢查,收到包的源地址是否能從收包接口(interface)路由可達,如果不可達,就會將該包丟棄,並記錄 “martian source” 日誌。回到我們問題的場景,tunl0在收到內部IP包[src=CIP, dst=VIP]這個包之後,就會去嘗試驗證從tunl0這個接口能不能連通CIP=10.218.98.18,由於tunl0無法路由到CIP,所以出現了上述的報錯。

那有什麼辦法,既能夠保證一定程度的安全,又可以支持DSR這種場景呢? rp_filter這個參數有 3個 值[8],如圖8,其中Loose mode下,只要從任何接口可以路由到源IP地址(而不限於收包接口),就不做丟棄處理。所以, 我們可以將tunl0的rp_filter設置成2 ,這樣由於CIP可以經由eth0路由,驗證應該會成功。

eBay流量管理之DSR在基礎架構中的運用及優化 13

圖8 Linux內核關於rp_filter的定義

Step 4.2

如下所示, 設置tunl0的rp_filter= 2,也就是對從tunl0進入的IP網絡包,如果其源IP地址可經由機器上任意網卡(例如eth0)路由到,就認為它是一個合法的報文。

eBay流量管理之DSR在基礎架構中的運用及優化 14

然後重新做一次telnet和tcpdump,奇怪的是,我們依舊沒有看到服務端內核回包,並且內核日誌仍舊報 “martian source” 的錯誤。這又是怎麼回事呢?看來,F5官方文檔讓在tunl0上配置SIP的要求似乎是不能省略的。

Step 4.3

接下來我們往tunl0上配置SIP,然後重做telnet和tcpdump。不出所料,此時服務端給出了正確的DSR回包(限於篇幅,此處略去抓包結果)。

到這裡,DSR誤打誤撞地完成了配置,但我心裡還有些難以平復—— Tunl0網卡的作用在於接收IPIP隧道內的內層IP包,但是服務端內核在回包時,是直接將[src=VIP, dst=CIP]的IP包經由eth0路由出去的,根本就沒有tunl0什麼事。 所以tunl0上理論上不需要配置任何IP,但為什麼在tunl0上配置SIP以後,就能解決”martian source”的問題呢?

懷著這個問題,我在網上找了很久的答案都沒找到,最終通過eBPF對linux內核源碼進行分析, 發現在linux的rp_filter代碼中,如果網絡接口(這裡是tunl0)不配置任何ip(ifa_list == NULL),那麼就會返回驗證失敗。

具體請參考github鏈接:

https://github.com/centurycoder/martian_source

eBay流量管理之DSR在基礎架構中的運用及優化 15

Step 5

既然linux內核要求tunl0上必須配置IP地址,那是不是意味著我們必須按照F5提供的官方步驟進行配置呢?不是的,我們前面已經分析,只要是在loopback或者tunl網卡上配置VIP騙過內核就行, 那我們就索性將VIP直接配置到tunl0網卡上,這樣既實現了tunl0上有IP地址的要求,又滿足了VIP是一個合法目標地址的要求。我們將第4步的配置回退後,在tunl0上配置VIP和rp_filter,如下所示:

eBay流量管理之DSR在基礎架構中的運用及優化 16

然後按照表1重新做一次telnet和tcpdump,如圖9所示,客戶端和服務端通過DSR成功完成TCP的3次握手( 1 是eth0端口上抓到的外層包, 2 是tunl0上抓到的內層包,它們其實是同一個 SYN包 ,所以被wireshark標記為TCP Out-of-Order; 3 是服務端回复的 SYN/ACK包 ,它不走Tunnel,所以沒有成對出現; 45 是客戶端發的 ACK包 ,分別是eth0抓到的外層包和tunl0抓到的內層包,被wireshark誤認為是重複的ACK)。

eBay流量管理之DSR在基礎架構中的運用及優化 17

圖9 成功的DSR通訊

四、總結

到這裡,我們就完成了DSR的原理分享和探究,並且通過對原理以及Linux內核源碼的分析,對F5官方提供的步驟進行了解析和優化。總的來說,從運用方面來看, 相比於SNAT模式,DSR在提高LB帶寬容量、保持客戶端真實IP等方面有很大優勢。但在選擇DSR或者SNAT模式時還要考慮實際運用場景。 DSR往往更適用於LB僅用作負載均衡功能的場景 ,而如果LB還承擔SSL offload、Cache、加速或者其它安全相關功能時,則只能選取經典SNAT模式[9]。希望本文能對各位讀者理解和運用DSR技術有所幫助和啟發。

參考資料

[1]https://kemptechnologies.com/au/white-papers/what-is-direct-server-return/

[2]https://www.loadbalancer.org/blog/15-years-later-we-still-love-dsr/

[3]https://www.haproxy.com/support/technical-notes/an-0053-en-server-configuration-with-an-aloha-in-direct-server-return-mode-dsr/

[4]https://developers.redhat.com/blog/2019/05/17/an-introduction-to-linux-virtual-interfaces-tunnels/

[5]https://tools.ietf.org/html/rfc792

[6]https://techdocs.f5.com/en-us/bigip-15-0-0/big-ip-local-traffic-manager-implementations/configuring-layer-3-npath-routing.html

[7]https://www.slashroot.in/linux-kernel-rpfilter-settings-reverse-path-filtering

[8]https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

[9]https://devcentral.f5.com/s/articles/the-disadvantages-of-dsr-direct-server-return

本文轉載自公眾號eBay技術薈(ID:eBayTechRecruiting)。

原文鏈接

https://mp.weixin.qq.com/s/vHQpnGnrc15D2HjcO8XIJA