说说ESXi虚拟交换机和端口组的“MAC地址更改”和“伪传输”

https://virtualtips.info/?p=316文章中提到过“MAC地址更改”和“伪传输”安全策略。作用范围和“混杂模式”是一样的。

这两个策略分别是做什么的呢?

先了解一些基本概念。

一个物理网卡的ROM中存储着它的MAC地址,不可更改,叫做“初始MAC地址”。

而在操作系统中,比如Windows,该网卡也有个MAC地址,叫做“有效MAC地址”,它是可以通过网卡属性或者注册表修改的。

在默认情况下,初始MAC地址和有效MAC地址是相同的,除非用户修改,修改后,通过物理网卡发送到网络上的帧,源MAC地址就是修改后的“有效MAC地址”,不同于固化的“初始MAC地址”。

虚拟网卡也有类似概念,固化的“初始MAC地址”就是在虚拟机VMX文件中的MAC地址,(ESXi管理员可以修改它,但对虚拟机系统来说,它是固化不可修改的)。而虚拟机系统中的网卡MAC地址,就是“有效MAC地址”,同样可以修改。这些MAC地址,vSphere/ESXi自然都是知道的。

MAC地址更改

ESXi知晓虚拟机的“初始MAC地址”和“有效MAC地址”,当两者不同时,需要执行相应的安全策略:

拒绝:此VM修改了MAC地址,它是想冒充别的VM吗?我把它的端口禁用掉。

允许:我知道VM修改了MAC地址,并启用它的端口。

此时,执行策略的是虚拟交换机,虽然我们说禁用了端口,但其实虚拟机OS本身是不知道的,因为并非在物理层或链路层断开网卡,而是丢弃了发给这个虚拟机OS的帧。

伪传输

MAC地址更改是修改“有效MAC地址”,此时通过此网卡向外传输的帧的源MAC地址也随着“有效MAC地址”修改了。还有些恶意软件,它不修改“有效MAC地址”,直接修改向外传输的帧的源MAC地址。伪传输这个策略检查的就是源MAC是否和“有效MAC地址”一致。

拒绝:当恶意软件修改了源MAC地址(伪造传输),该虚拟机的虚拟网卡就会删除该帧。但会允许没伪造的帧传输出去。

允许:随便什么源MAC,随便发。

此时,执行策略的是虚拟网卡。

两个策略的区别:

MAC地址更改比较的是“有效MAC地址”和“初始MAC地址”,方向是入站(从外界向虚拟机网卡传输的帧),而伪传输比较的是“源MAC”和“有效MAC地址”,方向是出站(从虚拟机网卡向外界发送的帧)。前者是断开入站的端口,后者是过滤出站的伪传输帧。

这两个安全策略可以通过类似“网络执法官”之类的应用配合ARP和PING命令来验证。

参考文档:

MAC 地址更改 (vmware.com)

伪传输 (vmware.com)

说说ESXi虚拟交换机和端口组的“混杂模式”

很多Up主在ESXi虚拟机软路由教程里都提到了ESXi虚拟交换机的安全里要设置“混杂模式”,但基本没有太详细说明什么是”混杂模式”,什么情况要开启“混杂模式”的,先给自己挖个坑,明天出玩回来写一下。

游玩归来填坑~(时隔快一年,再次填坑。)

vSphere虚拟网络02 – 虚拟交换机中,我介绍过vSphere的两种虚拟交换机。标准和分布式。关于“混杂模式”的生效范围,两种虚拟交换机也是有所区别的。以标准虚拟交换机为例,虚拟交换机级别的安全下有“混杂模式”,虚拟交换机的端口组可以继承虚拟交换机的安全属性,也可以覆盖该安全属性。而分布式交换机的”混杂模式“则是作用在端口组和端口级别。PS: 另外的两种安全策略“MAC地址更改”和“伪传输”和“混杂模式”是同理的。可参照官方文档 安全策略,在《关于vSphere网络连接》这个文档中。

关于混杂模式的解释:

混杂模式会清除虚拟机适配器执行的任何接收筛选,以便客户机操作系统接收在网络上观察到的所有流量。默认情况下,虚拟机适配器不能在混杂模式中运行。

尽管混杂模式对于跟踪网络活动很有用,但它是一种不安全的运行模式,因为混杂模式中的任何适配器均可访问数据包,即使某些数据包是否仅由特定的网络适配器接收也是如此。这意味着虚拟机中的管理员或根用户可以查看发往其他客户机或主机操作系统的流量。

注:有时您可能确实需要将标准虚拟交换机或分布式虚拟交换机配置为在混杂模式中运行(例如运行网络入侵检测软件或数据包嗅探器时)。

物理交换机是一个点对点的设备,它维护一个连接到到它上面的设备的MAC地址表。所以它可以实现只把数据送达到指定MAC地址的设备所连接的端口。

虚拟交换机在这方面也是同理。

在虚拟交换机默认不开启混杂模式时,举个例子,假设vSwitch0交换机下有两个端口组,端口组1下有若干Windows虚拟机用于员工办公使用,端口组2下一台Linux虚拟机,管理员用来进行一些网络分析。当我们在端口组2的Linux虚拟机上安装Wireshark之类的抓包工具时,只能抓取到发送到此台Linux虚拟机的数据包(上面提到的点对点),而抓取不到端口组1中的Windows虚拟机之间的数据包或者外界发到Windows虚拟机的数据包,也就是说Wireshark此时是不能远程抓包的。

我们可以对vSwitch0开启混杂模式,或者对端口组2开启混杂模式。推荐对端口组开启,授予权限或安全策略时,一般建议遵守最小化原则。

当端口组2开启混杂模式时,Linux虚拟机就可以抓取vSwitch0上所有数据包了。

这意味着虚拟机中的管理员或根用户可以查看发往其他客户机或主机操作系统的流量。

一个相对易懂的描述就是,混杂模式所做的就是将通过此虚拟交换机的数据流量开放给开启了混杂模式的端口组下面所连接的虚拟机可见。(所以如果是整个虚拟交换机开启混杂模式,就是此虚拟交换机所有流量开放给虚拟交换机下的所有虚拟机都可见。)

如果想尝试上述实验,可以照此创建实验环境,使用Wireshark或者tcpdump在Linux虚拟机上尝试抓取Windows虚拟机的数据包。记得修改混杂模式后重启下虚拟机。

ESXi社区版NVMe驱动更新v1.1

Community NVMe Driver for ESXi | VMware Flings 最近更新,支持到了ESXi 7.0,支持了三款NVMe设备:

VendorVendorIDProductID
ADATA0x1cc18201
Micro/Crucial0xc0a90x2263
Silicon Motion0x126f0x2262

也就是说能匹配以上vid,pid的NVMe设备就可以通过此驱动在ESXi上识别并使用。(在6.7U2更新时,由于ESXi遵照了NVMe 1.3 规范去识别和支持设备,某些消费级别的NVMe因为不支持该规范而无法被ESXi识别并使用,虽说也有用ESXi6.5的某些文件进行替换的变通办法,但还是很麻烦。)

可以下载此驱动,封装到ESXi安装镜像,也可以在已安装好的ESXi系统中离线安装此驱动。

esxcli software vib install -d /xxxxxx/nvme-community-driver_1.0.1.0-2vmw.700.1.0.15843807-component-18290856.zip

ESXi社区版网卡驱动再次更新

最近flings.vmware.com上,社区版的ESXi网卡驱动再次更新。

https://flings.vmware.com/community-networking-driver-for-esxi#summary

从changelog看,最近两次更新内容如下:

May 19, 2021 – v1.2 

    Net-Community-Driver_1.2.0.0-1vmw.700.1.0.15843807_18028830.zip

    md5: fc3b23201d78d3b0d75c8a4fcad759f3 

    What’s New:

    Support for Jumbo Frames (MTU up to 9000)

    Support for Wake-on-LAN (WOL) for Intel i225 NIC

April 08, 2021 – v1.1 

    Net-Community-Driver_1.1.0.0-1vmw.700.1.0.15843807_17858744.zip

    md5: 587d7d408184c90f6baf4204bb309171 

    What’s New:

    Resolve issue when using Intel vPro which can cause ESXi PSOD

ESXi 社区版网卡驱动

最近 VMware的flings网站里新增加了Community Networking Driver for ESXi | VMware Flings.

此驱动旨在对一些官方安装包里不支持的网卡提供一个相对稳定的网卡驱动,可以通过封装到安装镜像或者在现有的ESXi主机上安装来使用.

从requirements一页中可以看到此驱动支持了哪些网卡.

2.5GbE
1GbE

看了下NUC8和NUC11 Pro and Performance的网卡都属于这个驱动可以支持的.

PS: 此前也有一个类似的社区版网卡驱动,之前已经集成到了ESXi7.0.1里.

修复M1 芯片的Mac设备

前些天从公司采购了M1芯片的Macbook Pro,到手后发现系统初始化设置时被设置了Remote Management,等于系统镜像被出厂时预设成公司的企业设备管理了。而我是用来做开发测试用的,被Remote Management不方便,需要移除该管理。

咨询公司IT后,他们先把我的设备序列号从Apple Business Manager中移除掉。

如图

此时,如果通过长按电源键进入Recovery后重新安装Big Sur,安装完毕重启初始化时,还会出现Remote Management。

从苹果官方找到如下文档,在另一台mac电脑上利用Apple Configurator 2,通过Type-c将该电脑与需要修复的电脑连接,需要修复的电脑这边需要将Type-c插入离屏幕近的这个口。https://support.apple.com/zh-cn/guide/apple-configurator-2/apdd5f3c75ad/mac

然后打开Apple Configurator 2, 需要修复的电脑保持关机。然后同时按下电源,左Option,左Ctrl,右Shift,保持10秒,松开三个按键继续按住电源键7秒。松开电源键。然后稍等几秒,Apple Configurator 2里,该需要修复的电脑就进入DFU模式了,此时选择设备,右键,高级,修复。漫长的等待之后,就修复完了。重启,我用电脑创建了一个Big Sur最新版的启动U盘,长按电源键进入启动选项,选择启动U盘,安装Big Sur。完成重启后,Remote Management就不见了。

ESXi 7.0 Update 1c中加入的systemMediaSize启动选项

本周VMware发布了ESXi 7.0 Update 1c更新,查看Release notes,发现有一段比较有意思.

With ESXi 7.0 Update 1c, you can use the installer boot option systemMediaSize to limit the size of system storage partitions on the boot media. If your system has a small footprint that does not require the maximum 138 GB system-storage size, you can limit it to the minimum of 33 GB. The systemMediaSize parameter accepts the following values:

  • min (33 GB, for single disk or embedded servers)
  • small (69 GB, for servers with at least 512 GB RAM)
  • default (138 GB)
  • max (consume all available space, for multi-terabyte servers)

The selected value must fit the purpose of your system. For example, a system with 1TB of memory must use the minimum of 69 GB for system storage. To set the boot option at install time, for example systemMediaSize=small, refer to Enter Boot Options to Start an Installation or Upgrade Script. For more information, see VMware knowledge base article 81166.

对于这个启动选项,我的理解是之前ESXi 7.0默认最大会占用138GB左右硬盘,就是上文中提到的default(其中包括BOOTBANK1, BOOTBANK2, 还有OSDATA, 当硬盘为HDD时,OSDATA不会被当作虚拟闪存使用,此时OSDATA类型为VMFS-L. 当硬盘为SSD时,OSDATA会被同时当作虚拟闪存,此时OSDATA类型为VFFS.) 之前写过我们可以通过设置autoPartitionOSDataSize来调整OSDATA的大小. https://virtualtips.info/?p=42 ,但该方法并非官方提供的解决方案.

此次systemMediaSize参数可以理解官方为此提供了几种预设值(min, small, default, max). 我们可以在安装启动前Shift+O来加上参数systemMediaSize=min,或者在安装介质的boot.cfg文件中的kernelopt=runweasel这行后面加上诸如systemMediaSize=min的参数,让此安装程序自动设置参数.

kernelopt=runweasel systemMediaSize=min

此时,安装好以后的硬盘空间大致情况如下图,系统空间占用大概是33GB.

ESXi on ARM v1.2 (2020年11月更新)

还是不支持更新,只能全新安装选择保留VMFS,然后重新注册虚拟机。我暂时先不更新了,changelog如下:

November 30, 2020 – v1.2 

Note: Upgrade is NOT possible, only fresh installation is supported. If you select “Preserve VMFS” option, you can re-register your existing Virtual Machines.

UI: Disable datastore browsing when no datastores are present

PSCI: Fix missing context_id argument for CPU_ON calls

GICv2: Always enable SGIs, as GIC-500

arm64: Support for big-endian guests

Remove requirements/restrictions on initrd for UEFI-less VMs

关于Fusion on Apple Silicon的谨慎猜测

苹果发布M1芯片的新Mac设备以后,许多用户想要PD或者Fusion运行在Apple Silicon上,并虚拟x86 windows(准确说是模拟)。

从PD的博客看到https://www.parallels.com/blogs/parallels-desktop-apple-silicon-mac/,模拟x86 windows并未在计划中。其中提到了在虚拟的windows on Arm中利用微软的支持来模拟运行x86 windows程序 https://blogs.windows.com/windowsexperience/2020/09/30/now-more-essential-than-ever-the-role-of-the-windows-pc-has-changed/

所以模拟x86 windows OS并未在PD的计划中,同理去模拟其它AMD64 Linux或者x86 macOS也不在计划。

而Fusion并未在博客或者官网中提到类似计划,只在官方twitter和论坛中有所提及会去支持Apple Silicon。

对此,我谨慎做些猜测:

  1. Fusion on Apple Silicon首先会以universal app形式支持Apple Silicon,并首先可以虚拟一些arm64的 Linux虚拟机,正如现在ESXi on Arm所支持的。这个应该不会很久。
  2. 虚拟windows on Arm也会类似PD一样,在微软提供类似授权和模拟运行x86 windows程序后去提供支持。
  3. 至于模拟x86 windows或者其他x86/AMD64系统,我觉得短期不可能实现,这个工作量不是一般的大。如果2做的好话,模拟x86 windows这个意义也没那么重要了。

欢迎PD和Fusion来打脸。