Windows Server(ESXi) 单臂(软)路由 + NAT 家庭多 VLAN 组网手记

imyz

一、概述

      这篇文章的目标是在网络层（第三层）为 IPv4 大框架下，通过充分利用 Windows Server 的 “NIC 组合 (NIC Teaming)” 功能提供的 VLAN 特性，将一台普通电脑（虚拟机亦可）模拟成企业级路由器，即：企业级 Windows 软路由，使得一般家用环境也能够实现多 VLAN 同时上网的治学需求。之所以标题强调 “单臂路由”，主要是考虑到普通电脑大概率存在有且仅有一个网口的场景，进而仅分配了一张虚拟网卡给 Windows Server 虚拟机来模拟该情形，并非表示该方案仅适用于单网口的场景，事实上多网口会更加灵活也更推荐。

      正如标题所示，本文的核心就是 Windows Server 的配置，因我日常所使用的家用服务器环境基于 ESXi 系统，所以文中所述 Windows Server 均指 ESXi 主机中的虚拟机。正因如此，ESXi 主机的虚拟交换机（vSwitch）与端口组（Port Group）的配置方法自然就成为我整体网络环境配置中不可或缺的一部分，于是顺手打包作为赠品。对于各看官而言，Windows Server 的载体既可是实体机，亦可为虚拟机，至于虚拟机环境是否采用 ESXi 则看各位自己熟悉或偏好哪一款，我只是指明方向，各位自行依葫芦画瓢即可，而各位 ESXi 大佬们可以直接无视后续 ESXi 配置的章节。测试环境拓朴图如下：



      上图实际上是用服役了 10 年退役的单网口服务器模拟 “单臂” 以及实体交换机为傻瓜式的场景，实测完全没有问题。不过现役服务器的主板是 4 网口，为节省实体交换机网口，我实际是直接将 Apple 时间胶囊路由器的 LAN 口出线直连我 ESXi Host 主板其中一网口，再为该网口新建了一台 vSwitch1 作为 WAN 专用。而图中标记为 “网关 (Gateway)” 那台即是标题中所说的 Windows Server 软路由，此处用 “网关” 只为示意，实际上这么称呼是不准确的，因为若图中的实体交换机（Switch）是 L3 三层交换机的话，则建议由 L3 交换机充当各 VLAN 的网关，而 Windows Server 软路由则仅保留 NAT 功能即可。细节将在下文解释，请先看拓朴图：



* 优点：

• 极大降低硬件需求与组网门槛；
• 省去企业级路由器专用硬件的购置成本；
• 能充分发挥 Windows AD、DHCP、DNS 等能力，在家即可实现中小企业才有的各项功能；
• Windows 图形化配置极大降低普通用户入门门槛。
  

* 缺点：

• 硬件稳定性（尤其 DIY）无法与企业级专用设备匹敌；
• 网络性能及带机量受硬件限制将因人而异，不好一概而论。
  

      上面所说的普通家用路由器就是指市面上最常见的家用路由器，它在本文中的用处纯为 PPPoE 拨号/DHCP 从电信运营商处获取可上网 IP（含 CGNAT 大内网），以及最基础的端口转发（Port Forwarding）即可。更有甚者，假如清楚 Windows Server 可被配置为像各种软路由那样 PPPoE 拨号上网的（普通 Windows 亦可），那么连家用路由器可一并省了，组网成本可进一步降低，若不清楚也没关系，虽然我个人并不推荐这样做，但下文还是会提到。

      针对交换机则稍有些讲究，虽然方案都适用，但不同类型的交换机将伴随相应的限制，关于细节将在下一章节细说。先来解释以下两个基础概念，以防刚接触或不太熟悉网络的看官有可能不清楚或混淆，若有谬误也请大佬们不吝指正：

• 路由：专业术语名词解释请大家自行查找。我简单地理解为 IP 包从起点到终点之间寻找路径的过程，其位于 ISO – OSI 网络模型的第三层（L3），凡可为 IP 包指路（配置路由）的设备均可被称作三层设备。要强调一下：能找到路（具路由能力）并不代表就可以直接访问 Internet 互联网（WAN），其仅仅是先决条件或者说必要条件之一，原因在于起点与终点分别代表什么并非路由所关心，就像邮差仅负责按地址准确投递而不必关心投递后有什么事将发生，往大了说，现实世界中的邮政、快递等就好比活体路由器…… 言归正传：局域网内部各 VLAN 之间互访这样的基础路由需求仅需一台 L3 交换机即可，但若没有路由器加持则仍然无法实现各 VLAN 同时上外网的需求，因为局域网 IP 地址并非合法的公网（WAN）地址，所以才需要以下这个路由器的特有功能：
  
• NAT：网络地址转换。虽唤作转换，可其实是指将某个网段的一个或多个 IP 地址与另一个网段的一个或多个 IP 地址之间建立映射/对应（Mapping）关系，让合法地址充当非法地址的代理来 “代冲 (浪)”，因此，所有的 NAT 工作时均存在一张 IP 地址映射表。基于此，我个人认为将其唤作 “映射” 更准确，它同样属 L3 功能，可以是 LAN 对 LAN，也可以是 LAN 对 WAN。NAT 这一功能系路由器专属（除 Cisco C65xx/6000 交换机这个极特殊的异类之外），普通家用路由器其实就专做 “单一 LAN 对 单一 WAN/LAN” 这一件事，而企业级的则能支持 “多 LAN 对 多 WAN/LAN” 以及其它更高级的路由协议/功能。
  

      清楚以上两个概念后，相信各位看官已大致明白了接下来的方向，简而言之就是标题中的 多 VLAN 间路由 + NAT。说起来虽简单，但实际操作过程中将会发现，这当中涉及到的知识点其实也不少，对不熟悉网络以及 Windows Server 的而言或多或少有一定的门槛，为尽可能节省篇幅，我个人认为属 “应知应会” 的基础内容则不着笔墨。另一方面，我写此文不仅仅只是让看官们 “抄作业”，难免其中会有大量说明、名词解释等稍显啰嗦的文字，其用意是尽可能让各位知其所以然。

二、软硬件清单

* 硬件：

• 普通家用路由器一台，品牌不限；
• 交换机一台（建议可管理的，有条件则 L3），端口数量据自身情况而定；
• AMD/Intel（x86_64 架构）PC 一台作 ESXi 服务器，品牌不限只要能安装 ESXi；
• 任意 PC/Mac 一台；一来管理 ESXi 服务器，二来本身可日常使用；
  

* 操作系统：

• ESXi 6/7/8 均可，我的环境是 8.0U3e；
• Windows Server，建议不低于 2012 R2，我的是 2025；
• 用于虚拟机与实体机之间结果验证的其它各操作系统不限；若有三台或以上实体机的可忽略此项；
  

* 操作系统所需功能或服务：

• NIC 组合（NIC Teaming）：创建虚拟 L3 交换机端口；
• 路由和远程访问：路由、NAT、DHCP Relay 等；
• DHCP Server：用于为多 VLAN 分配 IP，个人推荐 Windows Server 自带的；
• ESXi Host 虚拟交换机（vSwitch）及端口组（Port Group）各工作模式，即：EST、VST、VGT。
  

      若仅有一台 PC 或 Mac 的就不建议继续往下了，因为这套方案是为了解决多 VLAN 互访 + 上网需求，最适合两台或以上实体 PC/服务器 这类的使用场景。虽说仅一台并非完全没有可操作性，可那样大概率只剩下虚拟机与虚拟机互搏了。若是 PC 并且其配置还算不错，用我这套方案的话倒是可以用仅有的实体机安装 Windows Server，配置好各项后再利用其 Hyper-V 多开虚拟机来验证，可 Server OS 总归不方便日常使用，纯粹为了验证方案的可行性的倒还行，但没有太多实用价值（若日常便如此则当我没说）；而若是独一台 Mac 的话基本就劝退了，即使想做实验都得虚拟机套娃，先不谈可行与否，Intel 架构的也许勉强行，若是 Apple Silicon，貌似微软尚未推出 ARM64 版 Windows Server，至少眼下官方没有。

      上一章节说到不同的交换机类型有相应的限制，实际是针对实体交换机环境能否实现多 VLAN 而言，并不影响虚拟交换机环境。具体限制如下：

      1. 二层 (L2)，可细分以下两款：

• 1.1. 无管理能力：硬件不支持划分 VLAN，即俗称的 “傻瓜式交换机 (Dumb Switch)”。若家里交换机属此类，虽然并不影响在虚拟机环境中划分多 VLAN，并通过虚拟机 Windows Server 实现各虚拟机之间多 VLAN 路由 + NAT 上外网，可但是，实体机因受硬件不支持多 VLAN 所限，不要指望虚拟机能助你突破 “物理限制”，仍只能维持与实体家用路由器处同一 LAN 网段的状况。
• 1.2. 具管理能力：硬件支持划分 VLAN。若家里交换机属此类，则实体机与虚拟机均可实现多 VLAN，并且各 VLAN 之间相互通讯（LAN 路由）以及上外网，均可由 Windows Server 配置单臂路由 + NAT 来实现。
  

      2. 三层 (L3)，支持 VLAN + 基础路由：

• 家里若有 L3 交换机，则实体机与虚拟机多 VLAN 之间相互通讯（路由）可交由三层交换机完成，而 Windows Server 则可专注 NAT 这一件事，如此可减轻 Windows Server 的负荷从而使得上外网更轻松，或者说 “带机量” 可更大。
  

      注：以上 Windows Server 处未注明 “虚拟机” 的表示也可以采用实体机。用下表形式展示也许更加直观，也可更清楚地看到各类设备之间的差异或者说 “分工”：



      假如对以上这些概念不熟悉或者看不明白的也没关系，请带上问题读完以下内容，若有条件的再实际操作一次之后，然后回头再来看，相信多少也会有些收获。

imyz

      既然标题写单臂路由，本章节中凡未特别注明的均默认 Windows Server 有且仅有一块网卡，与此同时，凡未对 Windows Server 版本作特别交待的，均默认为我示例所使用的 Windows Server 2025 版，其它版本的均大同小异。这一章节只做以下两件事：

• 充分利用 Windows Server NIC 组合 所提供的功能，在唯一的网卡基础上虚拟出多个 “组接口 (Team Interface)”，相当于将 Windows Server 配置为一台多网口 L3 交换机，也可以理解为配置/创建路由器接口的子接口（Sub-interface）；
• 安装并启动 “路由和远程访问” 服务，在以上 1 的基础上为 Windows Server 添加 NAT 服务以最终实现本文目标。
  

• 严格上讲，要实现以上两点还有个前提：须将 Windows Server 虚拟机网卡所连接的虚拟交换机端口配置为 “中继（Trunk）模式”，不仅如此，包括 ESXi 实体机连接的实体交换机（傻瓜式的可无视）相应的端口也得是 Trunk 模式，下文附赠的 ESXi 那章会有详解，若是实体机安装 Windows Server 的，则相应实体交换机的端口亦须如此。
  

      首先讲 NIC 组合。网上也能找到不少介绍该功能的文章，但尽数是讲如何用它来实现多网卡的合并/扩展带宽、负载均衡等，即：如何创建组。而我这篇文章所要做的是在创建完组的基础之上再将其 “拆分”，可以说 “反其道而行之”，而创建 NIC 组合并不限制单网口，所以标题不含一丝水分。基本的配置过程相对简单，按下图所示操作即可。对于新安装的 Windows Server，服务器管理器是默认在启动时打开的，仅需如下图点击界面左侧竖排菜单中的 “本地服务器”，图中红色箭头所指的 “已禁用” 处便是 NIC 组合的配置入口：




      要创建/添加组，如下图点击 “任务 –  新建组(N)”，然后为新组命名，展开下方 “其它属性(A)” 并确定适当的负载平衡模式后即可完成组的创建，而组的名称建议选择自己好记的，尤其当有多个组时便于区分。在某些情况下，负载平衡模式采用默认的 “动态” 有可能导致创建组失败，这时可以尝试将其改为 “地址哈希”，等完成创建后可以再根据需要自行调整模式。




      上图中红线标注的那个 “主要” 一列显示为 “是” 且 VLAN 列为 “默认值” 的那个唤作 “主组接口 (Primary Team Interface)”，每个组有且仅有一个，其余的均为 “组接口 (Team Interface)”，也就是说，若为 10 个网口分别创建 5 个组则相应有 5 个 主组接口，也只有 主组接口 才可更改其 VID 为上图所示的 “默认值”，而其余的则不行。可是，主组接口 的 “默认值” 该如何理解呢？我先给结论：默认值 = Untagged，可简单地理解它就是普通电脑网口，你以为这不就是废话吗？！可没你想得那么简单！！！一眼秒懂的网络工程师们大可以跳过以下几段斜粗体字内容，而对于仍不明就里的则请接着往下看，即使是看不懂也不必担心，抄作业总会吧：

      Untagged 一词涉及 “VLAN 标签” 这个基础网络知识。以大家较常用的微信为例：当你向群、好友发送各种消息时，该消息首先要通过你的电脑网口发送给交换机、再发送给路由器，最终发往 ISP 才能上到互联网，该过程很容易理解，可是对计算网络而言却完全不知所云！原因是因为计算机网络采用了另一套语言，而我并非网络专家并且限于篇幅这里只讲个大概：微信消息首先要先经过应用层协议（HTTP, FTP, DNS, SSL）将消息封装（Encapsulate）为相应的应用层数据（Data），随后再用 L4 传输层协议进一步将其封装成 TCP – 数据段（Segment）或 UDP – 数据报（Datagram），紧接着再用 L3 网络层 IP 协议封装为数据包（Packet），别急还没完，然后再采用 L2 数据链路层协议（IEEE 802.2, PPTP, L2TP, ATM, PPPoE 等）继续封装成可用于传输的数据帧（Frame），最后通过物理设备以比特位（bit）方式在物理线路中传输，我们常说的网络传输速率 “比特率，单位 bits/second (b/s, bps)” 中的比特就是这个比特位。事实上，微信消息在网络中各个设备之间所传输的实际上都是各类的 “数据帧”。很显然，L2 帧是包含了上述 L3 包的全部内容，更专业的说法应当是：“包” 作为 “帧” 的有效载荷（Payload），其好比导弹中的战斗部 —— 然而这并不是我们要讲的重点，重点是介于你电脑与路由器之间这段局域网（LAN）这部分是如何识别和处理这些封装后的消息的，而要想说清楚这件事得细分两部分来讲，现在请先忘掉微信这回事。

      先说其中之一的局域网终端设备，如：PC/Mac、打印机（Printer）等，它们之所以被称作 “终端” 概因其在网络世界中所扮演的角色为各类消息的生产者与/或消费者（Producer and/or Consumer）。这类设备相互之间通讯的主流协议即大家耳熟能详的 “以太网协议 (Ethernet Protocol)”，更准确地说是 Ethernet V2 或 Ethernet Ⅱ。该协议起源于更早的 Xerox 制定的一套标准，随后在 1980 年由 DEC、Intel 及 Xerox 共同将其标准化为 Ethernet V1，其改进版 V2 于 1982 发布，在那个年代是完全没有 VLAN 这一概念的，甚至连最早的傻瓜式交换机也是 1989 年才出现，而那个年代只有集线器（HUB）这类除了广播啥也不会的物件，很显然：

• 知识点一：咱们局域网所用的电脑这类终端相互通讯的 “语言”，即：数据帧，其默认是没有 VLAN 概念的，业内称之为 “无 VLAN 标签”，英文记作 Untagged —— 网络终端设备处理与识别网络消息即是依靠这套语言。
  

      随着互联网不断发展，越来越多的终端以及网络产品不断出现，局域网也变得越来越庞大复杂，同时对网络传输速率的要求也与日俱增，随之而来便是对 VLAN 的需求等，因越来越多厂商群雄逐鹿而当时标准不统一导致了各厂家设备在兼容方面的问题，于是 IEEE 又在当时已成为事实上终端设备标准的 Ethernet V2 的基础之上进行了扩充与改良，并于 1983 年发布了不一定各位都熟悉的 IEEE 802.3 以太网标准，它更多地为人所知的应该是该标准当中的物理传输介质标准部分，即：10BASE-T，或记作 10Mbps 以太网标准，随后便是 802.3u 100Mbps 与 802.3z 1000Mbps（1GbE）以太网标准分别于 1995 年及 1998 年发布。而作为对 VLAN 这一需求的响应，IEEE 802.1q 标准也于 1998 同年发布，其为以太网帧帧头部分引入了一个唤作 VLAN 标签的标记，共 4 Bytes(字节)，用于识别与区分网络中的不同虚拟网段（VLAN）。而正是因为 IEEE 这一系列标准，才逐步确立了除上述第一部分中的终端设备之外的第二部分的各类网络设备，即：交换机、路由器以及防火墙这类网络传输与管理设备的数据与接口等标准。这类设备在网络世界当中充当的角色主要有两个：一是连接各终端设备，并作为承载与传输数据帧的物理介质或载体，二是对数据帧（L2）以及数据包（L3）实施相应的管理。

• 知识点二：有 IEEE 802.1q 标准加持的以太网帧意即 “带 VLAN 标签”，英文记作 Tagged，与 Untagged 相对应；而 IEEE 802.1q（VLAN 标签）作为 IEEE 802.3 的 “外挂” 存在。
• 知识点三：VLAN 标签中有个位长 12-bit（12 位）的 VID 字段用于区分该数据帧归属于哪个 VLAN 段，而这个 VID 的值直接对应了上图中组接口 VLAN ID 的取值。于是：
• 知识点四：2^12 = 4096，即：VID 理论最大取值范围为 0 ~ 4095，采用十六进制则为 0x 000 ~ FFF，但 IEEE 802.1q 将首尾的 0 与 4095 作为保留值，而这也就是为什么大家在各类交换机产品中所见，可用的（或合法的） VLAN ID 取值在 1 ~ 4094 之间的根源。
• 知识点五：IEEE 802.3 与 Ethernet V2 虽有关联但其实是两个标准，而在 IEEE 802.3 出现前 Ethernet V2 已然是当时各终端设备的事实标准了，也没有理由或者说没办法为了新标准而将当时全球所有现存电脑、网卡、打印机等尽数报废，与此同时，网络终端设备压根不必具备 VLAN 功能徒增成本，正因如此，咱们的电脑这类终端得以一直沿用 Untagged 乡音至今，而 802.3 则负责规范其物理传输介质。那么究竟是谁在讲 Tagged 标准普通话呐？自然就非得是交换机、路由器、防火墙这类设备莫属，很显然：“傻瓜” 是学不会标准普通话的…… 经这样解释后，是不是对上一章结尾的功能表格有了更深刻的理解？
  

      现在已知局域网（LAN）中存在 Untagged + Tagged 这两种标准的数据帧，那么作为本文重点之一的交换机是如何处理这些数据帧的呢？相信大家都知道交换机的核心工作就两件事：接收 + 转发数据帧，而其余的均围绕这两件事展开，由于傻瓜式交换机没太多可说的，所以此处重点针对具备管理能力的交换机介绍其在 VLAN 配置方面大家日常会接触到的：这类交换机物理端口区分 Access（访问/接入） 和 Trunk（中继/汇聚） 两种基本工作模式，前者 Access 仅用于连接电脑、打印机这类只会讲 Untagged 乡音的终端，虽然可以变更其 VLAN 归属，但一个 Access 端口在同一时刻仅能划归某一个 VLAN 而不能多个，这类端口除了纯粹 “拆/打 VLAN 标签” 之外没有过多好展开讲的；然而后者 Trunk 端口则稍有些不同，从其设计目的上讲是为了级联交换机、路由器以及防火墙这类会讲 Tagged 标准普通话的网络管理设备，但也许是为了向下兼容的缘故，Trunk 端口同时还能接电脑、打印机这类传统终端。有容乃大本是件好事，可这也带来了一个问题：说好的标签呢？要不得说设计师就是聪明，以 Cisco 交换机为例，不就是让 Trunk 口加个班处理标签嘛，就给它安排个缺省值为 1 的 Native VLAN（本征/原生 VLAN）专干这活，多大事儿！简单说就是：若 Trunk 端口接收到外部发来 Untagged 帧，首先为其打上 VID = Native VLAN ID 标签，而若是 Tagged 则读取帧头 VID，此处统称 VID，接着执行接收规则：若该 Trunk 端口允许通过的 VLAN 范围包含该 VID 值，则放行该帧进入交换机，否则丢弃；随后将执行转发规则：先看该帧的目标 MAC（网卡物理地址）是否在本机学习清单中，若在则将该帧转发（复制）给相应的端口，否则泛洪（广播）给所有 VID 所指的那些 Access 端口，也包括 Trunk 端口，在转发过程中，若负责送行的端口恰好又是 Trunk 口，并且该帧 VID 与 Native VLAN ID 相等，在缺省情况下则拆掉标签令该帧成为 Untagged，同时也得判断 VID 是否在该 Trunk 口允许的 VLAN 范围，允许的才能离开，否则丢弃。为什么我要在这里和各位聊这个？还请各位带上这个疑问继续往下看：

      还记得前面说须将 Windows Server 网卡所连接的交换机端口配置为 Trunk 这一点吧？以 Cisco为例，假设我们采用 “switchport trunk native vlan 100” 指令将该交换机该 Trunk 端口的 Native VLAN 由原缺省值 1 改为 100，则该端口会将后续所有进入之前为 Untagged 的数据帧由原 VLAN 1 转至 VLAN 100。看明白了吗？不论如何修改 Trunk 端口的 Native VLAN 值，即使是在进入交换机之前原为 Untagged 的帧在被接收进入交换机后也悉数变为 Tagged，与进入之前已是 Tagged 的区别在于前者只会进入 Native VLAN，而后者则进入其 VID 指定的 VLAN，在随后转发时也有不同：Native VLAN 当中的帧在被转发离开交换机时（仅缺省情况下）将会被恢复为其 Untagged 真身 —— 简单地讲：在缺省情况下，假设一台交换机所有端口均配置为 Trunk，凡能够顺利通过该交换机的数据帧均保持其原状，而这也可能就是 “中继” 一词的来历吧？…… 如此一来，Cisco 交换机的 Native VLAN 与上面那个 主组接口 这二者便因此相互 “自适应” 或者说 “无师自通” 了。如此一番解释，相信各位应当能彻底理解上面那个 主组接口 的 “默认值” 其真实含义及其在现实世界中的作用了吧？要验证这一点很容易，只需将该 主组接口 的 IP 地址改为自动获取，再配置好 DHCP Relay（DHCP 中继代理）指向 DHCP 服务器，然后先禁用再启用该 主组接口（或使用 “ipconfig /renew” 指令）再观察其 IP 地址的前后变化。如此便带来了一个便利：假如和我一样采用 DHCP 为各组接口分配 IP 的话，因为上述 “自适应” 的缘故，修改实体交换机 Trunk 接口的 Native VLAN 可不必修改 Windows Server 中相应配置，而仅需禁用再启用一下相应 主组接口，或者重启一下 Windows Server 即可。

      然而，出于网络安全方面的考虑，实际情况有可能是一部分的 Cisco 交换机通过 “vlan dot1q tag native” 指令显式地禁止为即将离开 Native VLAN 的帧拆标签，而这时若不将相应 主组接口 的 VLAN ID 手工填写为相对应的值，则有可能因此造成网络不通甚至瘫痪。好在该指令须显式配置，一旦禁拆标签指令生效，修改实体交换机 Trunk 接口的 Native VLAN 须同步修改 Windows Server 中相应 主组接口 的 VLAN ID = Native VLAN ID。这一点十分重要！从另一角度看，既然如今 Native VLAN 和其余的似乎没差别了，索性转而为 Native VLAN 创建相对应的组接口，或者原本就没有需要使用 Native VLAN 的场景，也大可将其视作普通组接口也没任何问题，甚至令 主组接口 闲置或禁用之进而省去操这份心也不是不行。

• 知识点六：数据帧不论其初始为 Untagged 或 Tagged，在进入具备管理能力的交换机内部后则悉数变为 Tagged，而在离开交换机时则得分具体情况；而傻瓜式的则完全不嚼也不消化，吃啥拉啥。
  

      与上述 Native VLAN 相对应的，华为系设备则称之为 PVID（即：端口 VID），上面 Cisco 那条禁拆 Native VLAN 标签的指令是在全局模式中一条过而不必针对各 Trunk 端口，而华为的稍有不同，因其本身还细分 Trunk 和 Hybrid 两种端口工作模式，在配置时也是针对各个相应的端口而并非全局指令。若是 Hybrid 端口，则对应的等价指令为 “port hybrid tagged vlan 100”，而 Trunk 端口的等价指令按理应当为 “port trunk tagged vlan 100”，可遗憾的是，貌似并没有这条指令，所以我猜测它的工作方式与 Cisco 缺省方式应当是一样的，然而我本身对华为系的产品没那么熟悉，并且手上也没有任何实物可验证，若我的猜测有误，也请熟悉华为系产品的大佬们不吝指正！所以我在此只好建议：若使用华为系交换机的 Trunk 接口，要么请务必修改 主组接口 的 VLAN ID = PVID，要么请完全闲置或禁用之。

• 知识点七：Native VLAN ID（或 PVID）是交换机 Trunk 端口属性之一，请勿与属于数据帧的 VID 混淆。
• 知识点八：当有诸如 “vlan dot1q tag native“ 这类指令显式地禁止 Trunk 端口拆 Native VLAN 标签时，Trunk 端口仅能用于级联（Uplink）交换机、路由器、防火墙等网络管理设备；否则，它也可以接普通电脑、打印机等终端设备。
• 知识点九：同一台交换机不同 Trunk 端口的 Native VLAN 其取值可各不相同，这样的配置仅影响接入设备为电脑、打印机这类终端，并可由该取值确定这类终端各自所处的 VLAN 段是否相同，或者说其 L3 网络层的 IP 地址段是否处于相同的广播域，而其余无任何差别。这就好比家里两台电视可以分别收看不同的电视频道，而 Native VLAN ID 则相当于电视机当前所收看的频道号。
• 知识点十：傻瓜式交换机 “吃啥拉啥” 的本质是因其不支持开挂（802.1q）从而无法识别与处理 VLAN 标签，它的各端口没有 Native VLAN ID 属性或其为任意值（下一章 ESXi 的内容对此有详细解释），或者可视其为普通电脑网口…… 简单地说，通常可认为 2000 年以后的现代家用网卡，不论哪家的芯片方案，均硬件支持 VLAN，而早期网卡则有可能硬件不支持 —— 而这一点包括以上也是本文可以采用普通家用电脑/网卡搭配傻瓜式交换机实现多 VLAN “单臂路由” 的理论基础。
  

      在具备了以上基础网络知识之后，相信后续的配置对各看官而言可谓易如反掌。紧接着再如下图所示继续为其它 VLAN 创建相应的组接口（Team Interface），并重复该过程直至覆盖所有需要用到的 VLAN：


      这里需要提醒注意：下图中 “特定 VLAN(V)” 处填写的数值实际就是指数据帧帧头中的 VID 值，显然此处它表明该 VLAN 当中将要通过哪个 VLAN 的数据帧，其自然须与实体交换机中的 VLAN 定义相匹配，不但如此，ESXi（或其它虚拟环境）的虚拟交换机的各端口组的 VLAN ID 也得与该值以及实体交换机的定义相匹配：



      组接口创建完成后，可如下图所示打开控制面板中的网络连接查看所有创建好的组接口。一旦该网络适配器（网卡）被添加进 NIC 组后便不可再为其分配 IP 地址，应当转而为各个组接口分配。这属于正常情况，千万不要误以为是 NIC 组的配置过程有误而导致网卡配置出了问题。





      接下来就得为每一个新创建的 VLAN 组接口分配 IP 地址作为该 VLAN 的网关，通常情况下，多数人可能会选择手动分配，而我自己更偏好 DHCP 自动分配。采用 DHCP 的好处在于：组接口创建完成便立即获取保留的 IP，不但如此，整个网络中的所有 IP 地址悉数可由 DHCP 服务器托管，再配合 DNS 主机名称（A 记录）进行内网解析，则整个网络最核心的管理与规划工作就可集中式地在 DHCP 与 DNS 服务器上完成，加上 Windows Server 的图形化界面比通过终端指令方式更人性化，完全不必担心时间一长有可能记不住这么多设备的 IP 地址设置，并且也可以用较容易记住的主机名称替代难记的 IP 地址来访问各设备，对 Mac 与 Linux 也同样适用，比如下图就是我 Mac mini 的 Terminal 通过主机名来 SSH 连接配置 Cisco 交换机的示例，简单讲就是 “懂的都懂”，而考虑到其并非本文的重点，限于篇幅便不展开，若确有必要我可以单独开个帖细说。


注意：因为组接口（Team Interface）眼下作为局域网网关，其网关地址即自身，所以仅须设置 IP 及掩码（mask）即可，完全不必费劲为其设置网关地址！！只有当需要访问 Internet 时，才需要为其对应的那一个组接口设置网关地址。比如我上图中仅为 “HomeLab – WAN” 那个组接口设置了网关地址，也就是我 Apple Time Capsule（时间胶囊，以下简称 “ATC”）的 LAN 地址。而这一切都可以通过配置 DHCP 实现，也是我偏好 DHCP 自动分配的重要原因之一。

      至此，各 VLAN 段中不论是实体机还是虚拟机现在只须将各自 IP 地址配置中的 “网关 (Gateway)” 设置为 Windows Server 中相应 VLAN 组接口的 IP 地址，则所有 VLAN 之间就应当能正常互访了，即：实现了内网间路由（LAN 路由）。换个角度来看，若想临时隔离某个 VLAN 段，仅须在 Windows Server 网络连接中禁用相应的组接口即可。虽然内网已畅通无阻，但各新建的 VLAN 却仍然无法访问互联网，因为还缺少接下来准备讲的 “路由和远程访问” 配置，而该功能的安装很简单，按下图所示操作即可。假如有熟悉 Windows 软路由配置并且同样是 ESXi 大佬的话，则可以跳过接下来的内容并直接着手实践了。

      请注意：我上图中的 “HomeLab – WAN” 那个组接口实际上是对应家用路由器 LAN 口，该网段可直接访问互联网 Internet，所以它的名称中有 “WAN”，而这一点是接下来能否实现内网其余各 VLAN 段共同访问互联网的必要先决条件。换句话说：首先得确保至少有一个能访问互联网的地址，哪怕它是 CGNAT 大内网地址。对于 Windows Server 本身是多网卡的而言，只需从家用路由器任一 LAN 口引一条网线直连其中任一网口即可，但这样就至少是双臂而不再是 “单臂”。而标题所说的 “单臂” 要如何实现则需要详见后续附送的 ESXi 相应配置（因我的环境是 ESXi 虚拟机），不过眼下可先忽略这一细节，待完成 Windows Server 所必须的配置之后再进入 ESXi 章节并不会耽误任何事：




      待安装完成后，便可如下图所示启动路由管理界面：


      进入路由和远程访问管理界面后，鼠标右键点击相应的服务器名称，随即如下图所示点击 “配置并启用路由和远程访问(C)”，接着再按图示完成 NAT 的配置：




      选择局域网接口这一步可任选其一，因为这里并非最终配置，在启用 NAT 协议之后可按自己的需求进一步调整：



      启用了 NAT 协议后的界面将如下图所示。除其中那个 WAN 接口需要保留之外，其余内网 VLAN 接口可以根据自己的需要决定保留或删除。建议是尽数删除，因为除了可访问 Internet 那个接口之外的其余接口均为摆设。



      一旦上述各项配置正确无误，不论是实体机还是虚拟机，现在仅须将各自 IP 地址设置中的 “网关 (Gateway)” 填写为 Windows Server 中相应 VLAN 组接口的 IP 地址，则所有 VLAN 除能实现内网之间互访之外，还能进一步访问互联网。但还差一项很重要的功能：NAT–PMP（端口映射/转发），请接着往下看：




      以上图为例，假如你家的宽带是有动态公网地址的，经过以上配置后就能够从任何可以上网的地方访问家里 192.168.100.100 那台开启了远程桌面的电脑了，若不行则请检查家里链路中相应的防火墙设置以及动态 DNS 解析。针对该 NAT–PMP 配置，即使你是采用 Windows Server 直连光猫获取上网地址的情况也是一样配置，而通常情况应当是家用路由器本身先配置好端口转发到 Windows Server 的那个 WAN 接口地址，然后再由 Windows Server 最终转发内网，即：二次转发。比如下图便是我通过配置 Windows Server NAT 二次转发后，从外部经 Internet 公网访问我家中那台妖擎的 IPMI 管理页，这里只是作展示，用以说明二次转发是成功的，而若有和我一样主板有类似 IPMI 远控能力的，尤其是我的 Windows Server 就是那台妖擎上的虚拟机，建议还是一次转发避免二次甚至多次，否则一旦实体机发生问题后必然影响虚拟机，到时即便 IPMI 本身能正常工作，可一旦 NAT 断掉也只能干瞪眼，而其它诸如远程桌面（RDP）这种转发几次问题都不大。


      就事论事地说，Windows Server 这个端口转发功能也有局限，比如：它目前只能逐个端口配置，而不支持一般家用路由器所支持的一次配置某个端口段，若有这类需求的得借助第三方软件，再或者，直接将该主机置于家用路由器相同的那个网段也不是不行。与此同时，当添加、修改任一端口服务应用时，Windows Server 将清除 NAT 映射表再新建，换句话说，会瞬时断网，假如有对此敏感的应用时得谨慎操作，或者提前规划好一次过完成配置。此外，除上述图形界面配置方式外，Windows Server 的端口转发还可以通过命令行的方式，该方式较适合有大量转发需求的场景，如此可以写好批处理脚本一次执行即可，也方便后续的调整变更等。而这一点也不是本文重点，我也没花时间测试过，详情还请自行参阅微软官方文档：Netsh interface portproxy 命令。

      至此，Windows Server 这部分的配置已全部完成，而以上各个 VLAN 组接口也可用于 Hyper-V 虚拟机，同样不属本文讨论范围。若是熟悉 Hyper-V 解决方案的看官们，相信完全可以采用该方案来自己组纯血 Windows 网了。假如有 L3 实体交换机的，则建议将 PC / Mac 的网关设置为 L3 交换机的 VLAN 接口 IP，以便让 Windows Server 软路由专注 NAT 来进一步减轻负担。顺手再给几个友情提示：

• 若有和我一样采用 ESXi 虚拟机方案的，则务必将 Windows Server 虚拟机配置为随 ESXi 主机开机自启动（Autostart），可在 “管理 -> 自动启动” 中设置；假如还有人与我一样采取 DHCP 的，则软路由的自启动优先级要低于 DHCP Server 那台虚拟机，即：晚于 DHCP Server 启动。否则可能因获取不到 IP 造成断网进而被迫人工干预；
• 以上 Windows Server 为各 VLAN 创建组接口的方式其实只是实现方式之一，若有 L3 交换机并且熟悉路由器配置的大佬们其实不必为每个 VLAN 分别创建组接口，而可以采用配置静态路由方式来实现。虽然最终效果是一样的，可一来 L3 交换机对多数人而言并非刚须，二来配置静态路由对不熟悉路由配置的看官们十分不友好，所以这一方式也不在这里展开讨论了。
• 也许会有和我一样仍然在坚持使用 ATC 作家庭网关拨号上网，并且恰好也是用它作为 Time Machine 备份磁盘的 Mac 用户。在以上的组网方案之下，对 Windows Server 这个 “网关” 而言，ATC 显然已处于 “公网” 网段而 Mac 则处于内网，如此便导致 Bonjour 协议找不到 ATC 从而造成 Time Machine 无法正常工作。显然，最简单粗暴的解决办法就是用其它路由器替换下 ATC，然后将 ATC 移回内网。但若那样做便糟蹋了 ATC 强大的路由器功能，并且靠纯花钱这种事完全没技术含量，还容易招人笑话，所以我的办法如下图所示，采用 ATC 的 IP 地址并通过 AFP (Apple File Protocol) 协议来取代 Bonjour 查找，点击 “连接” 按钮后输入 ATC 的访问密码即可，若有配置了内网 DNS 解析的则可以和我一样用主机名称取代 IP。若是之前已有旧备份的，打开 macOS 设置 -> 时间机器，先删除此前的磁盘配置，然后重新添加磁盘，这时会弹出对话框，选择 “保留旧备份” 后，输入访问 + 磁盘密码双双验证通过后即可。
  

      请再容我多句嘴：前面提到过可以配置 Windows Server 请求拨号接口（PPPoE）来取代家用路由器，而它实际上与上文中 “HomeLab – WAN” 组接口起到的作用一样。不过，我不太推荐各位这样做，并且也不是本文的重点，我在此仅指个路，余下还请有雅兴的看官们自行尝试：








      接下来将进入 “赠品” 环节。

imyz

      这一章节本质上只做一件事：正确地配置 ESXi 的虚拟交换机（vSwitch）。说起来挺简单的一件事，可在我彻底理解它之前却为此耗费了不少时间和脑细胞，并且回顾过往才发现此前还走了一些无谓的弯路，甚至还进入了认知上的误区而不自知。所以在进入正题之前，我会用大量通俗易懂的文字解释重点概念，以免各位像我刚开始那样踩坑，或者说尽量让各位有机会 “弯道超车”。

      据官方文档记载，ESXi 的 vSwitch 有且仅有 EST、VST 及 VGT 三种工作/配置模式。之所以将这一点 “置顶” 来讲，是因为这三种模式可以说囊括了 vSwitch 所提供服务的全部内容，而其余关于 vSwitch 的理论知识、技术实现等无一例外是为实现这三者，或者说围绕其展开。于普通用户而言，只须牢记并熟练运用这三者便足以满足日常乃至高级之需，一旦弄清其背后的原理及相互间的关系则自然就融会贯通。官方描述大意如下：

• EST = External Switch Tagging：数据帧帧头 VLAN 标签中的 VID 由外部实体交换机标记，官方规定 ESXi 主机网卡所连接的实体交换机的端口须配置为 “Access – 访问/接入” 模式，同时规定相应 vSwitch 中相应端口组（Port Group）的 VLAN ID 值须设置为 0。
  
• VST = Virtual Switch Tagging：数据帧帧头 VLAN 标签中的 VID 由其相应的 vSwitch 标记，官方规定连接 ESXi 主机的外部实体交换机相应的物理端口须配置为 Trunk 模式，同时规定相应 vSwitch 中相应端口组（Port Group）的 VLAN ID 值须设置为 1 ~ 4094。
  
• VGT = Virtual Guest Tagging：数据帧帧头 VLAN 标签中的 VID 由其中某一台或多台虚拟机标记，条件是该虚拟机得安装 802.1q VLAN Trunking 驱动，官方规定连接 ESXi 主机的外部实体交换机相应的物理端口须配置为 Trunk 模式，同时规定这类给数据帧打标签的虚拟机所在的端口组须配置为 trunk 模式，同时须设置其 VLAN ID = 4095。
• （笔者注：很显然，用于给数据帧打 VLAN 标签的那类虚拟机则等价为具备管理能力的虚拟 L2 交换机。而那个官方原文中的 “an 802.1Q VLAN trunking driver” 这个驱动究竟指的是个啥？请带上该问题继续往下看。）
  

      为更加有助于各位理解，我首先用我自己配置完成的 vSwitch 的拓朴图来切入正题：


      明眼人一眼便能看出，上图中是一台配置为 “单臂” 的 ESXi 主机，因为 vSwitch 右侧显示有且仅有一张物理网卡。请各位暂不要急于往下翻答案，先尝试用你自己读完官方文档后的理解来回答以下提问：

      上图中的 vSwitch 究竟工作在 EST、VST、VGT 中的哪种模式？

      对于初次接触这几个概念的看官们而言，大概率在读完官方文档之后会与我当初刚接触 vSwitch 时是一样的不知所云的状态，原因在于，你以为官方文档在讲 vSwitch，而它却更多地却是在讲连接 ESXi 主机的实体交换机工作在哪种模式，包括 官方给出的示例指令 也是 Cisco 实体交换机的配置…… 正因如此，对于还没彻底理解 vSwitch 的必然先入为主地认为 EST、VST 或 VGT 应当是 vSwitch 的配置方式或工作模式。此外，网上能搜到的各种 vSwitch 解析甚至 “精讲” 等文章，在我真正理解了 ESXi 的 vSwitch 工作方式之后，感觉网上那些文章包括官方文档在内都好比 FPS 游戏当中的 “描边大师” 之流，理论非常扎实与全面但总之就讲不到点上，读完不但仍然似懂非懂，甚至误入歧途以致走火入魔我都不觉惊讶…… 我初次接触 vSwitch 还是 ESXi 6.5 刚出那时，因为自身没有多 VLAN 的需求，再加上受硬件条件所限而无法进行实测，所以当时压根儿连配置 vSwitch 的想法都没有，安装好 ESXi 之后都是默认配置就上线，因为那阵子运行在 ESXi 中的各虚拟机才是我的全部，ESXi 纯作个载体而已。这一状况直到一年多前才有了变化，那时因机缘突然就萌生了多 VLAN 的需求，于是配置 vSwitch 就成了迈不过去的坎，而上面那个问题自那时起便一直萦绕在我脑中挥之不去，也许是我天生资质愚钝、悟性太差，再加上当时没有装备来实测，以致于网上找来各路大神们的深度讲解读完后依然百思不得其解…… 可我此前却从来没有去质疑过上面那个命题（提问）本身是否有什么问题，也就是常说的：没有尝试打破陈规（Think out of the box）。那么请再来看以下这个提问：

      上图中的 vSwitch 究竟启用了 EST、VST、VGT 中的哪几种模式？

      前后两个提问一对比就不难发现，第一个提问似乎在暗示其中那三种模式是对于拓朴图右侧那张物理网卡（vmnic0）而言，因为数据帧全都流经它，并且官方文档在解释三种模式时也全程在讲数据帧是如何被处理的，于是难免会让人先入为主地认为：对同一张网卡而言似乎没办法同时工作于一种以上的模式，那么 EST、VST、VGT 三者之间默认有互斥关系…… 现在第二个提问似乎打破了这个 “暗示 (或者不如说是误导)”，那么请再看以下我加了标注说明之后的拓朴图：


      以下便是我个人在彻底理解了 ESXi vSwitch 的工作原理之后作出的总结或者说个人理解：

• EST、VST、VGT 事实上是端口组（Port Group）的属性，好比 Access、Trunk 之于实体交换机的物理端口，尽管从官方角度上讲其归根结底还是 vSwitch 整体的特性这一点也没错，可从用户或者说初学者角度看却并不能说十分准确；
• 一个 Port Group 即对应一个 VLAN 段，用于连接一个或多个虚拟机，而这也是它被称作端口组的原因；
• Port Group 等价于实体交换机的某个或某一批物理端口，而虚拟机则通过 Port Group 与 vSwitch 交换信息；
• 结合以上 1, 2, 3 不难理解：既然 EST、VST、VGT 实际上是 Port Group 的属性，虽然某一个 Port Group 在某一时刻仅可工作于某一种（“三选一”）模式，但对于 vSwitch 或者说对于 ESXi 主机中的不同 Port Group 而言，这三种模式并非互斥或排他，而是如上图所示可和协共存 —— 哪怕有且仅有一个网口；
• Port Group 作为虚拟交换机的端口组，它本身为 L2 即二层属性，就是说包括 Management Network 在内的 Port Groups 与实体 L2 交换机的端口一样是不具备 IP 地址的，而管理 ESXi 主机的 IP 地址是 VMKernel NIC，即：L3 管理内核接口（vmk0）的属性，千万不要误以为那是 Management Network 管理组的 IP 地址。或者反过来讲，具备 IP 地址的端口便不再是 “交换端口” 而是 “路由端口”，以 Cisco 三层交换机为例，欲为某端口分配 IP 将其配置为路由端口，则首先得使用 no switchport 指令禁用该端口的交换属性；
• 一台全新安装完成未作任何配置的 ESXi 主机，其自带的 “Management Network” 及 “VM Network” 两个端口组的 VID 值均默认为 0，即：二者默认均处于 EST 模式；
• 为进一步解释三种模式如何处理数据帧，以及与实体交换机端口之间的相互关系等，请看以下表格：
  

      由此可见，EST 模式的 Port Group 允许且仅允许数据帧保持 Untagged 形态通过这一特性，与将硬件不支持 VLAN 的物理网口直通给虚拟机是一样的效果，二者的差异在于：直通网口中的数据帧跳过了 vSwitch 交换机软件层而直接交由硬件处理，在效率层面好比影视剧的视频流的解码（Video Decoding）属于硬解（H/W）还是软解（S/W），也正是这个原因，全新安装的 ESXi 主机在默认无修改的情况下（即：EST）无论接哪种交换机、甚至直接连接电脑都能顺利访问其 vmnic 虚拟网口并对 ESXi 主机进行管理；于是我不禁又想：不如直呼 EST 作 “直通模式”？可是如今普通家庭网卡一早都支持 VLAN 透传了，若不加任何限定地说直通那它实际却是傻瓜式交换机端口或 VGT 模式，这显然也不对…… 那么结论就很明显了：作为过来人严格地讲，EST 并非交换机的任何一种工作模式，而同时作为曾经的受害者的我就忍不住想说：官方将 EST 归为 vSwitch 属性之一，虽然原则上也没大错，可一旦搞清了它的真面目后，其相较于实体交换机而言就总感觉有些不伦不类，尤其容易让初学者误入歧途！至于 VST 与 VGT，由上表可知其各自对应的工作模式，甚至可以得出 VGT = EST + VST 这一等式，具体不再赘述。

      虽说在弄清 vSwitch 的三种工作模式之后便能应付大多数使用场景，但还不能像我前面夸海口般地加 “彻底” 这一状语，因为还有几项与之密切相关的配置若不弄明白，即使能熟练运用前面的知识也只能算是个花架子。我再举个我自己 2016 年刚接触 ESXi 那会抄作业的例子，记得很清楚的是在讲配置 VLAN 的那部分明确配图要求开启 Port Group 或 vSwitch 安全选项中的 “混杂模式 (Promiscuous Mode)” 以及另两项，但却没说为什么，而那三项均默认为 “拒绝 (Reject)” 须手工开启，正如下图所示，：



      大家若有兴趣不难在网上搜到类似开启混杂模式的文章或帖子，而这类文章都有个共同点：要么讳莫如深要么只讲过程却从不讲为什么，并且开启前后究竟有什么不同应该也是只字不提…… 假如你完全不了解这东西便抄作业，建议先读一下官方文档对该模式的说明。概括地说，开启混杂模式表示允许虚拟机的虚拟网卡接收到数据帧帧头中目标 MAC（网卡物理地址）并非自身的数据帧，若只是开启 Port Group 中该项则只能接收该 Port Group 内的所有帧，而开启 vSwitch 的则是整个虚拟交换机中的所有帧。很显然，这无异于在该 vSwitch 或 Port Group 中通过这一特殊手段添加了一个 “窃听器”，因为混杂模式会将原本仅属于某一台虚拟机的数据帧 “按人头数” 复制给该组中的每一台虚拟机…… 这回看明白了吧！假如只是有目的地在虚拟机上抓包分析倒无可厚非，但若是不明不白地开启它无异于主动为恶意软件创造了条件。更好的做法应当是为该虚拟机添加一个 VGT 模式（即：Trunk）虚拟网卡，一旦目标达成之后，若再无后续需求应将其还原为 VST 或 EST，否则便完全失去了交换机本身设计的意义，也只有如此才能确保 vSwitch 各端口组以及相应的虚拟机在网络层（L3）乃至数据链路层（L2） 的安全性不打折…… 若非如此，大家猜官方为何将其置于 “安全 (Security)” 配置项当中？！不过对于大型网络而言，若只是针对某个特定的 Port Group 小范围抓包显然还是单开该 Port Group 的混杂模式更方便，毕竟它是 “单向侦听”，而 VGT 模式是针对 vSwitch 全局并且是 “双向互通” 同时针对特定流量抓包还需要配合相应的过滤条件，总之各有利弊吧。

      既然现在明白了这一点，其实对于普通家庭这种没啥秘密可言的网络环境而言，只要网络能通怎么方便怎么来都无所谓，但若是在政府、企业等注重信息安全的网络环境当中可不能这么儿戏，请务必确保它们始终处于 “拒绝 (Reject)” 状态，确有需要的则临时用完即关闭，或请显式地采用 VGT 模式。言下之意：即使是家庭组网，本章全章节内容也完全不会涉及甚至杜绝开启那个 “混杂模式 (Promiscuous Mode)”，同时也不建议各位闲得无聊开启它徒增系统开销。与此同时，本章节中除非明文指出，均默认表示 ESXi 主机以及其 vSwitch 各项配置悉数采用官方默认值，以及：若无特别提示的，下文中所涉及到 ESXi 主机、vSwitch 各项配置的文字与截图等，均默认采用 Safari/Edge 浏览器 URL（https://主机名(或 IP)/）的 WebUI 方式。

      我以上文字并非在贬低甚至歧视混杂模式，而是刻意让事情保持简单（Less is more），因为凡事都有两面性，混杂模式同样也有它的长处，比如：抓包分析入侵检测、流量分析、端口镜像等用于提升网络安全之用，甚至还有一个似乎非它不可的场景：嵌套虚拟化（Nested Virtualization），即在 ESXi 虚拟环境中再运行另一个 ESXi，就是俗称的套娃，而在该场景当中单凭 VGT 是没法让嵌套虚拟机通网的，这时必须开启实体机 ESXi（非嵌套）相应 Port Group 或 vSwitch 安全配置中的 “混杂模式 (Promiscuous Mode)” 以及 “伪传输 (Forged Transmits)” 这两项，具体原因在 这篇文章 中有解答，其根源在于 vSwitch 收发数据的机理，而这几项均与 VLAN 完全无关，是属于比 VLAN 更基础的交换机共性。我猜测原文的受众大概率是网管、网工这类有一定基础的，所以只交待了关键原理而没交待过程细节。为了让更多人彻底明白其中的具体原因，我在原文基础上展开细说：

• 交换机的设计初衷之一是根据数据帧当中的目标 MAC 来决定该数据帧要发给谁来减少网络广播，与 VLAN 无关，而这也是它区别于早期集线器（HUB）的显著特征之一。
• ESXi vSwitch 与实体交换机不同之处在于：后者学习其端口连接的设备的 MAC 并保存老化清单，然而前者却不学习各虚拟机的 MAC，其理由是 ESXi 主机会保存各虚拟机的 MAC，并且数据帧最终也是由 ESXi 在 vSwitch 的指引下发给各虚拟机，这一套机制在非嵌套的虚拟机环境当中运行良好。
• 在嵌套的场景中，首先存在至少两个 vSwitch，我暂且称非嵌套的 ESXi Host 为 ESXi 而其 vSwitch 则为 VSW，而嵌套的则分别为 NESXi 及 NSW。首先第一个结论：NSW 向 VSW 发送数据帧这一段本身是一切正常的，就好比 ESXi 中的非嵌套虚拟机可通过 VSW 与实体交换机正常通讯那样。而问题会出现在 VSW 这一层而非 NSW，其根本原因就是上述 2 所说。具体如下：
• 嵌套的 NESXi 其自身对于非嵌套的 ESXi 而言本质上是一台与其它虚拟机一样的虚拟机，显然 NESXi 的虚拟网卡（vmnic）的 MAC 是被 ESXi 当作普通虚拟机 MAC 记录在案的，然而 NESXi 中嵌套的各虚拟机的 MAC 却因上述 2 中的原因只有 NESXi 自己知道。同理，非嵌套的 ESXi 本质上也是一台电脑。
• 接 3，当 VSW 接收到来自 NSW 的数据帧时，将依次触发 VSW 两项例行收发检测手序：A. 接收：判断该帧帧头中的目标 MAC 是否在 ESXi 记录的各虚拟机 MAC 清单中（即 1 中所说）；B. 转发：判断该帧帧头中的源 MAC 是否与发送该帧的那台虚拟机的 “现役 MAC 地址 (Effective MAC Address)” 相匹配，什么是现役地址（或作有效地址）会另行解释。
• 先以 NESXi 中的嵌套虚拟机访问 ESXi 中的虚拟机场景为例：根据上述 3 可知，嵌套虚拟机的数据帧能够正常通过 NSW 发出（暂且称之为 “去程”），比如：ARP 广播，当 VSW 接收到该 ARP 广播帧时首先执行 A 项检测，因 ARP 广播帧目标 MAC 为全 F，虽然它并非 ESXi 记录在案的，但它是广播，所以该项检测仍然通过；随即执行 B 项检测，显然该 ARP 广播帧中的源 MAC 是嵌套虚拟机网卡的，并且该帧来源于 VSW 自身 Port Group 中的 NESXi 虚拟机，这时 VSW 发现 NESXi 发出的帧其源 MAC 与 ESXi 登记的 MAC 不匹配，便立即触发安全项当中的 “伪传输 (Forged Transmits)” 条件直接丢帧 —— 意思是嵌套虚拟机的 ARP 广播帧连进入目标虚拟机 Port Group 甚至可以说连进入 VSW 的机会都没有，即使目标虚拟机的 Port Group 为 VGT 模式，抓包工具也将 “一无所获”。
• 再假设以上去程顺利完成（只是假设），目标虚拟机将通过 ARP 应答帧返回自身 MAC（即：回程），该应答帧的目标 MAC 则不再是 ARP 广播那时的全 F 而是嵌套虚拟机的 MAC，当应答帧来到 VSW 时照例先进行 A 项检测，不幸的是 ESXi 此时答复 “查无此人” 进而 VSW 丢帧，这次连 B 项检测都省了（虽然理论上能通过），同样地，在发起访问的源嵌套虚拟机上也不可能抓到该应答帧。原因正如上述 4 中所说，ESXi 本质上仍然是一台电脑，当发现数据帧不是发给自己所登记的 MAC 时则直接丢弃。
• 在清楚了以上过程之后就不难理解：嵌套虚拟机 想要访问 非嵌套虚拟机 的链路双向均不通，即 L2 数据链路层不通，所以不论 L3 网络层的 IP 究竟是同一网段还是跨网段其结果都是一样的。只有一个例外，那就是 NESXi 的 vmnic，它作为非嵌套虚拟机之一的网络接口的同时又兼作嵌套虚拟机的虚拟交换机接口，正因它的 “跨界” 特性，它即能被被其自身的嵌套虚拟机访问，又能被其它非嵌套虚拟机访问。
• 以上仅仅只是分析了 ESXi 内部的情况，那么对其外部的实体机欲访问嵌套虚拟机的场景，此时此刻 VSW 收到外部数据帧的情景恰如内部访问的彼时彼刻，嵌套虚拟机因上述 “内部” 原因村里都没通网…… 这就有点尴尬了不是！不过，既然已经清楚了问题的成因，解决办法也是现成的：同时开启 VSW 的 伪传输 与 混杂模式 即可，而 NSW 的相应选项无论如何设置均不影响以上情况，请继续保持它们为默认拒绝状态，难不成你还想嵌套第二层！？伪传输其实很容易理解，而为什么混杂模式能解决上述 7 中的问题的原因一早也解释了：要将它作为窃听器使，当然首先得先让数据帧绕过 A 项检测直接进入 VSW 或相应的 Port Group。
• 至于安全项中的 “MAC 地址更改 (MAC Address Changes)” 这项，具体的细节可以详见这篇文章。简单来说就是用于判断 vSwitch 或 ESXi 检查虚拟机操作系统当中保存的 “现役 MAC 地址 (Effective MAC Address)” 是否与该虚拟机配置文件（.vmx）当中的那个 MAC 地址相匹配。之所以有这个两个概念，是因为现实世界中被厂商 “烧录“ 在网卡硬件当中的物理地址此处唤作 “初始地址 (Initial Address)”，而虚拟环境中则其对应于 .vmx 配置文件中的那个。Initial Address 是不能直接被当前操作系统直接使用的，而需要操作系统在启动过程中将其复制到操作系统中某处保存后才能被自身或其它应用使用，而该 “复本” 就唤作 Effective MAC Address，就好比应用程序得加载进内存后才能运行，所以我便取其 “正在服役” 的意思而未取其字面的 “有效/生效”。而这一项所针对的是指修改 Effective MAC Address 这一行为而言，官方术语称之为 Impersonation（身份仿冒），而微软的网络负载均衡（NLB）功能在配置为单播模式需要多网卡共享一个 MAC 的场景中非它不可，官方文档也给了相应的配置方法。很显然，除了诸如 NLB 这类有正当用途的以外，其它修改 Effective MAC Address 的行为不太好判断其是否属善意。该行为与前面所说 “伪传输 (Forged Transmits)” 之间的差异在于前者是刻意的且主动的行为，而后者则是被动、因客观条件造成。所以建议没事别开启它。
  

      经以上解释后不难理解，解决嵌套虚拟化通讯问题的最优解实际上应当是采取实体交换机那样的 MAC 地址学习，可喜的是，官方文档（What is MAC Learning Policy）指出分布式交换机（VDS）可通过 vSphere API 方式启用该功能，而遗憾的是，对于普通人常用的标准虚拟交换机（VSS）则没交待…… 至此，对于 vSwitch 中最为核心的概念已基本清晰，结合我以上理论，各位再回头去读官方文档以及网上类似文章，相信很多疑惑便能迎刃而解 —— 而事实证明这才是正确的打开方式。至此，核心的 vSwitch 与 Port Group 理论已具备，而其余的配置项在绝大多数场景对绝大多数人而言均属 “可选项”，限于篇幅便不予展开。

      言归正传。作为与上一章节中相应内容的对照，Port Group 等价于 Windows Server “组接口 (Team Interface)”，而 HomeLab 那个网卡组（NIC Team）则与 vSwitch 是等价的 —— 而以上也是本文可以采用普通家用电脑/网卡实现 “单臂路由” 的又一个理论基础（参见上一章 “知识点十” 处）。更进一步，vSwitch 的 EST 模式于是乎又恰好与 Windows Server 中那个 “主组接口 (Primary Team Interface)” 在缺省情况下 “自适应” 了，换句话说，若是基于 ESXi 的 Windows Server 虚拟机，且该 Windows Server 虚拟机所在 Port Group 为 EST 模式（VLAN ID = 0），那么，该 Windows Server 的 主组接口 采用 “默认值” 或令其 VLAN ID = 0 是等效的，并且能够实现与该 EST 模式 Port Group 中各虚拟机互通，即：相当于它所连接的是电脑网口、家用路由器 LAN 口…… 只有一个前提，就是上一章强调的 “no vlan dot1q tag native”，各位若有兴趣可自行验证。对于自身已有一定基础且已经理解并掌握了 vSwitch 的工作原理，同时也完全了解各类实体交换机基本工作原理的，相信你已经能够像网络工程师那样自行完成组网了；而对于理论基础仍有欠缺的，也不要急于求成，我将一步一步告诉各位具体步骤，同时也将清楚地交待为何如此。

      既然标题是单臂路由，先单看 ESXi 虚拟环境这部分，欲通过 vSwitch 在虚拟环境中建立 VLAN，那么 ESXi 主机唯一的网口所连接的实体交换机的端口则必须配置为 Trunk，且同时记下其 Native VLAN ID 值备用，同理在 vSwitch 这端则必须将相应的 Port Group 配置为 VGT 模式（VLAN ID = 4095）。与此同时，官方文档针对 VGT 所说的那个 “an 802.1Q VLAN trunking driver” 我不说相信各位也能猜到个大概了吧？其正是上一章节当中 Windows Server 所提供的 NIC 组合功能所创建的相应 VLAN 的组接口所完成的工作（可结合开篇头两张拓朴图中放大镜效果那处来理解）。而官方所说的那个 “driver”，应当指的是某些高端服务器高性能网卡其硬件具备 VLAN 卸载（VLAN off-load）能力，并为其所提供的相应驱动，显然那类高级货不是咱们这种普通家庭能承受的，但好在咱们有平价替代方案，此处我暂且称之为 “平替”。至于 ESXi 主机物理网卡是多网口的，若充分利用以上 EST、VST 及 VGT 等端口组特性去分别连接不同类型的网络设备（如：路由器、交换机），则你的 Windows Server 软路由乃至 ESXi 主机的玩法又会多些花样，因属超纲就不展开细节，留待各位根据以上理论自行探索。

      接着再来看实体交换机这部分。市场上的产品主要分：L2 傻瓜式、L2 管理、L3 管理这三大类，此处特意在第一项前加 L2 意为提醒各位千万别不把傻瓜式当 L2。因后两类产品本身具备 VLAN 能力，所以没有过多可说的，若对实体机环境确实有 VLAN 需求的旦凡有条件的都尽量上这类交换机。而针对傻瓜式这类普通家庭中最常见的，我反倒要重点在这里提一下，傻瓜式的因其自身不具备 VLAN 能力而注定了实体机环境中是无法实现多 VLAN 这一点虽无法改变，可虚拟机环境却不受其限制，原因在上文已有过提示，正是因为傻瓜式其本身没有识别和处理 VLAN 标签的能力，其同样没能力阻止 802.1q 标签在 Ethernet Ⅱ 上开挂，足可见 “傻瓜” 二字的来历，显然这类产品与其它可管理交换机的差异主要体现在其各端口以及其内部的工作模式的不同，在上一章也有过初步解释，这里再展开讲解以防有跳过前面内容的，具体如下：

• 可管理交换机端口区分 Access 和 Trunk 类型，而傻瓜式的则不分；
• 可管理交换机 Trunk 端口永远都有 Native VLAN ID 这一端口属性，而傻瓜式的端口则完全没有或者其为任意值，尽管这两类端口都能用于连接任意设备；与此同时，Trunk 端口还有 VLAN 允许列表，而傻瓜式则来者不拒；
• 可管理交换机 Access 端口只能连接电脑这类仅接受 Untagged 帧的网络终端，反过来讲，Access 端口所连的终端设备永远只会接收到 Untagged 帧，而拆/装 VLAN 标签的工作全在交换机内部完成；而傻瓜式的则无所谓，不论 Untagged 亦或是 Tagged 均照单全收，全然不顾终端设备究竟能不能接受 Tagged 帧；
• 即使是 Untagged 帧在进入可管理交换机内部后也必定成为 Tagged 帧，若从 Trunk 端口进入则被打上 Native VLAN ID 标签，若从 Access 端口进入则被打上该端口所归属的 VLAN ID 标签，同时，最终能离开可管理交换机 Trunk 端口的数据帧究竟是 Untagged 还是 Tagged 也取决于其配置；反观傻瓜式，正是因为上述 “傻瓜” 的缘故，显然数据帧即使进入傻瓜式交换机内部依然是 “原封不动 (Intact)” 的状态，并且能够最终通过（被转发离开）傻瓜式交换机的数据帧必定也是原封不动；
• 那么问题又来了：傻瓜式交换机与网线好像没啥差别？并不是，因为即使最简单的傻瓜式交换机，也有基础的 MAC 地址学习功能，同样具备在转发数据帧时根据帧头中的目标 MAC 来决定其转发方式这一基础 “二层交换” 能力，并不是说它真傻，否则便不再配被称作交换机，而是集线器、分线器之流，这正是 “交换” 与 “广播” 之别。
• 综上，傻瓜式交换机与其它可管理交换机都具有 “二层交换” 这一共性，这两类设备之间本质区别在于对 VLAN 的支持，更专业或学术的说法应当是：其所连接的设备是否在同一个 L2 二层广播域，即：VLAN 的本质就是细分后的二层广播域。也许有人会提问：是不是同在一个二层广播域中的不同 IP 地址段的设备就能直接互通呢？答案是否定的，举个简单的例子：一台傻瓜式交换机连接两台不同 IP 网段的电脑，显然两者在同一个二层广播域，但若没有网关则两台电脑仍然无法通讯，原因在于 IP 是三层寻址的概念，不同 IP 网段的寻址过程需要通过网关完成 —— 但这部分内容也超纲了，请有兴趣的看官们自行了解 TCP/IP 协议中有关寻址与路由方面的原理。
  

      相信经这样解释之后，各位应当能分清楚 Trunk、Access 以及傻瓜式这三类交换机端口其各自的工作方式了吧。在清楚了以上原理之后，对于家中有且仅有傻瓜式交换机的看官们想要体验多 VLAN，唯有虚拟机环境一条路可行，只须按照以上原理正确地进行配置，则虚拟多 VLAN 环境中的各虚拟机一样可与你实体傻瓜式交换机连接的实体设备互通有无，而以上则为其理论基础。不过我这样讲实际上并不严谨，因为以 Intel 为代表的部分网卡其驱动本身就能提供多 VLAN 功能，即是说家用实体机自身通过网卡驱动能创建多 VLAN 环境，根据以上傻瓜式交换机的特点可知，家用采取这种搭配也完全没问题。


      若各位严格按照我上文建议不对 vSwitch 默认设置作更改，则本文涉及到的需要各位手动管理与配置的则只有 ESXi 主机的端口组（Port Groups），我将其区分为以下两类：

• 管理组（Management Network）；
• 用户组（User Created）。
  

      首先声明：我以上的分类法并不严谨，因为二者本质上没有差别，而差别仅在于各自用途，之所以这样分类是希望大家重点关注第 1 类。Management Network 这项是新装 ESXi 操作系统时默认创建的（VLAN ID = 0，即：EST），可以改名，但若想删除它的话就不是那么容易，因为该组默认绑定了 VMKernal NICs，用于对 ESXi 主机进行网络远程管理，所以在将新的端口组绑定给 VMKernel 之前系统会禁止删除它，言下之意，我实际上将如何删除它的方法也告诉各位了。不过还是建议大家在不清楚自己在做什么之前不要轻易去尝试删除它。而第 2 类是我自己起的名，官方并没有这个称呼，新装的 ESXi 操作系统同样也默认为各位安排了一个唤作 “VM Network” 的组，初始也是 EST 模式，而这个组则可由用户决定其去留，假如纯粹是为了看一眼 ESXi 长什么样，删除 VM Network 组除了不能为虚拟机添加网卡之外不会有任何影响，因为 Management Network 是不能连接虚拟机的。用户组的具体创建方法如下图所示：



      对于 Port Group 手工配置所需要讲解的至此已完成，至于如何创建、安装、配置虚拟机等在我看来同样属 “应知应会” 范畴。现在需要重点为各位讲清楚的还剩下一件事：如何正确地将 Management Network 由默认的 VLAN 0（此处为便于表述我暂且用 “VLAN 0” 这个不正确的说法来指代傻瓜式交换机所处的网段，以下类似）迁移至其它 VLAN 段？或者说：如何正确地令 Management Network 的工作模式在 EST 与 VST 二者之间切换以适应不同的网络规划？但请稍等一下，为什么没有 VGT？还是先说结论：官方的确允许将 Management Network 组配置为 VGT（VLAN ID = 4095），但我并不建议这么做，原因是它绑定的是 VMKernel NIC，即：管理内核接口（vmk0），就相当于一台电脑（Untagged），而 VGT 因没有 Native VLAN ID 属性从而相当于傻瓜式交换机端口，理论上是可以接电脑的这一点没错，但根据前面表格可知，Untagged 帧默认了 VID = NULL ⇔ 0，即：VLAN ID = 0 ⇔ EST，这好像绕口令啊。然而我要指出的是，以上的结论虽然看似正确，但推理过程其实是有瑕疵的，原因是如下图所示，其根源并不在于作为管理 ESXi 主机的组能不能被配置为 VGT，而在于既然所有流量均已在 vSwitch 之中，为何还要将其配置为 VGT 去侦听/接收那些对管理组毫无意义的其它组的流量徒增系统开销？！那么现在请各位再回想一下为什么我前面建议各位不要开启 “混杂模式 (Promiscuous Mode)”。只有同时理解了这层意思才能算作真正理解了 Port Group 乃至 vSwitch。


      经过以上一大堆概念解释之后，现在才正式切入 ESXi vSwitch 的实际配置环节。既然已知全新安装的 ESXi 主机其 Management Network 管理组初始便是 EST 模式，那就先来看官方建议的 EST -> VST 标准迁移步骤，但请搭配傻瓜式交换机的各位先不要急于操作，因为这部分原则上是为 ESXi + 可管理交换机 这一搭配准备的：

• 在初始模式（EST）时，应确保 ESXi 主机网卡连接的实体交换机端口模式为 Access（傻瓜式交换机可忽略）；
• 修改 ESXi 主机 IP 地址为目标 VLAN 段对应的 IP 地址；
• 将 Management Network 的 VLAN ID 值由默认的 0 修改为 1 ~ 4094 之间的任意一个，但官方是有附带条件的，详情见以下注释；
• 将ESXi 主机网卡连接的实体交换机端口模式改为 Trunk（傻瓜式交换机可忽略）。
  

     

• 注：官方文档（原文门牌）针对 VST 模式强调勿将 ESXi 任一端口组的 VLAN 设定为物理交换机该端口指定的 Native VLAN（即：前面让各位记下备用的那个 Native VLAN 值），包括 Management Network 这个默认管理组在内，而其理由是实体交换机 Native VLAN 数据帧均默认 Untagged。针对官方指出的这一点需要结合前面章节讲 Windows Server 配置 主组接口 的那一大段解释一起来理解：VST 模式的取值范围（1 ~ 4094）实际已暗示了该模式的本意就是让数据帧必须带上相应的 VLAN 标签，一旦设置某个 Port Group 的 VLAN ID = Native VLAN，在没有显式禁止拆标签指令的情况下实体交换机发往该 Port Group 的数据帧显然悉数为 Untagged，而此时工作在 VST 模式下的 Port Group 则直接尽数丢弃 Untagged 帧…… 言下之意：假如你的交换机已使用显式指令禁止 Native VLAN 拆标签便可无视官方这一限制 —— 虽然我也不建议这样做。
  

      上述第 2 步修改 IP 地址必须通过 ESXi Console 手动修改，而这一步实际是修改 VMKernel NIC，即：管理内核接口（vmk0）的 IP 地址。如下图所示，


      第 3 步操作如以下两图所示，既可通过浏览器 WebUI 管理页面直接修改，亦可通过 ESXi 主机控制台（Console）界面修改。一个避坑提醒：建议与第 2 步一起通过 ESXi Console 修改！原因是 2 & 3 这两个步骤的先后次序实际上是有讲究的，只有 ESXi Console 能无视该次序，而这个 “坑” 极其容易让人忽略。说起来也很容易懂：若先改了 VLAN ID 而未改 IP 地址，那么请问新的 VLAN 段的 IP 能直接访问这个 “非法” IP 吗？



      对于搭配可管理交换机的看官们而言，vSwitch 配置的全部内容可以说已结束了，既然都用上可管理的设备必然是有一定知识储备的，余下的相信都能自己应付了。而对于搭配傻瓜式交换机的，到这里才算真正的开始。原因也非常简单：因为用于管理 ESXi 主机的实体电脑受交换机硬件所限而无法变更 VLAN 段，一旦按以上标准步骤操作后则必然造成与 ESXi 主机失联这样的人间惨剧，这时你还得用 ESXi Console 恢复原状（包括通过 IPMI、iLO、iDRAC 这类远程控制手段）。那么这是不是说搭配傻瓜式交换机的就不能将 Management Network 改为 VST 了呢？答案是 “能改”，而聪明的看官应该已经想到办法了：

      虽然实体机环境不支持，可还有 vSwitch 以及其中的虚拟机可被充分利用，并且两个不同 VLAN 互访恰好路由器最擅长，于是上一章节中所说的那台虚拟机 Windows Server 软路由便是解题的关键。不过要解这道题稍有点绕，请仔细想：傻瓜式交换机因无法改变自身 VLAN，这便决定了它所连接的实体电脑的网段均为 Untagged，相当于实体电脑被固定在了 “VLAN 0”（借用 VLAN 0 之意），同理，家用路由器 LAN 口对于傻瓜式交换机而言同样处于 VLAN 0，假如只是简单地将 Management Network 迁移至其它 VLAN，无疑采用 Windows Server 软路由可解决 VLAN 间路由问题，可另外的问题是：其它 VLAN 的虚拟机需要访问 Internet 怎么办？显然只能将 VLAN 0 作为软路由的 WAN 段而其余 VLAN 则作为 LAN，随之 NAT 解决问题…… 但这样一来对于连接傻瓜式交换机的实体机而言又有新问题了：处于外网 WAN 段的实体机怎么能访问到内网 LAN 段中的虚拟机呢？其实答案已呼之欲出了：为避免出门忘带钥匙被锁在门外，于是家里始终留一个 “门卫” 为自己开门。步骤大致如下：

------ 更正说明 ------
Windows Server 软路由实际上是现成的 “门卫机”，因我最初的想法是不建议大家直接通过软路由的远程桌面来管理 ESXi，所以才有以下门卫机的做法。各位可根据自身实际情况进行取舍。

不过我当时在写门卫机步骤的过程中又忘记了一点，即：门卫机实际上应当要有两张虚拟网卡，一张用于与实体机通讯、另一张用于与 ESXi 通讯。此外，“门卫机” 与以下 “木马机” 的差异仅仅在于第二张网卡所在的 VLAN 是否能被软路由直接访问，其余均一致。详见以下修订后的内容：

• 首先规划好你的 VLAN 段，包括 VLAN ID、命名、IP 地址划分等；
• 按上一章内容配置好 Windows Server 软路由，同时确认与 1 中规划相符，各 VLAN 组接口（Team Interface）能互通；
• 请确保 vSwitch 中有 EST 模式的 Port Group，默认的那个名为 VM Network；若没有则新建一个，假设其名为 PGT;
• 再假设 1 中规划 Management Network 将迁往的 VLAN ID = 30，则新建一个 VLAN ID = 30 的 Port Group 并假设其名为 MGM，即：确保与 Management Network 处于相同 VLAN；
• 新建一台门卫虚拟机，分配两张网卡，其中一张连接上述 3 中的 PGT，或其它 EST 模式的 Port Group 均可，而另一张连接上述 4 中的 MGM；
• 随后将 4 中门卫机 PGT 对应的那张网卡的 IP 设置为与实体机同一网段，并请记下该 IP 地址作为远程桌面的入口地址；而 MGM 对应网卡的 IP 的网关留空即可，因为相同 VLAN 段 + 相同 IP 段无需网关；
• 接下来配置好远程桌面，同时确认可从实体机正常登录该门卫机的远程桌面；再确保 门卫机 与 Windows Server 软路由 双双配置为随 ESXi 主机开机自启动（Autostart），可在 ESXi 主机 “管理 -> 自动启动” 中设置，启动先后次序请按各自环境自行决定；
• 然后按上面官方给的 EST -> VST 标准操作步骤通过 ESXi Console 将 Management Network 组迁移至其它 VLAN，其网关则设置为 Windows Server 软路由的相应组接口 IP；
• 紧接着确认实体机能够使用 5 中 IP 登录门卫机的远程桌面，并能通过该门卫机的浏览器正常管理 ESXi 主机，并且在将 Management Network 迁回 VLAN 0 之前都得如此；
• 模拟断电、关机、重启等各场景并确保以上配置无误；
  

------ 更正完毕 ------

      至此，若你已理解并掌握以上各个概念，恭喜你，今后也可以自信地自称 “精通” ESXi 网络配置了，那么本章内容也已结束。什么？怎么才感觉刚开始就已经结束了？！没错，不论你清不清楚以上的概念，ESXi 的配置实际真就这么简单，也是我一直将其作为我家用底层环境的原因之一。假如有嫌内容不够丰富的，那么我再免费送一个用处不大甚至还有点找抽的 VST 花活给大家开心开心：将 Management Network 隐藏到虚拟环境中不让实体机直接访问。该花活的思路一说大家就明白：特洛伊木马（Trojan Horse），当然这是从隐藏 VLAN 的角度来看，简要概述就是在 vSwitch 中预先准备好一个专用于管理 ESXi 主机的 “木马 VLAN”，即：连软路由也无法直接访问，然后为前面那台门卫机添加一张网卡为木马专用，并将 Management Network 管理组迁移过去。如此一来，门卫机便摇身一变成为木马机，而该木马机的远程桌面便成为管理 ESXi 主机的唯一入口。具体步骤如下：

• 门卫机的配置请详见上方；
• 假设木马 VLAN ID = 404，请确保 VLAN 404 不在 Windows Sever 软路由组接口清单中，即软路由不可访问 VLAN 404；
• 在 vSwitch 当中新建一个 VLAN ID = 404 的 Port Group 并假设其名为 TJS；
• 为上述门卫机新增一张虚拟网卡并将其连接至 3 中 TJS 端口组，完成 “门卫 -> 木马” 变身；
• 随即开机设置木马机新增那张虚拟网卡的 IP 地址，网关留空即可，因为它将与 ESXi 主机管理接口处于相同网段；
• 请确保该木马机未启用 LAN 路由、网络共享等，若有请务必关闭或禁用，更不得将上述两网卡进行桥接（Bridging）；
• 接下来再确认木马虚拟机的开机自启动（Autostart）已正确配置；
• 然后按上面官方给的 EST -> VST 标准操作步骤通过 ESXi Console 将 Management Network 组迁移至木马 VLAN，其网关地址为自身或留空均可；
• 紧接着确认实体机能够登录木马机的远程桌面，并能通过该木马机的浏览器正常管理 ESXi 主机；
• 模拟断电、关机、重启等各场景并确保以上配置无误；
• 最后将 ESXi 主机置于机柜或不便于物理接触的地方。
• 收工！
  

      是不是很无聊！以上纯属献丑。假如各位还有其它花活的，也请不吝留言分享！
 

五、结语/背景

      软路由对于很多人而言并不陌生，诸如鼎鼎大名的 OpenWrt、iKuai 这类硬件或虚拟机解决方案，包括单臂方案，网上简直是信手拈来，不过对我这种专注于 Windows Server 的而言则是尽可能地避免第三方解决方案，并不是因为它们不够好，其实正相反，它们甚至比 Windows Server 的方案更好，仅仅只是因为我个人偏好 “纯净、极简” 的缘故；另一方面，配置 Windows Server 作软路由的文章网上也非常多，并且多年前就有，不过我在网上找到的 Windows Server 软路由方案似乎没有一篇是与我这篇类似采用 “单臂” 的方式，即便如此，也不足以促成我写下这篇，更何况我早前在连载 PXE 无盘三篇（见下方门牌号）那时，更准确地讲是在我写后两篇那时，因受硬件所限也被迫采用了 Windows Server 虚拟机软路由，与这篇所不同的是，当时的重心并不在 “单臂 + 多 VLAN”，否则早几年前大家就应当看到这篇了。

• NUC9 iSCSI无盘工作站/服务器札记 — PXE安装及引导 Win11 成功
• iPXE iSCSI无盘安装及引导 Win11／10 连载(上) — WDS篇
• iPXE iSCSI 无盘安装及引导 Win11／10 连载(下) — Linux + wimboot 篇
  

      真正促成我写这篇文章的另一个主要原因在于：这套单臂组网方案的灵活度非常大，硬件方面尤其是对实体机而言，下至家用丐中丐、上就看愿砸多少钱，同时，Windows Server 软路由配置的全过程不必借助微软家以外任何第三方软件，同样非常贴合偏好 “纯净系统” 这类群体的需求，再加上原生 Windows 图形化配置的门槛已低无可低，可想其适用面也极大；还有其二：我很早之前便有升级万兆网的需求和打算，按理买买买就完了，但当时苦于市面上适合我的万兆电口的家用产品极其稀有，即便是有，那价格和企业级也差不太多，也考虑过 SFP+ 转 RJ45 电口模块，但合计造价也接近原生电口产品了，再者还有可能存在模块本身的兼容/稳定性问题，并且功耗、发热、安装后明显突出面板一大截都算作劝退理由…... 在海鲜市场蹲守了一年多之后，直到前段时间才最终被我看到一款价格、品相都令我满意的那款三层万兆交换机（C3560CX-8XPD），再加上东西应该是卖家自己家用升级后淘汰下来的，保养得非常好，同时卖家非常爽快并且显然是懂行的，没聊两句我就直接下订了。选择它是因为其除具备 2 x 10Gbps SFP+ 口之外，还具备 2 x 10Gbps Multigigabit RJ45 多速率电口，官方文档显示这俩电口支持的速率范围为 100M ~ 10Gbps 自适应，就是说 NBase-T 标准 2.5G + 5G 也通吃，实际使用中也的确如此，如此一来，即使今后上光纤也没任何可担心的了。就是下图中的宝贝：



      正所谓 “万兆高楼平地起”，有了这个宝贝打地基，除了可实现万兆线速转发外，原本我只能在虚拟机环境中才能体验的多 VLAN，现在不但能直接与实体机进行交互以及 VLAN 间路由，还能借助 Windows Server 软路由进一步实现多 VLAN 上外网了。欣喜之余，再加上前面提到的几点，才最终促成我写这篇，同时希望可供有同样治学需求的看官们一些帮助或参考。

      各位看到这里请不必有 “我仲未上车哦” 这样的担心，以上只是交待我写这篇的真实背景，而不是说 L3 交换机是入场券！

      虽说这次是家庭组网，可事实上 Windows Server 的能力及稳定性远超家用需求，假如可以将家庭宽带换成企业宽带、再将我的时间胶囊替换为性能更强的家用路由器，虽然没有条件实测，可我估计用手上这台基于 Ryzen PRO 5750GE 平台搭建的 Windows Server 软路由配合 C3560CX 带个 50~100 台机器的小网估计还是有富余的。最后再次友情提醒一下：Windows Server 可不是免费的，若有商业用途的还请使用正版 —— 这也是我开篇和结尾一再强调 “治学” 的用意。可话又说回来，在彻底弄清楚这些个概念之后发现，这些所谓的技术手段均为 “大型网络” 而生，尤其是其中包括 VLAN、ACL、策略路由、防火墙等技术也好产品也好有一个算一个，无一例外均服务于大型网络环境的 “网络安全”，并且这类产品还卖得死贵，而从这个角度来看，也能够理解为什么产品需要区分家用和企业级了。对普通家庭而言就买家用的也完全够用了，而一定要上企业级的则似乎正印了古人云：天下本无事、庸人自扰之 —— 这其中显然也包括了我，所以本文最后的一个用意是希望各位以我为鉴。
（全文完）

z82638275

大佬,这也太详细了. 收藏学习了

后天

弱弱问问

搞这么清晰的

是不是都考过了CCIE？

lsy174915864

从未考虑过单臂，这玩意不符合我的搞机哲学

dirnet

非常详细，先码后看

imyz

后天 发表于 2025-6-19 15:09
弱弱问问

搞这么清晰的

Cisco 欠我一张

imyz

lsy174915864 发表于 2025-6-19 15:18
从未考虑过单臂，这玩意不符合我的搞机哲学

图一 或 图二，总有一款适合你

lsy174915864

imyz 发表于 2025-6-19 18:06
图一 或 图二，总有一款适合你

那倒不用，我的家庭网络系统自搞好之后已经稳定运行6年多了，玩ROS的人，都能自己搞定。

你这图画的倒是不错，好评。

imyz

lsy174915864 发表于 2025-6-19 18:40
那倒不用，我的家庭网络系统自搞好之后已经稳定运行6年多了，玩ROS的人，都能自己搞定。

你这图画的倒是 ...

玩 ROS 的都是大佬啊！！

goat

看到esxi的vswitch痛苦的记忆又回来了

housecall

技术贴，多谢分享，学习一下