VMware config network

今天折腾虚拟机各种网络的问题,电脑也是老卡死,恼火死了,暑假的时候参加嵌入式培训的时候由于要发东西到宿主机,大家也遇到了虚拟机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连接虚拟机,会很卡卡卡卡,原因后面你会懂的)

  1. 桥接模式。这是默认设置的模式(我的虚拟机版本是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)的时候发现出现了重定向的问题,如下图:

      来自七牛云的图片

      按照百度的解释,这种问题出现的原因有两个: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的话不会抓到任何数据,这是因为虚拟机通过虚拟的交换机连接在一起,所以除了第一次通信构造转发表时宿主机会受到报文,其他时候是收不到的。综上所述我们大概画出了下面的拓扑图:来自七牛云的图片

上面这些都是我自己的猜想,能否拿来解决我们在校园网中遇到的问题呢?接下来我们就来看看校园网中的复杂情况吧。由于我们处在校园网内,所以可以再增加一个我们学校的bt down铺的主机。所以我们现在能够确定的(简化了核心交换机)拓扑信息如下:
来自七牛云的图片

然后用 ping 命令进行实验得到下面这样的结果:

  1. win8 ping 虚拟机,时而出现超时,一般时延小于1ms,有时时延极大。wireshark直接死掉,里面出现大量的重复request数据,request的ttl从1到128不等且多次重复出现,reply的ttl稳定128 而数量和request几乎相当,ping了4次出现了500万+条数据报。tracert要在本机的几点上重复跳不定次。
  2. 虚拟机 ping win8 ,对于xp时而出现超时,一般时延小于1ms,有时时延极大。对于linux 出现大量DUP! 提示,虚拟机卡死。wireshark由于中间按了停止所以,发现reply的ttl从128到90不等各种重复出现,request出现3条ttl都为64,同样在半路停止的情况下出现了50万+条的reply数据报。tracert只需一条。tracepath 无法到达。
  3. linux ping btdown铺发现出现大量重定向和大量来自win8的数据报(这已经很明显地出现环路了),wireshark里面显示数据报依然有300万+大部分是重定向和来自bt down铺的reply,当时同学说bt down铺并没有异常。网络指示灯狂闪。。。
  4. 虚拟机互ping无异常,wireshark抓不到任何包,tracexx一跳就到。但是一旦关闭目标主机,出现大量重定向。。。
  5. win8 ping bt down铺正常而且能抓到报文。

    来自七牛云的图片
T B
站点访问量: / , 本页阅读量:
T B