【解决办法】Mac物理机无法ping通另一台Mac物理机中的虚拟机

1. 背景

最近放假没啥事，之前的工作电脑一直在闲置，所以想鼓捣鼓捣，我最终整个环境如下：

图中看起来很合理吧，使用VMware Funsion kali将虚拟机和Windows server 2019虚拟机都装在Mac 2中，将kali虚拟机的22端口映射到Mac 2的2222端口上，Mac 1就可以使用SSH获取到kali虚拟机的终端，并且因为2个虚拟机都是使用NAT连接至Mac 2中，所以kali和Windows server也可以进行通信。我就可以操控kali猛攻Windows server。。。

为什么说是最终环境呢，因为故事的开始不是这样的。。。。

2.就很烦！

2.1 初代环境设计

此时的想法：

2.1.1 M芯片我真是不知道说啥好

问题：

一开始我的想法真的很简单，原本在Mac 1里面已经装过kali虚拟机，再装一个Windows server 2019虚拟机，咱们就来个虚拟机养蛊。但是！在我信心满满的从官网上下载好Windows server 2019镜像的时候，并尝试新建虚拟机的时候：

之前无论是安装kali还是Ubuntu虚拟机，直接在官网点击下载之后就会自动匹配电脑架构。但是微软就很有脾气，哎，只有X64架构的ISO，爱用不用。

解决办法 :

好的微软，我还有一台Intel芯片的Mac 2，我在Mac 2里装虚拟机，你能难死我？

2.2 第二代环境设计

2.2.1 很奇怪的解决办法

此时的想法：

问题：

在Mac 2中安装Windows server 2019虚拟机的时候，前面都很顺利，马上就要进行安装了，来了个报错："Windows 找不到Microsoft软件许可条款。请确保安装源有效，然后重新启动"

一开始我以为是前面在VMware配置的时候出现了问题，因为我没填写许可证序列号。但是我在官网上看即使没有许可证，也可以免费使用180天，所以又装了第二遍，还是一样的报错。

解决办法 ：

上网一顿搜索，得出的解决方法居然是点击设置按钮，移除VMware中的虚拟软驱？？？

不是很明白为什么软驱会出现"找不到Microsoft"的报错。。。

2.2.2 MAC地址安全问题

问题1 ：

按照以往装虚拟机的系统，我都会使用桥接的方式进行网络配置，因为有独立的IP地址，比较好区分和记录。但这次很抱歉，根本没有网。能够获取到IP地址，但是无法进行ping通信。

原因：

MAC地址安全：交换机的一个物理关口或者一个WiFi关联只允许一个特定的MAC地址通过

我在使用桥接模式配置网络的时候，虚拟机会生成一个虚拟MAC地址。校园网发现我电脑多了一份新MAC地址的DHCP请求，就会非常gentleman的给虚拟MAC分配一个IP地址。但是一旦分配完地址，安全策略就会发现我的同一个物理机上跑了2个MAC地址。所以就会把虚拟MAC地址的所有非DHCP流量丢弃掉。

解决办法 ：

OK啊，我换NAT连接

看起来很成功，Windows server虚拟机被VMware重新分配了一个C类IP地址。Mac 2将Windows虚拟机的流量源IP变成了自己的10.135.70.X地址，对于Mac 1来说接到的ping请求看起来就是Mac 2发出来的。

2.2.3 寻址失败问题

问题：

经过上面的问题，我把Mac 1中的kali虚拟机也换成了NAT连接。但是问题又出现了：

在上一个问题中，有提及NAT连接是通过主机替换掉虚拟机的源IP地址达到相互通信的情况。但是按照这个结构，出现了寻址的问题，请求与响应可以看到请求和响应的问题。我们拿一条线（Mac1 --> Windows ）进行举例，Mac 1中将会发送如下命令：

shell 复制代码

# Mac 1 IP addr：10.135.70.5
# Windows IP addr：192.168.151.128
ping 192.168.151.128

从数据流的角度来看这个事：

匹配失败：发出的 Ping 包目的地是 192.168.151.128。Mac1 查表发现：它不属于 127.0.0.1，也不属于本地校园网 10.135.70.0/24
走向"默认网关"：路由表里唯一能匹配这个包的只有 0.0.0.0/0（全网通配）。于是 Mac1 把包发给了路由器网关 10.135.70.1
路由器丢弃：校园级路由器的路由表由学校网管配置，通常运行 OSPF 或 BGP 协议。为了防止地址欺骗和私网环路，这些路由器会配置特殊的规则：
- Bogon Filter (黑洞过滤)：路由器会丢弃所有源自或去往 RFC 1918 私有地址段（192.168.0.0/16 等）的外部流量
- 丢弃反馈：路由器查不到 192.168.x.x 的特定条目，且它的上级（公网）也不处理私有地址，于是包在这一步直接被 Drop (丢弃)

基于这一点，更不要说经过Mac 1替换源地址的kali向Windows进行ping连接了。

解决办法 ：

好好好，我把kali虚拟机和Windows虚拟机都装在Mac 2里面，至少可以解决kali和Windows server通信的问题。即使后面不用Mac 1，也能做实验。如果可能的，还是希望能够在Mac 1里执行操作。因为我没带拓展坞，Mac 2没法连显示器。。。

2.3 终版环境设计

此时的想法就是终版了：

在Mac 2上装好kali和Windows server虚拟机后，最后一个需要解决的问题就是，怎么让Mac 1与kali通信上。但是反过来想一想，我一定需要获得kali的全部数据流量吗，我可能也只是需要kali的22端口的SSH服务。那为什么不做一个端口映射呢。在我向Mac 2某端口发送SSH连接请求，转发给Kali的22端口不就可以了吗。

解决办法

我需要手动的修改Mac 2上VMware的nat.conf文件，命令如下：

shell 复制代码

sudo vim /Library/Preferences/VMware\ Fusion/vmnet8/nat.conf

在配置文件内容，找到"incomingtcp"的注释，在下面就可以新添加一个配置：

shell 复制代码

# 格式：宿主机端口 = 虚拟机IP:虚拟机端口
2222 = 192.168.151.129:22

这里的IP地址换成kali虚拟机的IP地址。接下来手动重启一下Mac 2中VMware的网络服务：

shell 复制代码

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start

回到Mac 1中尝试使用-p参数指定2222端口连接Mac 2：

shell 复制代码

ssh -p 2222 hollk_kali@10.135.70.37

齐活！

3. 总结

真的是被自己蠢死，感觉所有的坑都趟了个遍。回头看尤其是第二版环境设计，啧！

不过还是挺有意思的，已经很久没有写博客了，又找回曾经的感觉。写过的东西无论好与坏都很印象深刻，就这样吧，封面懒得搞了，我得睡觉了。。。