虚拟机三种网络模式

基本知识

ipconfig查看信息。
网关(Gateway)又称网间连接器、协议转换器。是你连接到的上层节点的地址。
ip地址是你本身的地址（如果是路由器分配的 那么是路由器所构建的内网地址）
网卡：需要网卡才能连接其他设备 是设备端的
交换机：类似集线器
路由：类似路由器

Virtual Ethernet Adapter
Network Adapter VMnet1虚拟网卡连接
VMnet1虚拟交换机

vmnet1是vmware的虚拟网卡，默认用于host-only模式
vmnet8是vmware的虚拟网卡，默认用于nat模式
这2个网卡，都跟物理主机的本地连接没有关系。

网络适配器VMware Virtual Ethernet Adapter for vmnet1是vmware的虚拟网卡

专用网络是两个企业间的专线连接，这种连接是两个企业的内部网之间的物理连接。专线是两点之间永久的专用电话线连接。和一般的拨号连接不同，专线是一直连通的。这种连接的最大优点就是安全。除了这两个合法连入专用网络的企业，其他任何人和企业都不能进入该网络。所以，专用网络保证了信息流的安全性和完整性。
域是微软的活动目录的概念,只要你的机器加入了活动目录(和工作组不同),且在网络中检测到你所加入的活动目录,那么就会显示出域网络

桥接模式Bridged

物理机上虚拟网卡VM0相当于交换机（集线器），一头连到了家用路由器，另外N头接所有需要上网的电脑。虚拟机 和 物理机同等地位。

所以虚拟机的网络配置和物理机保持一模一样。
如果物理机是固定IP，这里虚拟机也要固定IP，把IP末尾改一下其他DNS不变。
这里物理机自动分配，于是虚拟机也自动分配。

NAT模式

NAT模式借助虚拟NAT设备和虚拟DHCP服务器，使得虚拟机可以联网。在NAT模式中，主机网卡直接与虚拟NAT设备相连，然后虚拟NAT设备与虚拟DHCP服务器一起连接在虚拟交换机VMnet8上，这样就实现了虚拟机联网。

类似路由器，物理机虚拟出了一个路由器，然后虚拟机连接到这个虚拟路由器。

虚拟机在物理机的一个子网中，虚拟机的地址是内网地址，虚拟机所有上网都是借助物理机NAT功能把内网IP转换成外网IP，因此对外面网络上花花绿绿的机器来说，看到的永远只是外网IP。
类似于我现在一个笔记本、一个手机都是通过家用路由器上网，一个192.168.1.2，一个192.168.1.3，但是对百度来说，它所看到的源IP绝对不是这个，而是经过路由器转换后的电信提供的公网IP。百度无法从这一个IP判断是我的笔记本还是手机在上网。

内网把DNS发到192.168.204.2，就会有人来做这个DNS查询，这实际上是因为上述虚拟网络编辑器中配置了网关192.168.204.2，VMware就来我们完成。

剩下只需要保证虚拟机连上VM8，且IP在这个网段内，就好啦~

虚拟出一个路由器，然后其他设备连接到这个路由器的dns服务器地址

Host-Only（仅主机模式）

什么叫做仅主机？就是虚拟机只能跟物理机联系，不能直接上互联网。
想象就是两台家用电脑，一根网线把它们连起来。这时候如果双方IP掩码都在一个段，就可以相互通信；如果不在就连不了，因为对方并没有DHCP的能力。

Host-Only模式其实就是NAT模式去除了虚拟NAT设备，然后使用VMware Network Adapter VMnet1虚拟网卡连接VMnet1虚拟交换机来与虚拟机通信的。之所以称之为仅主机模式，就是虚拟机只能和宿主机进行通信，不能连接互联网，也不能在局域网进行访问和被访问。他和NAT模式一样，独立使用一块虚拟机网卡，一般名称为VMware Virtual Ethernet Adapter for VMnet1

三种网络模式在的生活中类比

以下箭头均代表访问方式为：主动请求，被动接收

红色代表：局域网内的访问

绿色代表：可以访问外网，比如互联网

一、仅主机模式

二、NAT模式（地址转换模式）

此种情况相当于，虚拟机是个小学生，还没有自己的支付宝账号和银行卡，他可以外界交互，去购物，但是都是以父母的身份去购物，拿着父母的支付宝或银行卡。此时父母（物理主机）可以访问外网，虚拟也可以，不过是透过父母去间接访问外网。

三、桥接模式

此种情况相当于，虚拟机已经长大成人，有也自己的独立身份，有自己的支付宝账号和银行卡，他可以直接与外界交互，去购物，无需再透过父母的身份去购物。此时父母（物理主机）可以访问外网，虚拟也可以独立，直接的访问外网。

隧道

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 端口的网络包里面，不就可以通过这防火墙了吗?

如图5所示。这就如同在防火墙里面挖了一条隧道出来，看到图中那个正穿过 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 发起请求。

图 6：通过SSH tunnel来将请求穿越防火墙细节图

二哥在文章《​​如何对Pod容器进行remote debug​​》里详细描述了 SSH Tunnel 的使用场景。

VPN
二哥在文章《tun设备的妙用-VPN篇》及《tun设备的妙用-OpenVPN篇全流程补充》详细介绍了VPN的工作原理以及客户端通过VPN向企业内部服务发起请求时所涉及到的具体过程。附图如下，细节跳过。

实战

链接yun 隧道