大家好，我是二哥。
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 端口关闭了，那这招就失效了。
- V** 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 的使用场景。
V**
二哥在文章《tun设备的妙用-VPN篇》及《tun设备的妙用-OpenVPN篇全流程补充》详细介绍了V**的工作原理以及客户端通过V**向企业内部服务发起请求时所涉及到的具体过程。附图如下，细节跳过。
图 7：浏览器通过V**访问企业内部服务场景
Flannel VXLAN
人狠话不多，直接附上文章《tun设备的妙用-Flannel UDP模式篇》。
对比总结
如果说 HTTPS proxy tunnel 以及 SSH tunnel 还只是比较节制地在客户端和服务器端建立了定向隧道的话，V** 这种类型的 tunnel 则直接把企业内部的大门全部敞开了，理论上只要 V** 在客户端配置好允许访问应用的 DNS cache 及路由，客户端就可以如同在公司内部一样自由地访问企业内部服务了。
图 8：V** tunnel和另外两种tunnel 可访问服务粒度比较
从使用方便的角度来讲，当然 V** 是最好的，只要通过了 V** 认证，就等于从客户端完全叩开了企业内部网络的大门。从企业安全的角度来说，V** 又是粒度最粗犷的，也不安全的一种方式。
以上就是本文的全部内容。码字不易，画图更难。喜欢本文的话请帮忙转发或点击“在看”。您的举手之劳是对二哥莫大的鼓励。谢谢！
