【NSX入门黄金2小时】：仅需2台ESXi+1台NSX Manager，手把手搭建可验证的微隔离实验环境

更多请点击： https://kaifayun.com

第一章：NSX入门黄金2小时：从零构建微隔离实验环境

NSX 是 VMware 提供的软件定义网络（SDN）平台，其核心能力之一是实现基于策略的微隔离（Micro-segmentation），在虚拟化与云原生环境中提供精细化东西向流量控制。本章将带你用不到两小时，在本地 vSphere 环境中快速部署 NSX-T Data Center 3.2（或更新版本），完成基础控制器集群、传输节点注册及首个微隔离策略配置。

环境准备清单

• vCenter Server 7.0U3 或更高版本（已启用 vSphere Distributed Switch）
• 三台 ESXi 主机（6.7U3+，启用 N-VDS 支持）
• NSX Manager OVA（下载自 VMware Customer Connect，建议使用 3.2.3）
• 具备 root 权限的 SSH 访问能力及 curl 工具

一键部署 NSX Manager

导入 OVA 后，通过 vSphere Client 配置初始 IP、root 密码及主机名。首次登录 Web UI 后，执行以下 CLI 初始化（需替换为实际参数）：

# 在 NSX Manager CLI 中执行初始化
set user admin password 'VMware123!#'
configure ntp-server 0.pool.ntp.org
configure timezone Asia/Shanghai

该步骤确保时间同步与安全凭证就绪，为后续集群构建奠定基础。

创建传输区域与策略组

进入 Networking → Switching → Switching Profiles → Create → Segment Security Profile，启用“Apply micro-segmentation policy”。随后创建两个逻辑交换机（例如 web-tier、db-tier），并分别绑定至不同 Tier-0 网关下的子网。

定义微隔离策略示例

在 Security → Micro-segmentation → Create Policy 中，添加如下规则：

源组	目标组	服务	动作
Web-VMs	DB-VMs	TCP/3306	Allow
Any	Web-VMs	Any	Deny

验证隔离效果

在任意受控 VM 中运行：

# 检查 NSX 分布式防火墙日志是否生效
curl -k -u "admin:VMware123!#" https://<nsx-mgr-ip>/api/v1/ns-groups | jq '.results[].display_name'

返回结果应包含已定义的 NS 组名称，表明策略对象已成功同步至各传输节点。

第二章：NSX架构核心与组件部署实践

2.1 NSX逻辑架构解析：控制平面、数据平面与管理平面的协同机制

NSX采用三平面分离设计，各平面职责明确又深度协同。

平面职责划分

• 管理平面：提供UI/API接口，处理用户策略配置与生命周期管理；
• 控制平面：运行NSX Manager与Controller集群，负责分布式逻辑路由、安全策略编译与下发；
• 数据平面：由vSphere内核模块（VDS/VIF）及KVM/OVS代理构成，执行实际转发与策略 enforcement。

关键协同流程

策略同步示例

{
  "rule_id": "fw-001",
  "source_group": "web-sg",
  "destination_group": "db-sg",
  "service": "tcp/3306",
  "action": "allow"
}

该JSON经NSX Manager解析后，由Controller生成对应OpenFlow 1.3匹配项（`ip_proto=6, tp_dst=3306`），最终注入ESXi vSwitch的`nsx-vswitch`模块。

2.2 实验拓扑设计：2台ESXi+1台NSX Manager的最小高可用性验证模型

该模型聚焦轻量级验证，剥离冗余组件，仅保留核心控制平面与数据平面交互链路。

网络连接约束

• 两台ESXi主机必须位于同一二层广播域，确保NSX Manager可无NAT直连管理接口
• NSX Manager需配置静态IP并启用SSH与REST API服务

NSX Manager部署参数

参数	值
CPU	4 vCPU
内存	16 GB
磁盘	200 GB（厚置备）

初始化注册脚本

# 在每台ESXi上执行，注册至NSX Manager
esxcli network ip interface ipv4 set -i vmk0 -I 192.168.10.50 -N 255.255.255.0 -g 192.168.10.1
esxcli software vib install -v https://nsx-manager.example.com/nsx-esxi-7.2.0-12345678.vib --no-sig-check

该脚本首先配置管理网卡vmk0的IPv4地址，再通过esxcli安装NSX VIB模块； --no-sig-check用于跳过签名验证以适配实验室环境。

2.3 NSX Manager部署与初始配置：OVA导入、网络连通性校验与证书初始化

OVA导入与基础资源配置

在vSphere Web Client中通过“部署OVF模板”导入NSX Manager OVA，需严格匹配CPU（4vCPU）、内存（16GB）及磁盘（200GB）要求。网络适配器须绑定至管理VLAN，并分配静态IP。

网络连通性校验

# 验证NSX Manager与vCenter通信
ping -c 3 192.168.10.50  # vCenter IP
curl -k -I https://192.168.10.50/rest/vcenter/about  # 返回200 OK即成功

该命令验证NSX Manager能否访问vCenter REST API端点；-k忽略证书校验，-I仅获取响应头，避免传输大量body数据。

证书初始化流程

• 首次登录Web UI（https://<nsx-mgr-ip>）触发证书向导
• 选择“Generate self-signed certificate”或上传CA签名证书
• 系统自动将证书同步至所有已注册的NSX Edge节点

2.4 ESXi主机纳管与VIB安装：通过REST API与UI双路径完成Transport Node注册

REST API自动化纳管流程

curl -k -X POST \
  https://nsx-manager.example.com/policy/api/v1/infra/sites/default/enforcement-points/vmc-enforcementpoint/transport-nodes \
  -H "Content-Type: application/json" \
  -H "Authorization: Basic $(echo -n 'admin:password' | base64)" \
  -d '{
    "display_name": "esxi-01",
    "host_switch_spec": { "host_switches": [{ "host_switch_name": "nsxSwitch", "host_switch_profiles": [] }] },
    "node_deployment_info": {
      "ip_addresses": ["192.168.10.51"],
      "fqdn": "esxi-01.vmc.local",
      "deployment_type": "ESXI"
    }
  }'

该请求向NSX Manager发起Transport Node注册，关键参数包括 ip_addresses（ESXi管理IP）、 deployment_type（固定为ESXI）及 host_switch_name（需与后续VIB配置匹配）。

UI纳管与VIB安装验证

• 登录NSX Manager UI → Networking → Transport Nodes → Add Transport Node
• 选择ESXi集群或单主机，自动触发VIB（vmware-esx-vsip）下载与安装
• 状态变为Ready即表示VIB加载成功且主机已加入NSX转发平面

VIB安装状态对比表

VIB名称	版本要求	依赖模块
vmware-esx-vsip	≥ 7.0.3-1	vsip, nsx-ncp

2.5 Transport Zone与Host Switch创建：基于N-VDS的手动配置与自动发现对比验证

手动配置N-VDS Host Switch示例

nsxcli -c "host-switch create --display-name my-nvds --host-switch-profile-type uplink-vmnic --host-switch-profile-value uplink1 --transport-zone tz-1"

该命令显式绑定Uplink配置文件与Transport Zone，确保网络策略精准下发； --transport-zone参数必须指向已存在的TZ ID，否则创建失败。

自动发现模式关键差异

• 依赖NSX Manager对vSphere集群的vCenter事件监听
• 自动同步vDS/VDS变更并映射为N-VDS实例
• 不支持自定义Uplink Profile绑定顺序

配置模式对比表

维度	手动配置	自动发现
一致性保障	强（API级精确控制）	弱（依赖vCenter事件时序）
运维粒度	节点级	集群级

第三章：逻辑网络构建与基础连接性验证

3.1 逻辑交换机（Logical Switch）创建与分布式端口组映射实践

逻辑交换机创建流程

在 NSX-T Manager 中，逻辑交换机通过 REST API 创建，需指定传输区域和 IP 地址池：

{
  "display_name": "ls-web-tier",
  "transport_zone_id": "tz-5a8f2e1b",
  "ip_pool_id": "ippool-9c3d7a2f"
}

该 JSON 定义了逻辑交换机名称、绑定的传输区域及子网地址池，确保 L2 广播域隔离与自动 IP 分配能力。

端口组映射关键参数

字段	说明	取值示例
switching_profile_ids	应用的安全/QoS 配置集 ID 列表	["sp-001", "sp-002"]
replication_mode	洪泛模式：MTEP 或 STATIC	"MTEP"

验证映射状态

1. 调用 GET /api/v1/logical-switches/{id} 获取详情
2. 检查 realized_entities 字段确认分布式端口组同步完成

3.2 逻辑路由器（Tier-0/Tier-1）部署与OSPF/BGP基础路由注入验证

拓扑角色划分

Tier-0 负责南北向连接与动态路由分发，Tier-1 专注东西向微隔离与子网路由。二者通过 Router Link 逻辑直连，形成分层转发平面。

BGP 邻居建立示例

# 在 Tier-0 上启用 BGP 并宣告默认路由
set protocols bgp 65001 router-id 192.168.10.1
set protocols bgp 65001 neighbor 192.168.20.1 remote-as 65002
set protocols bgp 65001 network 0.0.0.0/0

该配置使 Tier-0 向上游物理路由器（AS 65002）通告缺省路由， network 0.0.0.0/0 触发 BGP 最佳路径计算并同步至 Tier-1。

OSPF 区域注入对比

参数	Tier-0 OSPF	Tier-1 OSPF
Area Type	Backbone (Area 0)	Normal (Area 1)
Route Redistribution	静态→OSPF	BGP→OSPF

3.3 虚拟机接入与跨子网连通性测试：ICMP+TCP端口级双向可达性验证

测试拓扑与目标设定

虚拟机（VM-A: 10.20.1.10/24）位于 subnet-A，服务端（VM-B: 172.30.5.20/24）位于 subnet-B，经三层网关互通。需验证 ICMP 基础连通性及 TCP 80/443 端口双向可达。

端口级连通性验证脚本

# 并行执行 ICMP + TCP 探测，超时统一设为3秒
for host in 172.30.5.20; do
  echo "[ICMP] $host"; ping -c 2 -W 3 $host && \
  echo "[TCP:80] $host"; timeout 3 bash -c 'echo >/dev/tcp/$0/$1' $host 80 && \
  echo "[TCP:443] $host"; timeout 3 bash -c 'echo >/dev/tcp/$0/$1' $host 443
done

该脚本使用 Bash 内置 TCP 重定向语法模拟连接，避免依赖 nc； timeout 3 防止阻塞， -W 3 控制 ping 等待时间，确保测试原子性与可重复性。

典型测试结果汇总

协议/端口	VM-A → VM-B	VM-B → VM-A
ICMP	✓ 成功	✓ 成功
TCP/80	✓ 成功	✗ 拒绝（防火墙策略限制入向）

第四章：微隔离策略落地与安全策略闭环验证

4.1 安全策略建模：基于标签（Tag）、IP集与VM组的三层策略抽象方法

传统ACL策略难以应对云环境动态拓扑，三层抽象解耦策略语义与底层资源绑定。

策略层级关系

• Tag层：业务语义标签（如env=prod、app=payment），支持自动继承与多维组合
• IP集层：网络地址集合（CIDR/主机IP），实现网络层归一化表达
• VM组层：虚拟机逻辑分组（按角色/生命周期/租户聚合），屏蔽底层ID变更影响

策略声明示例

policy:
  from: tag:app=frontend
  to: ipset:internal-services
  allow: [tcp:80, tcp:443]
  scope: vmgroup:prod-cluster

该YAML声明将前端应用标签与内部服务IP集关联，限定仅在生产VM组内生效； scope字段确保策略随VM组成员自动同步，避免手动维护IP列表。

抽象映射表

抽象层	典型属性	更新触发源
Tag	key=value对	CMDB变更/API打标事件
IP集	CIDR或IP列表	子网扩容/负载均衡器漂移
VM组	标签选择器+生命周期过滤	Autoscaling组伸缩/K8s Pod重建

4.2 分布式防火墙（DFW）规则编写与应用顺序深度解析

规则匹配优先级机制

DFW 规则按**自上而下、精确匹配优先**原则执行，首条匹配即终止匹配流程。策略层级：Section → Rule → Application。

典型规则定义示例

{
  "section": "web-tier-security",
  "rules": [
    {
      "name": "allow-https-to-app",
      "source": ["ip-set:app-servers"],
      "destination": ["ip-set:lb-pool"],
      "service": ["tcp:443"],
      "action": "allow",
      "logged": true
    }
  ]
}

该 JSON 定义了面向负载均衡器的 HTTPS 入向放行规则； source 和 destination 引用预置 IP 集， logged 启用审计日志，确保可观测性。

规则应用顺序验证表

序号	规则名称	匹配条件	动作
1	block-rdp-from-internet	src=0.0.0.0/0, dst=any, port=3389	deny
2	allow-api-internal	src=ip-set:backend, dst=ip-set:api-svc	allow

4.3 微隔离效果验证：使用nsxcli与pktcap-uw抓包分析策略命中路径

策略命中路径可视化验证流程

微隔离策略生效后，需通过底层数据平面确认实际匹配路径。NSX-T 提供 `nsxcli` 与 `pktcap-uw` 协同验证能力：

# 在目标ESXi主机执行，捕获源VM→目的VM的TCP流量
pktcap-uw --vmk vmk0 --srcIP 192.168.10.5 --dstIP 192.168.10.6 --proto 6 --capture --outfile /tmp/flow.pcap

该命令捕获经 vmk0 的指定 TCP 流量，`--proto 6` 精确过滤 TCP 协议，避免干扰；`--capture` 启用内核级流跟踪，确保策略决策点（如 Distributed Firewall）日志同步写入。

策略日志关联分析

• 使用 nsxcli -c "get firewall session-table" 查看实时会话匹配规则ID
• 比对 pcap 中 IP ID/TCP Seq 与 NSX Manager 中 /var/log/dfw.log 时间戳及 rule_id 字段

关键字段映射表

抓包字段	NSX策略日志字段	语义说明
ip.id	packet_id	唯一标识跨vSwitch转发的同一逻辑流
tcp.flags	action	Syn=ALLOW/DENY；Fin=TERMINATE

4.4 策略审计与日志溯源：通过NSX Intelligence启用流量可视化与异常行为标记

实时策略合规性验证

NSX Intelligence 自动解析分布式防火墙（DFW）规则与微分段策略，将策略执行流映射至实际东西向/南北向通信路径。其内置的策略影响分析引擎可识别“冗余规则”“冲突策略”及“未覆盖流量”。

异常行为标记机制

当检测到偏离基线的通信模式（如非预期端口扫描、横向移动尝试），Intelligence 会为对应 Flow 添加 `anomaly_score` 和 `risk_category` 标签，并推送至 vRealize Log Insight。

{
  "flow_id": "fl-8a9b1c2d",
  "anomaly_score": 0.92,
  "risk_category": "lateral_movement",
  "recommended_action": "isolate_source_vm"
}

该 JSON 片段由 NSX-T Manager 的 `/api/v1/nsxintelligence/anomalies` 接口返回；`anomaly_score` 为归一化置信度（0–1），`risk_category` 对应 MITRE ATT&CK 技术编号映射表。

审计日志关联视图

字段	来源系统	保留周期
Flow Start Time	ESXi vSwitch	7天
Policy Match Result	DFW Rule Engine	30天
Threat Intel Enrichment	VMware Carbon Black Cloud	90天

第五章：实验环境收尾与进阶学习路径

清理容器与持久化资源回收

执行以下命令安全卸载实验中创建的 Docker 卷和网络，避免残留资源占用磁盘与端口：

# 删除孤立卷（仅当未被容器引用时）
docker volume prune -f

# 清理自定义桥接网络
docker network rm lab-network demo-bridge

# 强制移除所有已停止容器（保留运行中的生产服务）
docker ps -aq --filter "status=exited" | xargs -r docker rm

配置备份与版本归档策略

• 将 docker-compose.yml、.env 及 Ansible playbook 目录提交至 Git 仓库，标签命名遵循 v0.3.2-lab 语义化格式
• 使用 tar -czf lab-env-$(date +%Y%m%d).tar.gz ./configs ./scripts 定期归档本地实验快照

推荐进阶学习方向

领域	实战项目	关键工具链
可观测性	部署 Prometheus + Grafana + Loki 实现日志/指标/追踪三合一监控	OpenTelemetry Collector, Tempo
服务网格	在 Kubernetes 集群中部署 Istio 并配置 mTLS 与金丝雀发布	Kiali, Envoy, cert-manager

自动化验证脚本示例