Chiphell - 分享与交流用户体验

标题: Windows Server(ESXi) 单臂(软)路由 + NAT 家庭多 VLAN 组网手记 [打印本页]
作者: imyz    时间: 2025-6-19 14:36
标题: Windows Server(ESXi) 单臂(软)路由 + NAT 家庭多 VLAN 组网手记
本帖最后由 imyz 于 2025-6-19 14:44 编辑

一、概述

      这篇文章的目标是在网络层（第三层）为 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 配置的章节。测试环境拓朴图如下：

(, 下载次数: 0)

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

(, 下载次数: 0)

* 优点：

* 缺点：


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

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



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

二、软硬件清单

* 硬件：

* 操作系统：

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

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

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

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

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

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

(, 下载次数: 0)

      假如对以上这些概念不熟悉或者看不明白的也没关系，请带上问题读完以下内容，若有条件的再实际操作一次之后，然后回头再来看，相信多少也会有些收获。
作者: imyz    时间: 2025-6-19 14:36
标题: 三、Windows Server 单臂软路由配置
本帖最后由 imyz 于 2025-6-21 15:49 编辑

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




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

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

      上图中红线标注的那个 “主要” 一列显示为 “是” 且 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 的需求等，因越来越多厂商群雄逐鹿而当时标准不统一导致了各厂家设备在兼容方面的问题，于是 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）实施相应的管理。



      现在已知局域网（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 的场景，也大可将其视作普通组接口也没任何问题，甚至令 主组接口 闲置或禁用之进而省去操这份心也不是不行。



      与上述 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，要么请完全闲置或禁用之。



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

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

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

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

注意：因为组接口（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 大佬的话，则可以跳过接下来的内容并直接着手实践了。

------ 更正说明 2025/6/21 ------
      非常抱歉，在没有开启 Windows Server 的 “LAN 路由” 功能之前，不论实体机或虚拟机将网关指向 Windows Server 软路由相应 VLAN 组接口 IP 并不能实现跨 VLAN 互访。而开启 “LAN 路由” 的方式与以下 NAT 的启用方式类似，区别在于如下图所示选择 “自定义配置(C)” 那项而不是 NAT。不过，开启 NAT 的同时是默认开启 LAN 路由的，并且自定义方式也能如下图所示同时选择 NAT，所以请各位按各自需要自行决定采用哪种方式：
(, 下载次数: 0)
(, 下载次数: 0)
------ 更正完毕 2025/6/21 ------

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

      待安装完成后，便可如下图所示启动路由管理界面：
(, 下载次数: 0)

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

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

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

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

      以上图为例，假如你家的宽带是有动态公网地址的，经过以上配置后就能够从任何可以上网的地方访问家里 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）这种转发几次问题都不大。
(, 下载次数: 0)

      就事论事地说，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 来进一步减轻负担。顺手再给几个友情提示：


(, 下载次数: 0)
(, 下载次数: 0)
(, 下载次数: 0)

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


      接下来将进入 “赠品” 环节。
作者: imyz    时间: 2025-6-19 14:36
标题: 四、ESXi 虚拟交换机（vSwitch）配置
本帖最后由 imyz 于 2025-6-20 09:55 编辑

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

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



      为更加有助于各位理解，我首先用我自己配置完成的 vSwitch 的拓朴图来切入正题：
(, 下载次数: 0)

      明眼人一眼便能看出，上图中是一台配置为 “单臂” 的 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 三者之间默认有互斥关系…… 现在第二个提问似乎打破了这个 “暗示 (或者不如说是误导)”，那么请再看以下我加了标注说明之后的拓朴图：
(, 下载次数: 0)

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


(, 下载次数: 0)

      由此可见，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)” 须手工开启，正如下图所示，：
(, 下载次数: 0)
(, 下载次数: 0)

      大家若有兴趣不难在网上搜到类似开启混杂模式的文章或帖子，而这类文章都有个共同点：要么讳莫如深要么只讲过程却从不讲为什么，并且开启前后究竟有什么不同应该也是只字不提…… 假如你完全不了解这东西便抄作业，建议先读一下官方文档对该模式的说明。概括地说，开启混杂模式表示允许虚拟机的虚拟网卡接收到数据帧帧头中目标 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 地址学习，可喜的是，官方文档（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 Ⅱ 上开挂，足可见 “傻瓜” 二字的来历，显然这类产品与其它可管理交换机的差异主要体现在其各端口以及其内部的工作模式的不同，在上一章也有过初步解释，这里再展开讲解以防有跳过前面内容的，具体如下：



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

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


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

      对于 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。
(, 下载次数: 0)

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


     

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

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

      对于搭配可管理交换机的看官们而言，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 是否能被软路由直接访问，其余均一致。详见以下修订后的内容：


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

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



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

五、结语/背景

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


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

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

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

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

搞这么清晰的

是不是都考过了CCIE？
作者: lsy174915864    时间: 2025-6-19 15:18
从未考虑过单臂，这玩意不符合我的搞机哲学
作者: dirnet    时间: 2025-6-19 15:43
非常详细，先码后看
作者: imyz    时间: 2025-6-19 18:05
后天 发表于 2025-6-19 15:09
弱弱问问

搞这么清晰的

Cisco 欠我一张
作者: imyz    时间: 2025-6-19 18:06
lsy174915864 发表于 2025-6-19 15:18
从未考虑过单臂，这玩意不符合我的搞机哲学

图一 或 图二，总有一款适合你
作者: lsy174915864    时间: 2025-6-19 18:40
imyz 发表于 2025-6-19 18:06
图一 或 图二，总有一款适合你

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

你这图画的倒是不错，好评。
作者: imyz    时间: 2025-6-19 19:02
lsy174915864 发表于 2025-6-19 18:40
那倒不用，我的家庭网络系统自搞好之后已经稳定运行6年多了，玩ROS的人，都能自己搞定。

你这图画的倒是 ...

玩 ROS 的都是大佬啊！！
作者: goat    时间: 2025-6-19 22:23
看到esxi的vswitch痛苦的记忆又回来了
作者: housecall    时间: 2025-6-19 22:55
技术贴，多谢分享，学习一下
作者: smallfount    时间: 2025-6-20 08:50
很厉害。。
不过我还是不喜欢把关键的出口丢给windows或者说任何VM host..
重启太慢了。。。而且一旦host重启手机就丢网络。。。无法接受啊。。。
作者: imyz    时间: 2025-6-20 09:05
goat 发表于 2025-6-19 22:23
看到esxi的vswitch痛苦的记忆又回来了

希望这篇文章能帮助到有这类痛苦的
作者: imyz    时间: 2025-6-20 09:07
smallfount 发表于 2025-6-20 08:50
很厉害。。
不过我还是不喜欢把关键的出口丢给windows或者说任何VM host..
重启太慢了。。。而且一旦host重 ...

哈哈哈哈哈，那您肯定是没体验过我手上这台 C3560CX-8XPD，重启一次 3 分钟打底，有这时间我的 ESXi 主机 + VM 虚拟机们也差不多重启完了，简直绝配
作者: wuhao0015    时间: 2025-6-20 09:34
C3560CX-8XPD 这个交换机曾经考虑过，功能强大，IOS用着顺手；但是价格高，体积大，功耗大，还嘎嘎烫。。。没有机柜搞不定。最终搞个傻瓜的也挺好的。
作者: smallfount    时间: 2025-6-20 09:48
imyz 发表于 2025-6-20 09:07
哈哈哈哈哈，那您肯定是没体验过我手上这台 C3560CX-8XPD，重启一次 3 分钟打底，有这时间我的 ESXi 主机 ...

.....可是我为啥要重启交换呢。。，
顺便。。。我用的是H3C 5560....从配置完成后三层交换没有任何主动重启的记录。。
windows server嘛。。。。。就不说了
作者: smallfount    时间: 2025-6-20 09:51
wuhao0015 发表于 2025-6-20 09:34
C3560CX-8XPD 这个交换机曾经考虑过，功能强大，IOS用着顺手；但是价格高，体积大，功耗大，还嘎嘎烫。。。 ...

因为3560太老了。。
就算是10多年前我们新项目开工。。他们只有在3750/3850来不及到位的情况下作为Plan B登场。。。现在连9300都进入更新周期了已经。。。
作者: imyz    时间: 2025-6-20 14:20
smallfount 发表于 2025-6-20 09:51
因为3560太老了。。
就算是10多年前我们新项目开工。。他们只有在3750/3850来不及到位的情况下作为Plan B ...

哈哈哈哈，是这个理。所以特意在标题中安了个 “家用”
作者: lwmboss    时间: 2025-6-20 14:26
进来学习一下



欢迎光临 Chiphell - 分享与交流用户体验 (https://www.chiphell.com/) Powered by Discuz! X3.5