企业官网建设流程全解析

端口这个东西，平时没人惦记，一出事就是全链路的事。我印象最深的一次，是给一个新建的集群做网络分区，防火墙策略只放行了 443，结果 vCenter 登录正常，但虚拟机控制台打不开、迁移进度条卡在 0%、告警里时不时冒出一条主机失联。熬到后半夜才发现，漏掉的是 902、8000 这几个看起来"不重要"的口子。vCenter 和 ESXi 主机端口这套东西，单拿出来看是一张表，真正用起来却是整个虚拟化平台的通信设计图纸：谁连谁、走哪个方向、哪个端口必须常开、哪个端口可以按需关掉，想清楚这些，很多"玄学故障"其实都有迹可循。

这篇内容我准备按运维现场的思路来写：不堆砌官方端口表，而是从通信方向出发，把 ESXi 侧和 vCenter 侧的端口拆开讲清楚，再落到防火墙策略、连通性验证、证书过期这种真实场景上。适合正在规划虚拟化网络分区的人、做等保或内网隔离的安全同事、以及刚接手 vSphere 环境、被"任务卡住但没报错"折磨过的运维朋友。默认你对虚拟机、集群这些概念有基本认知，但端口细节我会从头讲。

1. 端口清单为什么是 vSphere 运维的基本功

1.1 端口在虚拟化架构里到底扮演什么角色

很多人把端口理解成"服务的门牌号"，这个类比只对了一半。在 vSphere 这种分层架构里，端口更像是分工明确的快递通道：443 走管理和 API 请求，902 走主机代理和控制台数据，8000 走内存状态的搬迁，3260 走存储块设备的读写。每一条通道承载的数据类型完全不同，丢包的后果也完全不同——443 不通，你连登录页都看不到；902 不通，页面能开但操作全废；3260 不通，主机看上去正常，虚拟机却批量变成"无法访问存储"。

这里有个容易被忽略的点：vSphere 的很多操作不是单一连接完成的。你在客户端点一下"打开控制台"，背后可能是先走 443 拿到票据，再走 902 建立到主机的会话，最后再拉一路控制台数据流。中间任何一环被拦，前端表现都不一样，但报错信息往往极其含糊，这就是为什么单纯看日志很难定位，必须回到端口和方向上来推。

我个人的习惯是：拿到一个 vSphere 环境，第一件事不是看版本号，而是先在纸上画三条线——管理线、平台内部线、数据线。三条线上分别跑哪些端口，画完基本就能预判后面 80% 的故障类型。

1.2 一份端口清单能解决的几类问题

把端口梳理清楚，收益远比"能连上"大得多。我总结下来主要是四类：

第一类是新建环境的防火墙规划。这是最正经的用途，在集群上线之前把源地址、目的地址、端口、协议写成策略，避免上线后再回头补规则——生产环境临时改防火墙，审批流程能拖到你怀疑人生。

第二类是故障排查的排除法。任务卡住、控制台黑屏、迁移失败、存储掉线，这些问题在应用层看是一团乱麻，但落到端口上往往就是一个方向没通。有过一份清单，你可以在五分钟内定位到"是 vCenter 到 ESXi 的 902 被我挡了"，而不是花两小时翻日志。

第三类是安全加固与暴露面收敛。ESXi 的 443 直接暴露在办公网，和放在运维跳板机后面，风险等级完全不同。搞清楚哪些端口是给管理员的、哪些是给平台内部用的、哪些是给外部依赖的，才知道该从哪里下手收敛。

第四类是版本升级前的兼容性核对。6.7 升 8.0 的跨度里，有些端口的行为发生了变化，有些旧服务被移除，照着老文档配的策略在新环境里可能就少了一条。

1.3 版本差异：从 6.7 到 8.0 的端口变化规律

严格说，VMware 每一代都会发布对应的端口与协议文档，数字会微调。但从 6.7 一路看到 8.0，变化是有规律可循的，抓住规律比死记数字有用：

趋势一，SLP 逐步退场。6.x 时代 427 端口承担的服务发现功能，在 7.0 之后基本被更现代的机制替代，新环境里这条规则通常可以不放。如果你是从 6.7 环境迁移过来的策略，里面大概率还留着一堆 427，属于历史包袱。

趋势二，Web 层端口在收敛。早期 vSphere Web Client 要单独占 9443，现在 443 统一承载大部分管理流量，外部只需要放行 443 加 5480（VAMI）就能覆盖绝大多数日常管理动作。

趋势三，内容库和更新相关的端口更受重视。离线升级、内容库同步这类操作在 7.0/8.0 里用得越来越多，对应的流出端口如果不通，表现是"上传镜像一直在转圈"而不是明确报错。

注意：不同小版本（比如 7.0 U2 和 7.0 U3）的端口表也可能有细微差别。生产环境落地前，务必以你实际部署版本的官方端口文档为准，本文给的是通用骨架，不是可以直接抄死的最终版本。

2. 先弄清楚谁连谁：方向比端口号更重要

2.1 管理面流量：客户端到 vCenter 与 ESXi

管理面是所有人最熟悉的一条线，也是最容易被过度放行的一条线。典型的流量方向是：管理员终端或跳板机 → vCenter 的 443，以及管理员终端 → ESXi 的 443。这两条都是"人"发起的，特点是流量小、偶发、可预测源地址。

这里有个常见误区：很多人觉得既然有 vCenter 了，就不需要直连 ESXi。但现实里主机故障排查、主机证书替换、单主机配置调整，都绕不开直接访问 ESXi 的 Host Client。我一般建议保留一条受控的直连通道，源地址限制到运维跳板机，而不是干脆全封。真出事的时候，vCenter 自己可能还在转圈呢，你只能靠直连主机救场。

另外，ESXi 的 80 端口通常只做跳转到 443，如果你的客户端习惯输http://前缀，这条也得留着，否则用户看到的是连接被拒绝而不是自动跳转。

2.2 平台内部流量：vCenter 到 ESXi、ESXi 到 ESXi

这条线是端口规划的重灾区，因为它不涉及"人"，出问题时没有人会主动告诉你"我连不上"。vCenter 到 ESXi 的通信主要有两个方向：管理指令走 443，数据通道走 902。你新建虚拟机、快照、迁移、改配置，全部依赖这两条。

ESXi 之间的通信主要是集群功能。vMotion 用 8000，vSphere HA 用 8182，容错（FT）用 8100、8200、8300 这几个。这一组端口的特点是必须在主机之间双向放行，而且源和目的都是 ESXi 的管理地址。我做过的项目里，最容易漏的就是 FA 和 FT 那几条，因为平时用不到，等到真的触发故障切换才发现欠债。

提示：这些主机间端口如果跨网段（比如集群主机分布在两个机架的不同子网），防火墙策略要双向放行，别只写一条单向规则。协议是 TCP，但实际会话建立是双向确认的。

2.3 数据面流量：存储、vMotion 与外部依赖

数据面是吞吐量最大、也最容易被网络团队质疑的一条线。NFS 走 111（rpcbind/portmap）加 2049，iSCSI 走 3260，这两个协议对丢包和时延都极其敏感。你在防火墙上做了严格的状态检测（比如很短的会话超时时间），存储流量可能出现间歇性卡顿，表现是虚拟机磁盘 IO 周期性抖动，这种问题查起来非常折磨人。

除存储之外，ESXi 还要访问一些外部基础服务：DNS 的 53、NTP 的 123、Syslog 的 514、以及接入 AD 域认证时的 88、389、464、636、3268、3269。这几条线的特点是流量小但关键，尤其 NTP，时间不同步会导致证书校验失败、AD 认证失败、日志时间线错乱，一串连锁反应。

2.4 用一张表把方向固化下来

把上面三类流量整理成"源→目的→端口→协议"四元组，是最实用的落地方式。我给一个骨架表，你在实际项目里把具体 IP 段填进去就能直接用：

这张表的价值在于，它把"端口清单"变成了"策略清单"，可以直接交给网络或安全同事执行，不需要他们理解 vSphere 内部逻辑。

3. ESXi 主机侧端口逐条拆解

3.1 管理入口三件套：443、902、427

443 是 ESXi 的总入口，承载 Host Client 界面、API 和 SDK 调用。这条不通，主机基本等于失联。它的特殊性在于，即使 vCenter 挂了，只要 443 通，你还能直连主机做应急操作。

902 是很多人低估的一条。它承载主机代理服务和控制台数据流，vSphere Client 打开虚拟机控制台、vCenter 执行部分操作都依赖它。我前面提到的"页面能开但操作全废"，几乎都是 902 被挡。判断方法很简单：登录 vCenter，打开某台虚拟机的控制台窗口，如果一直黑屏或提示连接失败，但主机状态正常，优先怀疑 902。

427 属于历史遗留，6.x 时代承载 SLP 服务发现，7.0 之后重要性大幅下降。新环境我一般不放行，但如果你的环境里还有老版本的 vCenter 或者其他依赖 SLP 的组件，就得留着。判断方法是看你的版本和组件清单，别想当然。

实践心得：443 和 902 我建议永远成对放行，不管你觉得自己会不会用到控制台。因为它们经常被同一个操作链路同时依赖，漏一个的效果和漏两个是一样的，但排查难度翻倍。

3.2 认证与目录服务：88、389、464、636、3268、3269

这一组端口在接入 AD 域的环境里必须放行，否则 ESXi 加域、vCenter 使用域账号登录都会出问题。它们的分工是：

• 88/TCP+UDP：Kerberos 认证，域名解析和时钟偏差都会影响它，属于典型"看起来跟网络无关实则死于网络"的端口。
• 389/TCP+UDP：LDAP，目录查询的主力。
• 636/TCP：LDAPS，加密目录查询，现在越来越多环境要求走这条。
• 464/TCP+UDP：Kerberos 密码修改。
• 3268/3269：全局编录查询，跨域场景需要。

这里有个很典型的坑：88 端口涉及 UDP，很多防火墙策略模板默认只放 TCP。你会看到域认证偶尔成功偶尔失败，或者只在某些主机上失败，查半天以为是账号问题，其实是 UDP 被吞了。我现在的习惯是，Kerberos 相关的策略明确标注"TCP+UDP 都要放"。

另一个坑是时间同步。Kerberos 对时钟偏差非常敏感，默认容忍范围很窄。如果 ESXi 的 NTP 没配好，88 端口明明是通的，认证还是失败。所以我在排查域认证问题时，第一件事是查时间同步，第二件事才是查端口。

3.3 集群与可用性：8000、8182、8100/8200/8300

这一组是集群功能的命脉，也是最容易在初次部署时被漏掉的。

8000/TCP是 vMotion 的数据通道。开启了 vMotion 但没放 8000，表现是迁移任务能创建、进度条缓慢推进、最后超时失败，报错信息通常指向"操作超时"或者"无法完成迁移"，非常不直观。更麻烦的是，如果配置了 vMotion 专用网段，这条端口要开在专用网段上，不是管理网段，别配错方向。

8182/TCP是 vSphere HA 的代理通信端口。HA 的作用是主机故障时自动重启虚拟机，属于"平时不用、关键时刻救命"的功能。我第一次独立搭集群的时候就没放这条，测故障切换的时候怎么都不触发，翻文档翻了半天才发现。HA 的端口在主机之间双向放行，源目的都是 ESXi 的管理地址。

8100、8200、8300是容错（FT）功能使用的端口。FT 提供的是比 HA 更强的保护——不只是重启，而是让主备虚拟机同步运行。它对网络质量要求极高，端口不放行直接导致 FT 无法启用。如果你的环境根本不用 FT，这几条可以不放，但要记得在文档里标注"未启用 FT，相关端口未放行"，避免以后接手的人困惑。

3.4 存储协议：111、2049、3260

存储相关的端口数量少，但对网络质量要求最高。

NFS 走 111（rpcbind，同时需要 TCP 和 UDP）和 2049。111 的作用是端口映射查询，有人觉得可以省略直接只放 2049，实际操作中会遇到挂载偶尔失败的情况，因为某些流程仍然需要查询 rpcbind。我的建议是两个都放，代价很小。

iSCSI 走 3260。它的特殊性在于有两种连接方式：一种是主机作为发起端主动连接存储的 target，防火墙放行出方向 3260 就行；另一种是通过软件 iSCSI 适配器配置，配置过程中还有别的交互。如果存储和主机在同一个二层域，一般不需要防火墙参与；跨三层域就必须规划这条规则。

对存储流量，我强烈建议在防火墙上放长会话超时时间，或者干脆对这条规则关闭深度包检测。存储协议对时延极其敏感，安全设备做了严格检测会引入抖动，表现是 IO 周期性变慢，查起来非常痛苦。

3.5 辅助服务：123、514、5988/5989 与 DNS

123/UDP是 NTP。这条我不多解释重要性，只强调一点：ESXi 的时间来源要和 vCenter、域控保持一致，否则你会在证书、认证、日志三个地方各踩一次坑。

514是 Syslog，UDP 最常见，也最容易丢包。做合规环境建议用 TCP 514 或者走加密通道的端口，避免日志缺失导致审计时抓瞎。

5988/5989是 CIM/WBEM 服务，硬件监控用。如果你的监控平台要采集主机的硬件健康状态（温度、风扇、电源、RAID），这两条要放行，5989 是 HTTPS 版本。不放的话监控平台看不到硬件告警，属于"功能静默失效"的典型。

53是 DNS，虽然属于基础服务，但 ESXi 的很多操作都依赖域名解析。主机名解析不了，会导致证书校验、vCenter 注册、AD 认证接连出问题。我在环境里见过 DNS 记录没及时更新，结果换了一台主机名后各种莫名其妙的报错。

4. vCenter Server 侧端口与组件依赖

4.1 vCenter 服务端口总览

vCenter 8.0 已经是一个跑在 Linux 上的大型服务集合，端口数量比 ESXi 多得多。但随着版本演进，对外暴露的端口在收敛，内部服务之间用大量本地端口通信，不需要在防火墙上放行。

对外必须关注的几条：

注意：vCenter 是设备形态（VCSA）还是 Windows 安装形态，端口表差别很大。现在主流是 VCSA，Windows 形态基本进入维护期。本文默认按 VCSA 讲，如果你的环境还是 Windows 版 vCenter，务必查对应版本的文档，外部数据库、SQL 连接这些端口在 Windows 形态里是必须单独规划的。

4.2 SSO 与目录服务相关端口

vCenter 的 SSO（单点登录）是整个管理平台的认证基石。它内部依赖一套目录服务，涉及 2012、2013、11711、11712 这些端口。这些端口通常只在 vCenter 组件之间通信，不需要对外开放，但如果你做的是多节点部署（比如增强链接模式），节点之间要放行这些，否则会出现"某个节点上的用户登录不上、权限同步异常"之类的怪现象。

对接 AD 域的端口和 ESXi 类似，重点是 Kerberos 的 88（TCP+UDP）和 LDAP 的 389/636。这里有个经验：如果你用的是 LDAPS（636），需要先把域控的 CA 证书导入到 vCenter 的信任库，否则连接会因为证书不受信任而失败，报错指向认证失败，实际原因是证书，不查证书永远查不出来。

4.3 VAMI、内容库与更新相关端口

5480 是 VAMI 的入口，用于设备级操作：网络配置、时间配置、备份恢复、补丁升级、SSH 开关。这条端口建议限制源地址，因为它的权限等级很高，暴露到办公网不合适。我自己维护的环境里，5480 一律只对运维跳板机开放。

内容库和更新相关的端口在离线环境里用得比较多。上传 ISO、同步模板、打补丁，都涉及文件传输。这条流量的特点是数据量大、耗时长，防火墙的会话超时要设长一些，否则表现为"传了一半断了"，重传又从头开始。

4.4 证书相关端口与过期排查思路

证书过期是 vCenter 环境里最典型的"连锁故障"。表现通常是一连串奇怪的问题：登录报证书错误、主机显示已断开、部分功能灰掉、某些页面直接 500。根本原因往往是 ST日常用的 STS 证书或者主机证书到期了。

排查思路我一般这么走：

第一步，登录 VAMI（5480），在证书管理页面查看所有证书的到期时间。这一步能一次性看到全貌，比一条条命令查快。

第二步，如果 VAMI 也进不去（证书问题严重时确实会这样），就 SSH 到 vCenter，用命令行工具查看证书状态。注意看是 STS 证书、机器 SSL 证书还是解决方案用户证书出的问题，处理方法不一样。

第三步，续期或替换后，检查主机侧的证书状态。主机证书和 vCenter 证书是两套东西，vCenter 修好了不代表主机也好了。ESXi 的证书如果过期，主机会在 vCenter 里显示"证书状态异常"，需要重新注册或者单独续期。

第四步，验证所有依赖 TLS 的端口是否恢复正常，重点是 443、902、以及各类 API 调用。这一步我习惯用一个自动化脚本批量探测，比手工点界面可靠。

4.5 外部依赖与备份恢复的端口考量

如果有外部备份系统、监控系统、日志平台接 vCenter，需要规划它们到 vCenter 443 的访问，以及相应的 API 权限。这类流量往往是长连接或周期性轮询，防火墙的并发会话数要留够，别让监控把连接数占满了影响正常管理操作。

vCenter 的备份也是走 5480 或命令行，备份文件可以用 SMB、NFS、FTP、HTTPS 等方式传到远端。这些传输方式的端口要单独规划，尤其是 HTTPS 方式复用 443 但方向相反，容易被忽略。我在项目里见过备份任务一直失败，最后发现是 vCenter 出方向到备份服务器的 443 没放行。

5. 落地实操：把端口清单变成可执行的防火墙策略

5.1 分区与策略设计思路

我推荐的分区方式是三层：管理区、计算区、存储区。管理区放 vCenter 和运维跳板机，计算区放所有 ESXi 主机，存储区放存储设备。分区之后，策略就变成"区间流量"的问题，比按单个 IP 写规则清晰得多，后期扩容也只需要往区里加地址。

策略的粒度我建议按功能分组而不是按端口号分组。比如"vSphere 管理"这一组包含 443、902、5480，"集群通信"包含 8000、8182、8100-8300，"存储访问"包含 111、2049、3260。这样在评审时，讨论的是"要不要允许集群通信"，而不是"要不要开 8000"，沟通效率完全不一样。

提示：策略命名里把用途写进去，比如ESXi-CLUSTER-双向-8000-8182。半年后接手的人（包括你自己）看名字就知道能不能删，比看端口号猜用途靠谱得多。

5.2 用 ESXCLI 和 PowerCLI 导出端口现状

纸上规划完，要落地到实际环境，第一步是摸清现状。ESXi 上的防火墙规则集和连接状态可以这样查：

# 查看防火墙当前状态和规则集清单 esxcli network firewall get esxcli network firewall ruleset list # 查看某个规则集的详细信息，比如 vMotion esxcli network firewall ruleset rule list --ruleset-id=vMotion # 查看当前活动连接（排查谁在连、连到哪） esxcli network ip connection list

这几条命令的输出信息量很大，ruleset list会告诉你每条规则集是否启用，connection list能看到实时的 TCP/UDP 连接和对应进程。我排查"主机被别人扫"或者"某端口有异常连接"的时候，基本都从connection list开始看。

PowerCLI 侧批量导出多个主机的信息：

# 连接 vCenter Connect-VIServer -Server vc.example.com -User administrator@vsphere.local # 批量获取所有主机的防火墙规则状态 Get-VMHost | ForEach-Object { $esxcli = Get-EsxCli -VMHost $_ -V2 [PSCustomObject]@{ Host = $_.Name Rulesets = ($esxcli.network.firewall.ruleset.list.Invoke() | Where-Object {$_.Enabled -eq $true}).Name -join ',' } }

这两段脚本的实际价值是：在改防火墙之前，先知道每台主机开了哪些规则集。如果某台主机无意中开了 HTTP 客户端之类的规则，而其他主机没开，那台主机可能就是配置漂移的源头。

5.3 连通性验证的几种可靠方法

策略上线之后必须验证，而且要覆盖相关方向的每一个端口，不能只测 443 就算完。

Linux 侧用 nc 或 curl：

# 测试 TCP 端口连通性 nc -zv 10.0.0.10 443 nc -zv 10.0.0.10 902 # 测试 TLS 握手是否正常（证书问题会在这里暴露） openssl s_client -connect 10.0.0.10:443 -servername 10.0.0.10 # 测试 HTTP 层响应 curl -k -I https://10.0.0.10/ui

Windows 侧用 PowerShell 的 Test-NetConnection：

Test-NetConnection -ComputerName 10.0.0.10 -Port 443 -InformationLevel Detailed Test-NetConnection -ComputerName 10.0.0.10 -Port 902

我的验证顺序是：先测端口通不通，再测 TLS 握不握得上，最后测应用层响应。三步全过才算真的通。很多人只做第一步，结果端口通但证书不受信任，应用层依然失败，白高兴一场。

5.4 变更窗口与回滚预案

防火墙策略变更一定要有回滚预案，这不是形式主义。我个人的做法是：变更前用不涉及防火墙的方式留一条带外通道（比如主机单独的带外管理口、或者 iLO/iDRAC 这类管理网口），确保哪怕策略写错了也能救回来。

变更顺序上，我倾向先放行后收窄：先按较宽的范围放行，确认业务正常，再逐步收窄到精确的源地址和端口。反过来做风险大得多，一旦收过头，你连进都进不去，只能靠带外通道恢复。

注意：ESXi 的防火墙和你网络侧的硬件防火墙是两回事。ESXi 自己有一套防火墙规则集，新装主机上很多规则集是开启的。你在网络侧收紧的同时，也要检查主机侧的规则集状态，两边要一致，否则会出现"网络侧放行了但主机自己挡住"的情况。

6. 常见问题与排查实录

6.1 无法进入 ESXi 管理界面

这个问题的排查顺序很明确：

第一，确认网络可达。ping 主机管理地址，如果不通，先查网络配置是不是被改过。

第二，确认 443 端口通。用 nc 或 Test-NetConnection 测，不通的话，查网络侧策略和主机侧防火墙规则集，两边都要看。

第三，如果端口通但页面打不开，看 TLS 握手。用 openssl s_client 测，报证书错误说明主机证书有问题，需要重新生成或续期。

第四，如果 TLS 正常但页面报错，查主机服务状态。SSH 到主机（前提是 SSH 已启用），用services.sh status或查看 hostd、vpxa 这些关键服务的运行状态。

我遇到过最坑的一种情况是：主机管理地址改了，但 DNS 记录没更新，客户端用域名访问解析到旧地址，表现像"管理界面打不开"，实际是压根连错了机器。

6.2 vCenter 证书过期后的连锁反应

证书过期最麻烦的地方在于，它的表现太分散，容易让人误判成多个独立故障。典型表现包括：登录时提示证书警告、某些页面直接 500、ESXi 主机显示"已断开"、部分功能菜单变灰。

处理顺序我建议是：先在 VAMI 里确认到底哪些证书过期，再决定是续期还是替换，最后逐项验证依赖关系。续期相对简单，替换则涉及 STS 证书、机器证书、解决方案用户证书的多轮操作，需要有耐心按文档一步步来，中途不要跳步。

有个细节很多人不知道：vCenter 证书替换后，每台 ESXi 主机也需要重新建立信任。我一般会在替换后，从 vCenter 对所有主机执行一次重新连接或者证书修复操作，确保状态回归正常。

6.3 虚拟机操作超时、任务卡在某个百分比

任务卡住是最难查的一类问题，因为它没有明确报错。我的排查框架是：

• 卡在 0% 到 10%：多半是认证或建立连接阶段的问题，怀疑 443 和 902。
• 卡在中间偏后：可能是数据通道问题，怀疑 vMotion 相关的 8000，或者存储相关的端口。
• 卡在 90% 以上：往往是收尾阶段的确认消息过不去，怀疑主机之间的 8182 或者 vCenter 回连主机的端口。

这个框架不是绝对的，但它能帮你快速缩小范围，比漫无目的地翻日志高效得多。

6.4 存储挂载失败、主机看不到存储

存储问题的排查顺序：先确认主机和存储之间的网络可达（ping），再确认 111、2049、3260 这些端口通，再看主机上的存储适配器状态，最后查存储侧的访问控制（比如 iSCSI 的 ACL 有没有加主机地址）。

我印象很深的一次，主机能看到 iSCSI target，但就是登录不上。最后发现是存储侧只允许了主机的某个地址，而主机用了另一个网口做 iSCSI，源地址对不上。这类问题在端口层面看不出异常，属于访问控制层面的坑，排查时不能只盯着端口。

6.5 常见问题速查表

7. 端口加固与运维心得

7.1 最小暴露面怎么收

加固的核心思路是"能不放就不放，能限源就限源"。具体到 vSphere，我会这么做：

5480（VAMI）只对运维跳板机开放，这条毫无例外。它的权限太高，暴露面收得越紧越好。

ESXi 的 443 尽量不直接对办公网开放，统一通过跳板机访问。确实需要某些运维同事直连的，把源地址限制到具体网段。

能找到替代的旧端口就关掉。427 这种在 7.0 之后基本没用的，直接不放。数据库、SSH、CIM 这些按需开放，不开就是不开。

一个容易被忽略的点是出方向也要收。ESXi 主机主动往外的连接，比如心跳回传、日志上传、时间同步，也应该限定到具体目的地址，避免主机被攻破后向外扩散。

7.2 变更后的验证清单

每次改完防火墙策略，我会跑一遍固定清单：

端口层面，逐个测试关键端口（443、902、8000、3260、53、123）的通断。

应用层面，登录 vCenter、打开一台虚拟机控制台、做一次小规模的迁移测试、查看主机证书状态、检查监控平台能否正常采集。

功能层面，如果环境用了 HA，做一次模拟触发；如果用了内容库，做一次小的上传同步。

这份清单看起来繁琐，但它能把"我以为通"变成"确认通"，省下的事后排查时间远超验证时间。

7.3 我踩过的几个坑

坑一：只放 TCP，忘了 UDP。DNS 的 53、Kerberos 的 88、NFS 的 111 都要 UDP，漏了会表现为"偶发失败"，最难查。

坑二：只放单向，忘了双向。集群通信、主机间通信都是双向的，单向规则的表现在于任务能开始但走不完。

坑三：改了网络侧防火墙，忘了 ESXi 自身的规则集。主机自己有一套规则集，两边状态要一致，否则会出现"网络侧明明通了但主机就是不理你"。

坑四：证书问题被当成网络问题。端口通、TLS 握手失败，第一反应应该是查证书，而不是继续查防火墙。

坑五：存储规则套用了通用模板。通用模板的会话超时和深度检测策略，对存储流量太激进，会引入抖动。存储规则要单独调优。

这套端口相关的经验，其实还能往几个方向延伸：一是自动化巡检，把端口探测和证书到期检查写进日常脚本；二是和 CMDB 结合，把端口策略变成可以版本管理的配置项；三是把本文这套方向分类的思路，套用到其他虚拟化或容器平台的网络规划上。不过这些展开又是一整篇内容了，先把基础的端口清单和执行策略理顺，才是最先该做的事。