編輯搜圖

大家好，我是二哥。

Tunnel 中文譯作隧道。平時(shí)開發(fā)中，我們或多或少都會(huì)碰到這個(gè)詞。

我們先借助現(xiàn)實(shí)中的一個(gè)例子來看看隧道的作用。

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

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

這個(gè)時(shí)候就得上Tunnel了。Tunnel的概念不難理解，它有兩個(gè)鮮明的特點(diǎn)值得列出來：

• 它需要借助 middle man 來中繼數(shù)據(jù)。這很好理解。通信雙方但凡可以直連，就不需要借助別人了。

• 這個(gè) middle man 既可以是用戶態(tài)應(yīng)用，如我們下文要聊的 HTTPS Proxy，也可以位于內(nèi)核態(tài)模塊，如我們之前聊過的基于 flannel.1 實(shí)現(xiàn)的 VXLAN。

• middle man 所中繼的數(shù)據(jù)在大部分應(yīng)用場景下是被加密過的，這就使得 middle man 退化為一個(gè)管道的角色，而不再具備數(shù)據(jù)嗅探的功能。數(shù)據(jù)不經(jīng)加密通過隧道的一個(gè)例子是 Flannel VXLAN 模式。

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

• HTTPS proxy 所涉及到的 tunnel 。它是通過 HTTPS proxy 不斷地 relay 客戶端和服務(wù)器的數(shù)據(jù)來實(shí)現(xiàn)的。

• SSH tunnel 。它是利用了防火墻開放 22 端口來實(shí)現(xiàn)的。當(dāng)然，如果防火墻把 22 端口關(guān)閉了，那這招就失效了。

• VPN tunnel 。

• 基于 flannel VXLAN 模式所實(shí)現(xiàn)的 K8s Overlay 網(wǎng)絡(luò)模型。

我們來一個(gè)一個(gè)瞧瞧。

HTTPS Proxy Tunnel

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

• 客戶端瀏覽器向它發(fā)起 TCP 連接，并把實(shí)際需要訪問的 web service 放在 GET 和 HOST HTTP header 中。

• 它收到請求后，解析 HTTP header，并向真正的 web service 發(fā)起請求。

• 稍后它再將 web service 返回的內(nèi)容返回至客戶端。

在上述這個(gè)過程中，HTTP Proxy 同時(shí)維持了2個(gè) TCP 連接。因?yàn)樗浅Ｇ宄刂揽蛻舳撕头?wù)端之間的對話內(nèi)容，所以帶來了安全隱患。另外有些無良的 Proxy 還會(huì)自己往服務(wù)端所返回的 HTML 頁面里面添加煩人的廣告。

編輯搜圖

圖 1：HTTP Proxy

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

為了解決這個(gè)問題，HTTPS Proxy 應(yīng)運(yùn)而生。圖 2 展示了它的工作流程。

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

② HTTPS Proxy 收到這個(gè)連接后，利用 CONNECT 請求里面的數(shù)據(jù)，向 google.com 發(fā)起 TCP 連接。

③ 從此以后 HTTPS Proxy 只負(fù)責(zé) relay 客戶端和 google.com 之間的數(shù)據(jù)，不會(huì)做任何解析，也沒有辦法解析，因?yàn)樗緵]有參與 TLS handshake 這個(gè)過程。它所 relay 的數(shù)據(jù)包括：TLS handshake 數(shù)據(jù)包(如證書、加密算法、加密秘鑰等)、加密過之后的HTTP payload。

在步驟 ③ 這里，HTTPS Proxy 通過對客戶端及服務(wù)端會(huì)話數(shù)據(jù)的透明轉(zhuǎn)發(fā)，實(shí)現(xiàn)了 tunnel 的效果。

需要強(qiáng)調(diào)的是上述過程中，瀏覽器從始至終都沒有和 google.com 發(fā)起直接的TCP連接，通信雙方所有的數(shù)據(jù)都是經(jīng)過 HTTPS Proxy中轉(zhuǎn)的。

編輯搜圖

圖 2：通過 HTTPS Proxy ，客戶端和服務(wù)器直接創(chuàng)建了一個(gè) tunnel

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

編輯搜圖

圖 3：通過CONNECT method創(chuàng)建一條TLS tunnel

編輯搜圖

圖 4：通過 CONNECT method 創(chuàng)建一條 TLS tunnel 抓包

SSH Tunnel

經(jīng)過研究，你發(fā)現(xiàn)因?yàn)榉阑饓Φ脑?，雖然客戶端和服務(wù)器之間無法直接通信，但有一個(gè)好消息：防火墻對端口 22 是開放的。

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

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

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

編輯搜圖

圖 5：通過 SSH tunnel 來將數(shù)據(jù)穿越防火墻示意圖

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

• SSH client 偵聽在 localhost:9300。

• 當(dāng)客戶端訪問 localhost:9300 時(shí)，實(shí)際上訪問請求會(huì)被 SSH Client 封裝并經(jīng)過 SSH tunnel 送至 SSH server端。SSH server 偵聽在 192.168.5.24:22 。

• SSH server端再向 192.168.4.23:32020 發(fā)起請求。

編輯搜圖

圖 6：通過SSH tunnel來將請求穿越防火墻細(xì)節(jié)圖

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

VPN

二哥在文章《tun設(shè)備的妙用-VPN篇》及《tun設(shè)備的妙用-OpenVPN篇全流程補(bǔ)充》詳細(xì)介紹了VPN的工作原理以及客戶端通過VPN向企業(yè)內(nèi)部服務(wù)發(fā)起請求時(shí)所涉及到的具體過程。附圖如下，細(xì)節(jié)跳過。

編輯搜圖

圖 7：瀏覽器通過VPN訪問企業(yè)內(nèi)部服務(wù)場景

Flannel VXLAN

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

對比總結(jié)

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

編輯搜圖

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

從使用方便的角度來講，當(dāng)然 VPN 是最好的，只要通過了 VPN 認(rèn)證，就等于從客戶端完全叩開了企業(yè)內(nèi)部網(wǎng)絡(luò)的大門。從企業(yè)安全的角度來說，VPN 又是粒度最粗獷的，也不安全的一種方式。