手边的Tunnel知几许
发布时间：2022-06-10 05:15:12 所属栏目：云计算 来源：互联网
导读：详解边缘计算系统逻辑框架 云 边 端协同: Tunnel 中文译作隧道。平时开发中，我们或多或少都会碰到这个词。 我们先借助现实中的一个例子来看看隧道的作用。 西成高铁北起西安，南至成都，线路全长643公里，设计时速250公里。自古以来，进入天府之国就是一
|
详解边缘计算系统逻辑框架 云 边 端协同: 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 页面里面添加烦人的广告。 时代在变，技术在变，需求也在变。如今放眼望去，大部分网站都在使用 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中转的。 SSH Tunnel 经过研究，你发现因为防火墙的原因，虽然客户端和服务器之间无法直接通信，但有一个好消息：防火墙对端口 22 是开放的。 如果把你的请求作为 payload 放到访问 22 端口的网络包里面，不就可以通过这防火墙了吗? 这就如同在防火墙里面挖了一条隧道出来，看到图中那个正穿过 SSH tunnel 的红色长条吗?像不像正在穿过秦岭隧道的高铁? 当然这个网络包的接收端是一个侦听在 22 端口的SSH server。它收到这个网络包后做什么事情不重要，重要的是你的请求已经成功地穿过了防火墙，且被投递出去了。不单如此，借助SSH自带的Secure加持，数据还是加密投递的。用一送一的感觉有没有? 好吧，知道 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 发起请求。 二哥在文章《如何对Pod容器进行remote debug》里详细描述了 SSH Tunnel 的使用场景。 VPN 二哥在文章《tun设备的妙用-VPN篇》及《tun设备的妙用-OpenVPN篇全流程补充》详细介绍了VPN的工作原理以及客户端通过VPN向企业内部服务发起请求时所涉及到的具体过程。附图如下，细节跳过。 Flannel VXLAN 人狠话不多，直接附上文章《tun设备的妙用-Flannel UDP模式篇》。 对比总结 如果说 HTTPS proxy tunnel 以及 SSH tunnel 还只是比较节制地在客户端和服务器端建立了定向隧道的话，VPN 这种类型的 tunnel 则直接把企业内部的大门全部敞开了，理论上只要 VPN 在客户端配置好允许访问应用的 DNS cache 及路由，客户端就可以如同在公司内部一样自由地访问企业内部服务了。 从使用方便的角度来讲，当然 VPN 是最好的，只要通过了 VPN 认证，就等于从客户端完全叩开了企业内部网络的大门。从企业安全的角度来说，VPN 又是粒度最粗犷的，也不安全的一种方式。 （编辑：大连站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐