前言

先說一下場景需求：
1、遠程ssh訪問設備，但是設備端不具備公網訪問能力。
2、物聯網採集網關，通過4G連接外網，網關部署在項目現場，我們不知道網關的IP，就算知道，網絡鏈路也不通。對於網關的遠程調試和運維都無法進行。
目前的解決方案：
1、通過SD-WAN技術，設備與設備之間打通隧道。
2、通過VPN，本地部署VPN服務器，實現VPN專網。
3、採用阿里雲/華為雲邊緣計算解決方案，設備連接到阿里雲/華為雲邊緣平臺，實現遠程運維、調試。

現有方案優缺點

1、SD-WAN技術，需要配備SD-WAN軟件或硬件，對於企業用戶是合適的。但是設備廠商並不合適。
2、採用VPN，如果是運營商VPN，成本昂貴，如果是私有部署VPN，部署相對專業，我沒有部署過，不過有一定的專業門檻。
3、使用公有云提供的邊緣計算方案，相當於要捆綁公有云，有不小的學習成本。
綜上，上述方案的優點簡單的說就是方案成熟，穩定，缺點就是要花錢買錢和不少人力。

工程師方案

上面的方案是基於外部力量實現的，對於稍微有些能力的開發者而言，也是有少花錢的解決方案的，簡單的說，就是在一臺公網服務器上，部署一個自己開發的 隧道轉發 應用程序，設備通過 自己開發的應用程序來建立隧道，進而實現轉發，流轉。這種方案，理論上可行，稍微有點網絡基礎的人就知道，背後的工作量巨大，光是穩定性這塊就很難保證，就更不用提多併發管理了。

MQTT Broker轉發方案

上面所有的方案，基本上都是要實現一個中轉站，上面提到的工程師方案的難點和缺點是，一般人很難開發出穩定、高可用、併發的中轉服務器。那麼如果有個 現成的、方便部署、穩定、可靠的中轉服務器呢，是否就能解決問題了呢，答案是：yes，有這樣的方案。
關於MQTT的通信協議，可以看我之前關於MQTT的系列文章：
《MQTT協議詳解及開發教程（一）MQTT協議概述》， 這裡就不贅述了。解決方案如下：

我們以MQTT Broker EMQx為例，網關和遠程調試工具作為mqtt client， 通過2個topic：up和down

• 配置工具想要發送命令，則publis消息到 down topic， 網關訂閱down topic，收到命令，對命令進行解析並執行，然後返回消息，publis消息到up topic，而配置工具訂閱up topic，收到返回數據。

這種方案，實現了一種通過Broker搭建隧道，實現數據中轉。

優點

可能有些不熟悉MQTT協議的人會覺得，該方案好像也不過如此啊，原理貌似懂，但是乾的事兒好像也不少啊，其實不然，這種方案有很多優點：
1、MQTT是物聯網領域的通用標準，不管是阿里雲物聯網、還是華為IOT，還是其他公司的IOT，基本上都是通過MQTT協議，可以說MQTT已經是物聯網領域事實上的標準了，標準的優點就是方便，支持多，資料多。
2、MQTT Broker部署非常方便，以EMQx為例，只需要一臺服務器，不管是windows還是linux，部署非常方便，幾乎不要什麼專業知識。
3、MQTT Broker可選擇對象多，EMQx、Apoll等等。
4、開源、免費、穩定，除非要求完善、高質量的服務，一般的知名開源Broker都是免費試用的，關鍵是非常穩定。

其他工作量

有了MQTT Broker的幫助，對於開發者，我們再也不用幹數據轉發、打通隧道這種專業性強、複雜的活兒了，我們只需要針對我們自己的應用需求，做MQTT消息的解析即可。

小結

經過測試驗證，該方案可以實現：

• JSON、ASCII碼等字符串轉發，所以理論上可以實現 ssh模擬。
• 字節、數值、十六進制數值的轉發，所以可以實現遠程功能調試，比如Modbus。
• MQTT支持字節流轉發，也就是支持文件傳輸，實現文件的轉發，類似於xftp。

該方案穩定、部署方便，用戶只需要關注自己的業務應用即可，目前瞭解到，一些物聯網關（中電網關）就是通過該方案實現的遠程調試、下載、上載功能。