今天折腾虚拟机各种网络的问题，电脑也是老卡死，恼火死了，暑假的时候参加嵌入式培训的时候由于要发东西到宿主机，大家也遇到了虚拟机ping不通宿主机的问题，当时很多同学是碰运气，我也不记得当时是怎么解决的，现在就把VMware里面的一些网络配置仔细写一下。
安装完虚拟机后，我们还可以在windows的控制面板\网络和 Internet\网络连接里面看到这样两个连接
其中VMnet1是虚拟机Host-only模式的网络接口，VMnet8是NAT模式的网络接口，这些后面会介绍，查看他们两个的ip，可以发现VMnet1的ip是192.168.178.1，VMnet2的ip是192.168.254.1,。
打开一台虚拟机后，点击 虚拟机 > 设置 > 网络适配器 我们可以看到像下面这样的情况。
然而当我们在VMware里面 编辑 > 虚拟网络编辑器 的时候却看到下面这个情况
其实这才是真实的情况，有三种连接的方式分别是 桥接模式，仅主机模式，NAT模式。接下来我们就一一解析这三种模式（PS：以下实验极有可能造成宽带断网之类的不良影响，并且确保你的电脑内存够大磁盘读写够快，否则容易造成电脑死机，由此引发一切后果概不承担。还有，在桥接模式下，别用putty之类的试图通过ssh连接虚拟机，会很卡卡卡卡，原因后面你会懂的）
- 桥接模式。这是默认设置的模式（我的虚拟机版本是11.1.2 build-2780323），但是我使用这个模式的时候经常卡死，所以本着求知的精神打算看看它的拓扑结构，为了了解它的拓扑结构我们先进行一系列实验。为了排除不同的操作系统底层实现对实验带来的影响，我们开了3个虚拟机，分别是archlinux最新版，xp，ubuntu14.04，宿主机是win8.1，关闭所有机器的防火墙，尤其是xp。
之前都是接在学校的局域网上实验的，痛苦万分，受到小伙伴的提示，我把电脑接到一个普通的家庭无线路由器上，这样网络环境相对简单，按照VMware的说法在windows下是允许桥接无线网的。所以有下面这样的一个拓扑关系（顺便给出路由表）：
首先看到他们的路由表：可以看到两台linux的虚拟机的路由表是一样的，有两条，第一条的意思是默认网关是192.168.1.1，第二条的意思是对于网络号是192.168.1.0/24 的目的ip的网关是0.0.0.0，不经过三层（代表直连路由，就是不要通过网关路由，直接下发到链路）。
实验结果表面上一切都和我们想的一样但是 出现一个重定向 这就值得我们怀疑了。实验过程如下：
* 当我们用虚拟机ping win8的时候发现显示没有任何问题，但是经过抓包后遇到了下面的问题：
可以看到这里的request报文的ip是没有问题的，但是mac是一样的，都是win8的mac，所以我们应该可以猜想，虚拟机其实不是真的暴露在局域网内，而是win8又建了一个小的”网络”，从上面的Archlinux的路由表可以看出，对于本网内的数据报直接广播没有不用经过路由，但是呢，arch的链路域是由win8 arch及其他的虚拟机组成的，所以呢Vmware应该有个进程(你看看你是不是装了Vmware bridge protocol)专门来收这种虚拟机的mac（原因详见我的另外一篇文章），Vmware的进程收到这些数据报之后会说这个发不得会出事，然后会不管三七二十一就把源mac改成宿主机（win8）的mac，然后通过真实的网卡下放到链路上（因为我们在真是的网卡上面确实捕捉到了这个数据包），这时的路由器就相当于一个二层交换机（因为数据报的通信双方的ip地址在同一网段），然后交换机一看这个数据报目的mac，你他喵的不就是你的么，所以又把这个数据报原封不动（因为没有路由所以源mac不变）返回给了我们的win8的真实网卡，然后Vmware又有一个进程(Vmware bridge protocol)相当于是给收到的数据报“路由”的（原因也很简单，以为发到这个mac地址的数据并不一定是给我的，我下面还有虚拟机，可能是他们的mac被改后发出去的数据报的响应）进过对比发现这个是给我的（就算不是也不能丢弃，还要看看目标mac是不是虚拟机的，是的话再看ip是不是对的上，都不是才丢弃），好的，处理后发现是个IP为111的发给我的，然后他不知道这个ip对应的mac，所以arp问，如下图：
问到了111的mac，所以发送一个reply报文（源mac是win8 的mac，目的mac是虚拟机的mac,就像上面的截图一样）给虚拟机，经过查询路由表之后发现，这个数据报应该直接下放到链路上，数据报就到了交换机这里，交换机收到这个数据报之后就看看这个目标mac是虚拟机的mac所以就把它发到了win8的接口上，win8一看，这个目的mac是个私有的mac不是我的扔掉吧，这时候虚拟机的守护进程跳出来，不能扔，这个可能是我们这边的，然后交给了虚拟机这边进程处理，然后一看mac地址不真是arch的mac地址么，好的下发给他。arch收到后上到三层一看这个ip不就对应着自己的ip么，好的收下了。
* 当我们用虚拟机ping 网关(.1)的时候发现出现了重定向的问题，如下图:
{% qnimg VM-net-arch-ping-gate-redirect.png title:test alt:来自七牛云的图片 'class:class1 class2' %}
按照百度的解释，这种问题出现的原因有两个：1)当路由器从某个接口收到数据还需要从相同接口转发该数据时；2)当路由器从某个接口到发往远程网络的数据时发现源ip地址与下一跳属于同一网段时。再仔细看看里面发给arch重定向要求的是win8的ip，所以可以肯定的是arch把数据报发到了win8的虚拟路由，然后win8的虚拟路由发现arch与目的ip是直达的，所以发出了重定向请求。这里我思考了很久，我一直在考虑的一个关键点是，到底这个和之前那个ping 宿主机会有什么区别，我们可以肯定这次肯定是经过路由了的（因为有redirect报文），而这就意味着之前的没有经过路由，可是为什么这次要路由之前不要，这里只有一点不同，那就是目的ip。这就意味着之前的目的ip是和虚拟机是同一链路域，而这次没有，可是这三个ip明明是同网段的啊，这里我们忽略了很重要的一点，对于家庭路由器来说，这三个ip肯定是同网段的，但是对于win8上那个虚拟路由来说就不是了，那个路由估计不会用子网掩码这种复杂的东西， **它估计就是把宿主机和所有虚拟机的ip组成一个集合，在这个集合里面的就是同网段，反之就是不同网段需要路由** 。所以这样就得出了我们的结果,由于目的ip（.1）不在虚拟路由的集合里面所以要进行路由（把源mac改成了win8真实的mac，目的mac由原来的win8的mac改成了家庭路由器的mac），然后发出去并发送一个重定向的数据报（源mac和目标mac都是win8的真实mac）到链路通知虚拟机重定向，接下来就和上面一样了。所以我们之前一直弄错的一点就是 **我们的虚拟机的0.0.0.0网关其实是宿主机上的虚拟路由器**。等到家庭路由收到
* 再来解释一些奇怪的现象，xp ping 网关不会出现重定向，这其实是因为windows系统没有显示重定向的报文（包括后面的DUP报文），如果你去抓包还是能够看到的。虚拟机互ping的话不会抓到任何数据，这是因为虚拟机通过虚拟的交换机连接在一起，所以除了第一次通信构造转发表时宿主机会受到报文，其他时候是收不到的。综上所述我们大概画出了下面的拓扑图：
{% qnimg VM-net-virtual-actually.png title:test alt:来自七牛云的图片 'class:class1 class2' %}
上面这些都是我自己的猜想，能否拿来解决我们在校园网中遇到的问题呢？接下来我们就来看看校园网中的复杂情况吧。由于我们处在校园网内，所以可以再增加一个我们学校的bt down铺的主机。所以我们现在能够确定的（简化了核心交换机）拓扑信息如下：
然后用 ping 命令进行实验得到下面这样的结果：
- win8 ping 虚拟机，时而出现超时,一般时延小于1ms,有时时延极大。wireshark直接死掉，里面出现大量的重复request数据，request的ttl从1到128不等且多次重复出现，reply的ttl稳定128 而数量和request几乎相当，ping了4次出现了500万+条数据报。tracert要在本机的几点上重复跳不定次。
- 虚拟机 ping win8 ，对于xp时而出现超时,一般时延小于1ms,有时时延极大。对于linux 出现大量DUP! 提示，虚拟机卡死。wireshark由于中间按了停止所以，发现reply的ttl从128到90不等各种重复出现，request出现3条ttl都为64，同样在半路停止的情况下出现了50万+条的reply数据报。tracert只需一条。tracepath 无法到达。
- linux ping btdown铺发现出现大量重定向和大量来自win8的数据报（这已经很明显地出现环路了），wireshark里面显示数据报依然有300万+大部分是重定向和来自bt down铺的reply，当时同学说bt down铺并没有异常。网络指示灯狂闪。。。
- 虚拟机互ping无异常，wireshark抓不到任何包，tracexx一跳就到。但是一旦关闭目标主机，出现大量重定向。。。
- win8 ping bt down铺正常而且能抓到报文。
