大家好，我是二哥。

Tunnel 中文譯作隧道。平時開發中，我們或多或少都會碰到這個詞。

我們先借助現實中的一個例子來看看隧道的作用。

西成高鐵北起西安，南至成都，線路全長643公里，設計時速250公里。自古以來，進入天府之國就是一件異常艱難之事，群峰環伺的四川無論從哪個方向進入都步履維艱。我們知道西安和成都之間隔有秦嶺天險，它就擋在那里，高鐵總不能像飛機一樣從天上飛越過去。又要快，又不能飛，唯一的方法就是在秦嶺群山之間挖隧道，讓高鐵從隧道里面穿過秦嶺。

來到我們的網絡世界。你想訪問Remote Server，但可惜你和它之間隔著防火墻。這個防火墻就如同秦嶺橫亙在那里，躲是躲不過去的，那怎么辦呢?

這個時候就得上Tunnel了。Tunnel的概念不難理解，它有兩個鮮明的特點值得列出來：

• 它需要借助 middle man 來中繼數據。這很好理解。通信雙方但凡可以直連，就不需要借助別人了。
• 這個 middle man 既可以是用戶態應用，如我們下文要聊的 HTTPS Proxy，也可以位于內核態模塊，如我們之前聊過的基于 flannel.1 實現的 VXLAN。
• middle man 所中繼的數據在大部分應用場景下是被加密過的，這就使得 middle man 退化為一個管道的角色，而不再具備數據嗅探的功能。數據不經加密通過隧道的一個例子是 Flannel VXLAN 模式。

我們來看看到目前為止，我們經常使用的隧道有哪些：

• HTTPS proxy 所涉及到的 tunnel 。它是通過 HTTPS proxy 不斷地 relay 客戶端和服務器的數據來實現的。
• SSH tunnel 。它是利用了防火墻開放 22 端口來實現的。當然，如果防火墻把 22 端口關閉了，那這招就失效了。
• VPN tunnel 。
• 基于 flannel VXLAN 模式所實現的 K8s Overlay 網絡模型。

我們來一個一個瞧瞧。

HTTPS Proxy Tunnel

說到HTTPS Proxy，不得不先提起 HTTP Proxy。如圖 1所示。HTTP Proxy 如同一個中間人：

• 客戶端瀏覽器向它發起 TCP 連接，并把實際需要訪問的 web service 放在 GET 和 HOST HTTP header 中。
• 它收到請求后，解析 HTTP header，并向真正的 web service 發起請求。
• 稍后它再將 web service 返回的內容返回至客戶端。

在上述這個過程中，HTTP Proxy 同時維持了2個 TCP 連接。因為它非常清楚地知道客戶端和服務端之間的對話內容，所以帶來了安全隱患。另外有些無良的 Proxy 還會自己往服務端所返回的 HTML 頁面里面添加煩人的廣告。

圖 1：HTTP Proxy

時代在變，技術在變，需求也在變。如今放眼望去，大部分網站都在使用 HTTPS 。這個時候再使用 HTTP Proxy 的話，就會出現一個問題：只有 Proxy 能看到 web service 的證書，但客戶端卻只能接收到 Proxy 的證書。很明顯，Proxy 證書里面的名字和客戶端所想要訪問的地址完全不同，這個時候瀏覽器會毫不留情地給出一個警告，TLS handshake 也沒法通過。

為了解決這個問題，HTTPS Proxy 應運而生。圖 2 展示了它的工作流程。

① 客戶端瀏覽器首先向 HTTPS Proxy 發起 TCP 連接，但在 HTTP 請求里，用的是 CONNECT 方法。

② HTTPS Proxy 收到這個連接后，利用 CONNECT 請求里面的數據，向 google.com 發起 TCP 連接。

③ 從此以后 HTTPS Proxy 只負責 relay 客戶端和 google.com 之間的數據，不會做任何解析，也沒有辦法解析，因為它根本沒有參與 TLS handshake 這個過程。它所 relay 的數據包括：TLS handshake 數據包(如證書、加密算法、加密秘鑰等)、加密過之后的HTTP payload。

在步驟 ③ 這里，HTTPS Proxy 通過對客戶端及服務端會話數據的透明轉發，實現了 tunnel 的效果。

需要強調的是上述過程中，瀏覽器從始至終都沒有和 google.com 發起直接的TCP連接，通信雙方所有的數據都是經過 HTTPS Proxy中轉的。

圖 2：通過 HTTPS Proxy ，客戶端和服務器直接創建了一個 tunnel

圖 3和 圖 4 清晰地展示了客戶端和 HTTPS Proxy 通過 CONNECT method 創建一條 TLS tunnel 的過程。

圖 3：通過CONNECT method創建一條TLS tunnel

圖 4：通過 CONNECT method 創建一條 TLS tunnel 抓包

SSH Tunnel

經過研究，你發現因為防火墻的原因，雖然客戶端和服務器之間無法直接通信，但有一個好消息：防火墻對端口 22 是開放的。

如果把你的請求作為 payload 放到訪問 22 端口的網絡包里面，不就可以通過這防火墻了嗎?

如圖5所示。這就如同在防火墻里面挖了一條隧道出來，看到圖中那個正穿過 SSH tunnel 的紅色長條嗎?像不像正在穿過秦嶺隧道的高鐵?

當然這個網絡包的接收端是一個偵聽在 22 端口的SSH server。它收到這個網絡包后做什么事情不重要，重要的是你的請求已經成功地穿過了防火墻，且被投遞出去了。不單如此，借助SSH自帶的Secure加持，數據還是加密投遞的。用一送一的感覺有沒有?

圖 5：通過 SSH tunnel 來將數據穿越防火墻示意圖

好吧，知道 SSH server 收到數據后干了什么也很重要。圖 5只是一個示意圖，二哥總想把它背后的細節給大家扒拉一遍。在本例中，local client 真正想訪問的是 192.168.4.23:32020 這個服務。當然它無法直接訪問。

• SSH client 偵聽在 localhost:9300。
• 當客戶端訪問 localhost:9300 時，實際上訪問請求會被 SSH Client 封裝并經過 SSH tunnel 送至 SSH server端。SSH server 偵聽在 192.168.5.24:22 。
• SSH server端再向 192.168.4.23:32020 發起請求。

圖 6：通過SSH tunnel來將請求穿越防火墻細節圖

二哥在文章《??如何對Pod容器進行remote debug??》里詳細描述了 SSH Tunnel 的使用場景。

VPN

二哥在文章《tun設備的妙用-VPN篇》及《tun設備的妙用-OpenVPN篇全流程補充》詳細介紹了VPN的工作原理以及客戶端通過VPN向企業內部服務發起請求時所涉及到的具體過程。附圖如下，細節跳過。

圖 7：瀏覽器通過VPN訪問企業內部服務場景

Flannel VXLAN

人狠話不多，直接附上文章《??tun設備的妙用-Flannel UDP模式篇??》。

對比總結

如果說 HTTPS proxy tunnel 以及 SSH tunnel 還只是比較節制地在客戶端和服務器端建立了定向隧道的話，VPN 這種類型的 tunnel 則直接把企業內部的大門全部敞開了，理論上只要 VPN 在客戶端配置好允許訪問應用的 DNS cache 及路由，客戶端就可以如同在公司內部一樣自由地訪問企業內部服務了。

圖 8：VPN tunnel和另外兩種tunnel 可訪問服務粒度比較

從使用方便的角度來講，當然 VPN 是最好的，只要通過了 VPN 認證，就等于從客戶端完全叩開了企業內部網絡的大門。從企業安全的角度來說，VPN 又是粒度最粗獷的，也不安全的一種方式。