編輯搜圖

大家好，我是二哥。

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

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

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

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

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

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

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

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

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

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

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

• VPN tunnel 。

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

我們來(lái)一個(gè)一個(gè)瞧瞧。

HTTPS Proxy Tunnel

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

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

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

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

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

編輯搜圖

圖 1：HTTP Proxy

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

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

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

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

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

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

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

編輯搜圖

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

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

編輯搜圖

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

編輯搜圖

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

SSH Tunnel

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

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

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

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

編輯搜圖

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

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

• SSH client 偵聽(tīng)在 localhost:9300。

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

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

編輯搜圖

圖 6：通過(guò)SSH tunnel來(lái)將請(qǐng)求穿越防火墻細(xì)節(jié)圖

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

VPN

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

編輯搜圖

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

Flannel VXLAN

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

對(duì)比總結(jié)

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

編輯搜圖

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

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