Article / 文章中心

手边的Tunnel知多少

发布时间:2022-05-09 点击数:187

编辑搜图

大家好,我是二哥。

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 又是粒度最粗犷的,也不安全的一种方式。