debian上启动一台系统为redhat的vmware虚拟机(版本为5.5.1),redhat有三块网卡:eth0,eth1,eth2,分别设置为bridge,nat,host-only模式,在物理机器debian上的/proc中可以看到网络连接情况:
debian:/proc/vmnet# ls
bridge0  hub0.1  hub1.1  hub8.0  hub8.3  netif1   userif10  userif5
hub0.0   hub1.0  hub1.2  hub8.1  netif0  userif1  userif11  userif9
hub后面的数字是m.n的格式,其中m表示一个虚拟交换机,而n表示该交换机上的插口,可以看出该系统目前有三台虚拟交换机:hub0,hub1,hub8。通过查看hubm.n的内容可以看到它们每一个插口上连接的“网卡”,以bridge为例:
debian:/proc/vmnet# cat hub0.0
connected bridge0 tx 12460
debian:/proc/vmnet# cat hub0.1
connected userif9 tx 366
可以看出,仅仅连接了两个“网卡”,第一个是bridge网卡,也就是真实的网卡设备(bridge的时候要指定真实网卡),第二个是虚拟机里面的网卡:
debian:/proc/vmnet# cat userif9
connected hub0.1 mac 00:0c:29:1b:85:3d ladrf 00:00:80:00:00:00:40:40 flags IFF_RUNNING,IFF_UP,IFF_BROADCAST,IFF_MULTICAST read 4286 written 366 queued 4286 dropped.down 12 dropped.mismatch 8147 dropped.overflow 0 dropped.largePacket 0
其中00:0c:29:1b:85:3d即是虚拟机里面Redhat系统的ifconfig eth0得到的mac地址结果,类似的,对于hub8.x系列来说,如下:
debian:/proc/vmnet# cat hub8.*
connected userif1 tx 32 
connected netif0 tx 5
connected userif11 tx 41
其中,userif1是用户态实现的nat设备的字符设备接口,netif0是内核的虚拟网卡设备,userif11是虚拟机redhat系统的eth1,这里还少了一个设备,用户态实现的dhcp设备,这是因为我故意将它(vmnet-dhcpd)kill掉了,它暂时没有用。
     除了在/proc中可以看到的这些信息之外,ps -elf也会发现几个进程,其中最重要的就是vmnet-natd和vmware-vmx了,对于vmware-natd来讲,它在用户态实现了一个nat设备,lsof这个进程:
debian:/proc/vmnet# lsof -p 4637
COMMAND    PID USER   FD   TYPE     DEVICE    SIZE     NODE NAME
...
vmnet-nat 4637 root    3u   CHR      119,8         33477775 /dev/vmnet8
vmnet-nat 4637 root    4u   raw                        6803 00000000:0001->00000000:0000 st=07
vmnet-nat 4637 root    5u  unix 0xf6fb5900             6804 /var/run/vmnat.4637
它打开了vmnat8这个字符设备,而这个字符设备就实现了nat,它就对应/proc/vmnet/中的userif1这个假网卡,那么它是如何实现nat的呢?肯定不是内核实现的,因为此时ipforward为0,另外nat内核模块没有加载,iptables的nat表也没有内容,想来vmware实在不必使用操作系统提供的nat功能,万一操作系统没有这个功能,岂不是vmare的nat模式不能使用了?按照vmware的网卡nat设置在虚拟机redhat上设置一下路由:
route add default gw 192.168.120.2
至于说这个120.2是谁的ip地址,还真不好查,实际上它就是用户态nat设备的ip地址,就和一个nat网关有一个ip地址一样,然后在redhat中telnet一下一个外网的地址,然后再lsof一下vmnet-natd这个进程,发现多了一行:
vmnet-nat 4637 root    7u  IPv4      10451              TCP 192.168.188.247:32775->192.168.40.91:www (ESTABLISHED)
如果还是不明白这到底是怎么一回事,那么近strace吧,strace这个natd进程,然后再次telnet,发现natd竟然去connect 192.168.40.91了,然后是natd与40.91之间建立了一条tcp连接通道,然后把数据代理给redhat的,只是不仅仅是第七层的数据,而是连tcp握手以及第四层的数据比如序列号等都要代理,很显然这里的握手的信息是natd自己造出来的,因为它用connect连接远程主机,握手包是得不到的。代理数据的时候,很显然执行了nat,其实也就是将userif(/dev/vmnet8)中读出的以太帧中取出目的ip和协议,然后自己和远程通信,得到纯应用数据后,再由从虚拟网络中来的原来的以太帧中的某些部分,比如原始的ip地址等信息构造出一个以太帧,然后发给userif,随后这个userif将得到的数据发给虚拟交换机,然后虚拟交换机将这个以太帧发给另一个userif,这个userif就是vmware-vmx打开的/dev/vmnet8得到的userif了,也就是上面的userif11,vmware-vmx会通过系统调用和模拟中断虚拟机里的网卡将数据转给虚拟机的,vmware-vmx打开的userif其实就是虚拟机里面的网卡的代理,连接到了虚拟交换机之上。
     用这种直接和目的主机通信(tcp:connect/send/recv;udp:sendto/recvfrom)然后构造回复给虚拟机的包的方式要比直接去掉源ip,查找目的ip的路由,添加物理主机的新源ip,然后发送raw数据包(scapy的方式)的方式效率更高一些,毕竟以太帧已经从userif中得到了,还有什么无法构造的呢!

Logo

华为开发者空间,是为全球开发者打造的专属开发空间,汇聚了华为优质开发资源及工具,致力于让每一位开发者拥有一台云主机,基于华为根生态开发、创新。

更多推荐