Part 01
● 需求背景 ●
在OneNET平臺某私有化項(xiàng)目中，項(xiàng)目方的需求是要獲取設(shè)備真實(shí)IP地址，然后根據(jù)設(shè)備的IP來統(tǒng)計(jì)處于各個(gè)省內(nèi)區(qū)域的設(shè)備數(shù)量展示到大屏上。
Part 02
● 查找解決方案 ●
以MQTT設(shè)備接入為例，由于項(xiàng)目方使用的外層負(fù)載是Nginx軟負(fù)載，并且MQTT協(xié)議是基于TCP，只能走4層方式轉(zhuǎn)發(fā)報(bào)文，Nginx轉(zhuǎn)發(fā)報(bào)文的時(shí)候會將源TCP連接的IP地址改寫為自己的內(nèi)網(wǎng)IP地址，不能像F5這種硬負(fù)載可以直接將設(shè)備的源地址轉(zhuǎn)發(fā)到后端服務(wù)上，因此就不能直接通過配置Nginx的方式來讓MQTT接入服務(wù)獲取到設(shè)備源IP地址，也就不能實(shí)現(xiàn)項(xiàng)目方的需求。
經(jīng)過網(wǎng)上查詢相關(guān)解決方案，發(fā)現(xiàn)一個(gè)Internet協(xié)議叫做proxy protocl(參考資料：https://www.jianshu.com/p/cc8d592582c9)，該協(xié)議可以通過為TCP包添加一個(gè)很小的頭信息，來傳遞客戶端信息(協(xié)議棧、源IP、目的IP、源端口、目的端口等)，在網(wǎng)絡(luò)情況復(fù)雜又需要獲取用戶真實(shí)IP時(shí)非常有用。其本質(zhì)是在三次握手結(jié)束后由代理在連接中插入了一個(gè)攜帶了原始連接四元組信息的數(shù)據(jù)包。
proxy protocol協(xié)議流程
查閱到proxy protocol報(bào)文的格式如下圖中所示，里面包含了客戶端的源地址和端口等信息，能夠滿足我們的需求。
proxy protocol報(bào)文格式
后端服務(wù)要獲取這個(gè)特殊報(bào)文也需要在Nginx上配置開啟proxy_protocol協(xié)議，如下圖中所示。
Nginx上配置開啟proxy_protocol協(xié)議
通過wireshark工具抓包我們也發(fā)現(xiàn)包結(jié)構(gòu)和查閱到的資料是一致的，接下來我們要做的就是在MQTT協(xié)議解析的時(shí)候把這個(gè)特殊的包也要解析處理并保存這個(gè)客戶端的真實(shí)IP。
Wireshark抓proxy_protocol協(xié)議包
Part 03
● 實(shí)踐操作 ●
說干就干，我們修改MQTT接入服務(wù)的源代碼是基于Netty框架實(shí)現(xiàn)的，于是我們在編解碼的時(shí)候增加了真實(shí)IP解碼器，如下圖所示。
真實(shí)IP解碼器
隨后我們在解碼器的decode方法中，將原始報(bào)文解析出來，判斷是否有proxy protocol報(bào)文，然后解析報(bào)文并提取里面的設(shè)備真實(shí)源IP地址和端口，并將之保持在Netty中的ChannelAttribute上下文中，方便后續(xù)獲取。
注意，這里的proxy protocol報(bào)文和MQTT協(xié)議中的報(bào)文是粘包在一起的，所以我們需要提取源地址后將剩余的MQTT協(xié)議包分離處理交給后續(xù)的MQTT協(xié)議解碼器進(jìn)行處理，這就是整體處理流程。
真實(shí)IP解碼器源碼
Part 04
● 測試認(rèn)證 ●
重新打包部署服務(wù)后，我們根據(jù)日志看到通過Nginx負(fù)載方式能夠正常獲取到測試設(shè)備的源IP信息，滿足需求。
對于4層的UDP協(xié)議獲取設(shè)備源IP也可以參考本方案解決。
