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其实就是虚拟机里面的网卡的代理，连接到了虚拟交换机之上。
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中得到了，还有什么无法构造的呢！
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1271130
