除了X-FORWARD-FOR,負載均衡中獲得真實源IP的方法還有很多種,本文拋磚引玉,主要介紹獲得真實源IP的多種方法,而不是具體配置,負載均衡獲得真實IP的方法有很多種,將形成專題文章,本文為第一篇,主要做介紹和優劣對比。
NGINX不僅可以實現http的反向代理,同時也支持TCP的反向代理,使用Nginx 新版的 stream方式,實現TCP/UDP代理轉發。在項目中由於網絡結構複雜,我就使用了NGINX的TCP代理在前,後面是NGINX的HTTP代理在後。後面的需要獲取客戶的真實ip,通過tcp代理後是取不到的。就使用了下面的方法4,實現了NGIXN 4層tcp代理獲取客戶真實IP。
當數據包從負載均衡器往後端轉發時候,真實源IP可在L3層、L4層、L7層實現,並且每層分別有2種方法可以獲得真實IP,因此共有6種方法:
保持L3層源IP不變,根據連接次數可以分為
在L4層數據裡,添加源IP信息,有2種模式
在L7層數據裡,增加源IP信息,有2種模式
一次連接:負載均衡器對數據包僅做轉發,而不對後端重新發起三次握手
二次連接:和一次連接相對應,在tcp轉發時候,對後端重新進行了三次握手。上面所講的L4和L7方法的負載均衡,都是二次連接
可以通過對比源埠是否有改變來簡單判斷是一次連接還是二次連接,埠沒改變,可以理解為一次連接,有改變就是二次連接
介紹:是指在網絡層不對源IP做修改,直接將數據包轉發給後端,當後端接收到數據的時候,源IP就是真實IP。
實現:LVS-DR、LVS-NAT、LVS-TUNNEL模式。其中LVS-TUNNEL比較特別,是在原有數據包的開頭封裝了IP頭,當後端收到數據的時候,將封裝的IP頭進行解封裝,獲得的就是原有數據包。
優點:邏輯簡單,當負載均衡器故障切換的時候,從客戶端到後端的tcp連接不會中斷
缺點:對網絡架構有要求,比如DR模式,要求後端配VIP,並且回包要能直接回到客戶機;NAT模式,要求回包經過負載均衡器;TUNNEL模式要求後端支持IPIP隧道
介紹:是指負載均衡器和後端重新進行三次握手,但保持數據包的源IP為真實IP。
實現:haproxy(開啟tproxy透明代理模式)+ iptables(fwmark打標記)+ 策略路由這3者組合才能實現
優點:可以實現L7層(如HTTP/HTTPS)的負載均衡,而一次連接主要實現L4層的負載均衡
缺點:配置最複雜,同時要求回包經過負載均衡器
介紹:在4層的option欄位裡增加源IP信息,比如在tcp option裡增加源IP信息(稱為toa)、udp option裡增加源IP信息(稱為uoa)
實現:負載均衡器配置lvs-fullnat(只支持toa),iqiyi/dpvs(支持toa和uoa);後端要加載toa、uoa模塊,這個模塊的作用是替換了後端應用程式獲取IP的系統接口的鉤子
優點:對網絡架構要求低
缺點:lvs-fullnat需要編譯內核,且只支持rhel/centos 6的內核,另外多年未更新;iqiyi/dpvs功能強大,但需要dpdk的支持;後端都需要加載toa/uoa模塊,且只支持linux系統。
介紹:在L7層開頭增加proxy protocol數據(該協議是haproxy發明),目前有v1(明文)和v2(二進位)版本
實現:負載均衡器和後端同時開啟proxy protocol,haproxy和nginx均支持,不過haproxy的配置顆粒度更小,另外nginx轉發數據時候只支持v1
優點:對網絡架構要求低,只要程序支持即可,因此理論上沒有作業系統限制
缺點:目前支持proxy protocol的程序較少,且兩端只能都開啟或者都不開啟該協議,不能一端開一端不開
nginx的官方文檔
https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/#
介紹:最常見的方法,協議自帶源IP信息,或者可定製插入
實現:例如HTTP協議有X-FORWARD-FOR,也可以自己將源IP插入到HTTP頭部信息裡
優點:對網絡架構要求低,配置簡便
缺點:容易被偽造
介紹:最好的方法,就是業務方自行實現
實現:業務自行實現,例如在client端插入源IP信息,帶到server端
優點:對網絡架構無要求,只要網絡可通即可,只要安全做好,不容易被偽造
缺點:業務方要有一定開發能力
如果能做到無狀態,不需要真實源IP,是最好的。因為這樣對底層架構沒有要求,底層架構就可以做的更高級更彈性。
如果一定要獲得真實源IP,推薦方案的順序就是倒推,從L7到L3,即首選方法6,如果不行再選用方法5,以此類推到方法1。