★ FEATURED ARTICLE 做主机运维的人大多有过这种体验某天巡检的时候翻了一下主机的日志发现认证失败的记录刷了满满几屏来源地址是自己完全不认识的网段。那一刻你就会意识到一个事实——ESXi 装完默认状态是把 443 的 Web 管理页面向整个二层网络敞开的只要能路由到管理地址谁都能打开那个登录框。对 IP 进行限制只开放指定的 IP 访问 web 页面这件事本质上做的不是加固而是把管理入口从广场缩回自家门厅。这篇文章就把这套操作从原理到命令、从白名单编制到把自己锁在门外的排查链路完整讲一遍。内容偏向 6.5/6.7/7.x/8.x 通用做法只要你能摸到主机的命令行或者 DCUI就能跟着做脚本基础一般也能上手。1. 为什么必须把 Web 管理页面的访问源收窄1.1 默认放通到底意味着什么ESXi 的防火墙和很多人想象的不太一样它不是默认拒绝、按需放通的思路而是服务集默认启用、来源默认全通。你敲esxcli network firewall ruleset list看到的那一列AllowedAll true翻译成人话就是只要某个规则集被启用了防火墙就不再管来源谁连都放进来。Web 管理页面所在的规则集天然是启用的因为它就是给人用的。所以你拿到一台新装的主机第一件事也许是把管理地址配好第二件事其实是决定谁有资格敲这个地址。真正麻烦的地方在于暴露面的扩散速度。管理网段一旦被规划得比较宽比如一个 /16 里塞了工作站、测试虚拟机、外包人员的笔记本那么任何一台中了招的终端只要能路由到 443就能拿到主机的登录框。密码策略再强也只是难猜而不是不可达而把不可达作为第一道防线成本比改密码策略低得多效果也直接得多。我在实际环境里更愿意把这一步理解成减面先把能发起连接的地址砍到个位数剩下的才交给认证、审计、口令策略去处理。1.2 允许清单不是拍脑袋写出来的编制白名单这一步比敲命令重要得多因为它决定了后面会不会出现某个业务悄悄挂掉的连锁反应。我的做法是先画一张访问关系表把所有会主动连主机 443 的角色列全再逐个确认地址。下面这张表是我在实际项目里反复用过的最小集合你可以直接拿去做起点。访问角色典型用途是否需要放进 443 白名单vCenter Server纳管主机、下发任务、心跳必须漏掉就直接掉线运维跳板机 / 堡垒机人工登录 Host Client必须备份服务器部分备份产品经 443 调用接口大概率需要实测确认监控系统采集主机状态与证书信息经常需要自动化平台模板部署、配置下发按实际调用方式决定普通办公终端偶尔想连上去看看原则上不放这里有个很容易被忽略的细节监控和备份这两类角色的地址往往不止一个。有的产品是控制节点和介质节点分离部署的控制节点负责调接口工作节点负责传数据你只放了控制节点备份任务在数据阶段照样会报错而报错信息通常指向存储或者网络不会告诉你是你的防火墙白名单漏了一个地址。所以我在编制清单时习惯多问一句这个系统的所有节点地址都给我我要全部列出来。1.3 动手之前先给自己留三条后路这是我最想强调的一点也是踩坑之后才真正记住的教训改来源限制这个动作本质上是在给自己加锁你必须先确认手里有钥匙。带外管理服务器的管理卡 / KVM over IP能进 BIOS 和虚拟控制台这是终极后路改之前确认它的地址和密码是可用的。DCUI 能进也就是在物理控制台或者带外虚拟控制台上直接操作主机界面可以从里面启用 ESXi Shell 来救火。SSH 规则集和 Web 管理页面的规则集是两个独立的东西。只要你不去动 SSH 的规则集哪怕 443 白名单写错了你依然能通过 SSH 上去改回来。这一点非常关键很多人一激动把 SSH 也一起限制了然后就没有然后了。顺手把esxcli network firewall ruleset list的输出完整截图或者复制到本地存一份作为改坏之前的原始状态。这个习惯救过我一次当时我改的是老版本主机规则集名字和 8.0 上的不一样全靠对照原始输出才定位到问题。2. 把 ESXi 防火墙拆开看规则集、端口和允许清单2.1 三个概念层级理清了就不会改错对象ESXi 防火墙这套东西看起来命令不少其实只有三层结构理解了这三层命令基本不用背。第一层是规则集ruleset你可以把它理解成一个服务的名字比如 SSH、NTP、vMotion 各算一个。第二层是端口定义rule每个规则集下面挂着若干条端口记录说明这个服务实际占用了哪个协议、哪个端口。第三层是允许清单allowedip只对来源生效也就是这个服务到底允许哪些地址连进来。搞混这三层的人特别多。最常见的一种误操作是跑去改端口把 443 的服务给禁用了——那是把门焊死不是只让指定的人进。你要的是第三层把AllowedAll关掉再往允许清单里塞地址。用一句话概括这次的操作目标把承载 443 的规则集设成不允许全通然后把指定的地址加进它的允许清单。2.2 用 rule list 把端口翻译成规则集不同版本的 ESXi承载 Web 管理页面的规则集名字并不完全一致。6.x 时代你可能看到的是vSphere Web Access这种带空格的写法7.x 和 8.x 上更常见的是vSphereClient。名字记错了命令会报ruleset not found或者更糟——你改了一个同名但不同用途的规则集页面照样能访问你还以为生效了。所以我的习惯是先查再改永远不凭记忆# 列出所有规则集及其状态看 AllowedAll 那一列 esxcli network firewall ruleset list # 把所有规则集的端口映射打出来找出 443 属于哪个规则集 esxcli network firewall ruleset rule list | grep 443第二条命令是关键。它的输出里能看到规则集名、协议、端口号一行一行对应。你在结果里找到 443/tcp 那一行它左边的名字就是你要操作的对象。如果版本比较新命令支持直接过滤esxcli network firewall ruleset rule list --rulesetvSphereClient顺便说一句esxcli network firewall ruleset rule list的输出建议完整看一遍你会发现 902、8000、5989 这些端口分别挂在谁名下。这个认知在后面放行 vCenter 的时候会派上大用场——因为 vCenter 和主机的通信不止走 443。2.3 允许清单为什么写成 CIDR/32 和 /24 差别在哪允许清单里的地址不是裸 IP而是带掩码的写法比如10.20.30.15/32表示就这一个地址10.20.30.0/24表示这一整个 C 段。这是最容易放松警惕的地方写/24很方便但等于你把整个网段都放进来了如果这个网段里混着办公终端那这次加固的意义就打折了。我的原则是能用 /32 就用 /32确实是一批同类角色比如跳板机集群才用 /24 或者更小的范围。还有两个细节值得知道。第一允许清单是或的关系加多条就是多个来源都放通不存在优先级或者顺序覆盖的说法。第二允许清单变更之后已经建立的连接不一定会被判死刑。这点有时候是好事你的 SSH 会话不会断有时候是坏事你以为没生效其实只是老连接还在。所以验证的时候一定要用新连接去测别拿浏览器里那个还开着的旧标签页看结果。3. 只放指定 IP 访问 443 的完整操作路径3.1 定位目标规则集并核对其覆盖范围先把目标规则集的名字确定下来并且确认它到底覆盖了哪些端口。这一步做完之后再动手可以让后面的操作变得非常线性。# 确认名字 esxcli network firewall ruleset list | grep -i vsphere # 看这个规则集具体覆盖哪些端口确认 443 在里面 esxcli network firewall ruleset rule list --rulesetvSphereClient # 看当前的允许清单改之前留个底 esxcli network firewall ruleset allowedip list --rulesetvSphereClient如果grep出来不止一个相关名字就看哪个的端口列表里包含 443。有些环境里会出现vSphereClient和另一个规则集同时存在的情况只改一个可能不完整这时候两个都按同样方式处理即可。这一步多花的这两分钟能省掉后面两小时的排查。3.2 先加白再关全通顺序不能反顺序问题看起来是小事其实是会不会把自己锁在外面的分水岭。正确的顺序永远是先把需要放通的地址全部加进去最后一步才把AllowedAll关掉。# 第一步加白名单按角色逐个添加 esxcli network firewall ruleset allowedip add --rulesetvSphereClient --ip-address10.20.30.11/32 esxcli network firewall ruleset allowedip add --rulesetvSphereClient --ip-address10.20.30.12/32 esxcli network firewall ruleset allowedip add --rulesetvSphereClient --ip-address172.16.8.0/24 # 第二步核对白名单是否都写进去了数量对不上就别往下走 esxcli network firewall ruleset allowedip list --rulesetvSphereClient # 第三步确认无误后关掉允许所有来源 esxcli network firewall ruleset set --rulesetvSphereClient --allowed-allfalse有一个实战技巧值得分享如果你担心在关掉全通的那一瞬间出现意外可以把前两步和第三步写成一条命令中间用分号连起来一次性执行。这样即使你在执行过程中断线配置也已经完整落地不会停在一个白名单加了一半、全通还开着的中间态。esxcli network firewall ruleset allowedip add --rulesetvSphereClient --ip-address10.20.30.11/32; \ esxcli network firewall ruleset allowedip add --rulesetvSphereClient --ip-address10.20.30.12/32; \ esxcli network firewall ruleset set --rulesetvSphereClient --allowed-allfalse反过来如果真的要回退命令只有一条esxcli network firewall ruleset set --rulesetvSphereClient --allowed-alltrue这条命令建议记在备忘录里出事的时候脑子是空白的翻笔记比回忆靠谱。3.3 vCenter 纳管环境下必须同步放行的地址这是整件事里翻车率最高的地方。主机被 vCenter 纳管之后vCenter 就是它最主要的访客而 vCenter 访问主机用的端口不止 443。你把 443 收窄了但只放了自己的跳板机那么主机在 vCenter 里很快会变成无响应或者断开状态依赖主机的任务比如模板部署、快照任务、克隆会成批失败监控系统开始报主机异常告警风暴叠加上来你很难分清哪些是原因、哪些是后果。所以放行清单里必须包含 vCenter 所有节点的地址。如果 vCenter 是高可用部署或者由多个组件节点组成把每个节点的地址都加进去。另外如果环境里跑着 vSphere HA主机之间的心跳通信也要考虑通常走的是管理网络的地址有条件的话把整个管理网段加进来比逐个猜更稳代价就是白名单没那么干净。我的一般做法是把白名单分成三档来组织用注释在变更单里标清楚方便后面接手的人看懂分档地址范围说明核心平台vCenter 各节点 /32漏掉就掉线优先级最高运维入口跳板机 /32、堡垒机 /32人工操作的唯一入口支撑系统备份、监控节点 /32按实测调用关系决定特殊场景管理网段 /24仅在 HA 心跳等场景下放行3.4 从两侧各测一次才算验证完成改完之后验证必须做双边测试只测一边等于没测。在允许清单里的地址上curl -k -I https://10.20.30.10/ui/能看到正常的 HTTP 响应头就算通过。在不在清单里的地址上同样的命令应该直接连不上——表现可能是连接超时也可能是连接被拒绝两种都算通过具体是哪种取决于路径上的设备行为不用纠结。但有一件事必须确认那个被拒绝的地址之前是能连通的。如果你没有先验证它在改之前是可通的那现在不通可能只是本来就不通这个验证就没有意义了。我习惯在改之前先测一遍所有目标地址包括要被拒的把结果记下来改完之后再测一遍对照。看起来很笨但这是唯一能证明你的规则真的生效了的方法。4. 把自己挡在门外之后的排查链路4.1 现象一改完立刻连不上页面但 SSH 还活着这个现象最典型八成是两种情况之一。第一种是规则集名字写错了比如你按 7.x 的习惯敲了vSphereClient但主机是更早的版本实际名字不一样命令执行时其实报了错或者你以为成功了真正的规则集还开着全通或者被你改错了对象。第二种是你自己的地址压根没加进白名单或者加的时候掩码写错了比如应该写/32结果写成了/24之外的东西或者干脆把地址最后一段写成了别的数字。排查顺序很简单用 SSH 上去三条命令走一遍# 看目标规则集的 AllowedAll 是不是已经变成 false esxcli network firewall ruleset list | grep -i vsphere # 看允许清单里到底有谁逐条核对 esxcli network firewall ruleset allowedip list --rulesetvSphereClient # 看这个规则集覆盖的端口确认 443 真在里面 esxcli network firewall ruleset rule list --rulesetvSphereClient这三条命令的输出一对照问题基本就暴露了。我遇到过一次很隐蔽的情况清单里有一条10.20.30.0/24但我当时在用的是10.20.31.x网段的地址看起来网段很像实际上差了一整个 C。所以核对的时候不要用眼睛扫要用 ping 或者 curl 做交叉验证。4.2 现象二重启之后限制不见了ESXi 上的防火墙配置是写进配置库的正常的esxcli network firewall ruleset set和allowedip add操作会持久化重启之后依然生效。如果你发现重启后限制失效了通常不是没持久化而是有人或者某个自动化流程在启动过程中重新放开了配置或者你改的根本不是承载 443 的那个规则集。还有一种情况是用自定义 XML 文件扩展规则集的路子。ESXi 允许你在/etc/vmware/firewall/目录下放自定义的服务定义 XML然后用esxcli network firewall refresh重新加载。这种方式可以做得很细但也带来了一个新的坑这些自定义文件在系统升级或者某些重装场景下会被清掉。所以如果你用了这条路一定要在升级前备份目录升级后重新确认一遍。4.3 现象三vCenter 里的主机掉线告警开始刷屏这是最折腾的一种。你以为只是限制了一个页面的访问来源结果影响面扩到了整个平台。症状一般是主机在 vCenter 里显示断开或者无响应主机上的任务排队、失败HA 相关的告警开始出现。处理思路是分清楚原因和后果原因几乎一定是白名单漏了某个 vCenter 节点的地址或者漏了某个支撑系统的地址后果才是那一堆告警。这时候最快的恢复手段是把AllowedAll先改回true确认平台恢复正常然后再一条一条地加白名单每加一条观察一会儿。不要在告警风暴里继续猜先把环境恢复稳定再重新做规划。我经历过一次更隐蔽的vCenter 有两个节点我只加了主节点的地址备用节点没加。平时看不出问题直到某次主节点做维护、流量切到备节点主机才开始掉线。当时排查了半天最后是在白名单里对比两个节点地址才发现漏了一个。这件事之后我养成了一个习惯任何节点列表都必须去管理界面里核对实际数量不靠别人的口头描述。4.4 排查时用得上的命令与日志位置除了前面那几条esxcli命令排查时还可以看看主机上的日志会有更直接的线索。防火墙相关的记录、连接被拒的记录通常在系统日志里能翻到用tail配合关键字过滤是最快的做法# 看最近的系统日志 tail -n 200 /var/log/vmkernel.log # 看主机守护进程相关日志认证失败的记录经常出现在这里 tail -n 200 /var/log/hostd.log # 看防火墙的当前生效规则确认配置真的被加载了 esxcli network firewall getesxcli network firewall get会给出防火墙整体是否启用、默认行为等概览信息改完配置之后顺手跑一下能确认服务层面是活的。另外一个经验是怀疑配置没生效的时候用esxcli network firewall refresh重新加载一次然后立刻重测。这个动作不会破坏现有配置属于零成本的尝试。5. 把管理面收敛做得更彻底一点5.1 网络层隔离比防火墙白名单更根本防火墙白名单是主机自己守门而网络层隔离是根本不让门出现在别人面前。这两种做法不是替代关系而是叠加关系。我现在的习惯是管理地址全部放在独立的管理 VLAN 里只允许跳板机和 vCenter 所在的网段路由进来其他 VLAN 到管理 VLAN 的流量直接在网络设备上拒绝。这样即使某天主机的白名单配置被误改暴露面也不会扩散到整个内网。配套的还有几个小动作成本极低但收益明显主机管理地址不要和其他业务地址混在一个网段服务器的带外管理卡单独走一个网段跳板机的访问做一次双因素认证。这些都不属于 ESXi 本身的配置但它们和只开放指定 IP 访问 web 页面这件事是同一个思路的延伸值得一起做。5.2 自定义规则集开放受控的额外端口有些环境里主机跑着第三方代理组件需要在主机上开一个额外的端口同时又不能让所有人访问。这种情况可以用自定义 XML 的方式新建一个规则集再给它配来源白名单。做法就是在/etc/vmware/firewall/下新建一个描述文件内容大致如下ConfigRoot service idcustom-mgmt-api idcustom-mgmt-api/id rule idcustom-mgmt-api-tcp directioninbound/direction protocoltcp/protocol porttypedst/porttype port8443/port /rule enabledtrue/enabled requiredfalse/required /service /ConfigRoot保存之后执行esxcli network firewall refresh再用esxcli network firewall ruleset list看看新规则集有没有出现。出现之后按前面那套流程加白名单、关全通即可。这里要提醒一句required这个字段我一般保持false因为true的情况下如果这个规则集加载失败会影响防火墙整体加载没必要给自己埋雷。另外前面提过的这套自定义文件在升级后需要重新确认别指望它一劳永逸。5.3 多台主机的一致性怎么保证如果环境里只有一两台主机手工做一遍完全没问题。但如果是十几台甚至几十台手工操作就会出现每台配置略有差异的问题而这种差异在半年后是没人能说清楚原因的。我的做法分两步先用一个带参数的脚本把同样的操作批量跑一遍脚本里把白名单地址固化下来跑完之后再抽查三台用allowedip list的输出做对比确认每台的条数和地址都一致。脚本的核心其实就三件事加地址、列清单、关全通。真正的难点不在脚本本身而在于把白名单作为一份配置资产管理起来比如放在版本控制的仓库里谁改了什么、为什么改有据可查。这件事的意义在交接的时候体现得最明显——接手的人打开仓库就知道这台主机为什么放行了这几个地址不用去猜。5.4 变更时的联动清单每次调整白名单我都按下面这个清单走一遍尤其是环境比较复杂的时候。顺序不能乱因为前面的步骤是后面步骤的前提。步骤动作目的1确认带外、DCUI、SSH 三条后路可用确保改坏了能救回来2导出当前ruleset list与allowedip list留下可回退的原始状态3核对所有需要访问的角色与地址避免漏掉节点4先测一遍将被拒绝的地址是否本来可通保证验证有意义5逐个添加白名单并核对数量避免中文输入法式的低级错误6最后一步关闭全通减少中间态风险7双侧验证 观察平台告警一段时间确认没有连带影响6. 长期维护中容易被忽略的复核点6.1 版本升级之后一定要重新核对大版本升级是这套配置最容易出问题的时刻。规则集的名字、覆盖的端口范围、自定义 XML 的加载方式都可能在版本之间发生变化。我的经验是升级前先备份/etc/vmware/firewall/目录和当前的防火墙配置输出升级后不要把页面还能打开当成配置还在——AllowedAll有可能被重置回全通状态。正确的做法是升级完成、主机重新纳管之后重新跑一遍ruleset list和allowedip list逐条对比升级前的记录。这件事做起来只要几分钟但漏掉的代价可能是一个月的暴露期。顺便说一句升级前后顺手确认一下主机的证书状态也是好习惯。证书异常的时候某些管理接口的行为会变得很奇怪容易被误判成防火墙问题白花很多时间排查。6.2 交接文档里必须写下来的四件事这套配置的特殊之处在于它对知情者依赖很重——如果没人知道白名单为什么是这几个地址下一次变更就会变成互相猜测。所以我在交接文档里一定会写清四件事每一条白名单地址对应哪个系统、由谁负责允许清单的变更需要走什么流程回退的一条命令是什么以及自定义 XML 文件的位置和它在升级后的处理要求。这四件事看起来是管理动作但实际决定了这套配置能不能长期稳定地活下去。一个更实际的小建议把回退命令贴在主机自身的备注里比如写进你们内部的资产管理系统的主机描述字段。真出事的时候你可能连 SSH 都进不去只能在带外控制台前面用手机查资料那时候能快速找到一条能用的命令价值非常大。我个人在实际操作中的体会是这类限制来源的加固难点从来不在命令本身——真正花时间的部分全在动手前的清单编制和动手后的影响面确认。我现在的习惯是任何一次白名单调整都当成一次小型变更来做先写下我打算放通哪些地址、为什么是这些再动手。写了这一行字之后漏节点的概率会明显下降因为它逼着你把访问关系想清楚而不是凭手感敲命令。
阅读完成 · 觉得有帮助？
