Part 01

需求背景 

在OneNET平台某私有化項目中，項目方的需求是要獲取設備真實IP地址，然後根據設備的IP來統計處於各個省內區域的設備數量展示到大屏上。

Part 02

查找解決方案 

以MQTT設備接入為例，由於項目方使用的外層負載是Nginx軟負載，並且MQTT協議是基於TCP，只能走4層方式轉發報文，Nginx轉發報文的時候會將源TCP連接的IP地址改寫為自己的內網IP地址，不能像F5這種硬負載可以直接將設備的源地址轉發到後端服務上，因此就不能直接通過配置Nginx的方式來讓MQTT接入服務獲取到設備源IP地址，也就不能實現項目方的需求。

經過網上查詢相關解決方案，發現一個Internet協議叫做proxy protocl（參考資料：https://www.jianshu.com/p/cc8d592582c9），該協議可以通過為TCP包添加一個很小的頭信息，來傳遞客戶端信息（協議棧、源IP、目的IP、源端口、目的端口等），在網絡情況復雜又需要獲取用戶真實IP時非常有用。其本質是在三次握手結束後由代理在連接中插入了一個攜帶了原始連接四元組信息的數據包。

圖片

proxy protocol協議流程

查閱到proxy protocol報文的格式如下圖中所示，裡麵包含了客戶端的源地址和端口等信息，能夠滿足我們的需求。

proxy protocol報文格式

後端服務要獲取這個特殊報文也需要在Nginx上配置開啟proxy_protocol協議，如下圖中所示。

Nginx上配置開啟proxy_protocol協議

通過wireshark工具抓包我們也發現包結構和查閱到的資料是一致的，接下來我們要做的就是在MQTT協議解析的時候把這個特殊的包也要解析處理並保存這個客戶端的真實IP。

Wireshark抓proxy_protocol協議包

Part 03

實踐操作  

說乾就乾，我們修改MQTT接入服務的源代碼是基於Netty框架實現的，於是我們在編解碼的時候增加了真實IP解碼器，如下圖所示。

真實IP解碼器

隨後我們在解碼器的decode方法中，將原始報文解析出來，判斷是否有proxy protocol報文，然後解析報文並提取裡面的設備真實源IP地址和端口，並將之保持在Netty中的ChannelAttribute上下文中，方便後續獲取。

注意，這裡的proxy protocol報文和MQTT協議中的報文是粘包在一起的，所以我們需要提取源地址後將剩餘的MQTT協議包分離處理交給後續的MQTT協議解碼器進行處理，這就是整體處理流程。

真實IP解碼器源碼

Part 04

測試認證 

重新打包部署服務後，我們根據日誌看到通過Nginx負載方式能夠正常獲取到測試設備的源IP信息，滿足需求。

對於4層的UDP協議獲取設備源IP也可以參考本方案解決。