Azure Stack Hub 网络服务管理工具与常见问题排错（下篇）

未经同意，请勿转载！

本篇定位：面向 Azure Stack Hub 一线运维 / SOC / 监控 / 故障响应工程师。本文承接上篇《Azure Stack Hub 网络服务：从物理拓扑到租户 SDN 完整图谱》中网络模型部分，重点展示如何在生产中观测、运维、排错 Azure Stack Hub 的网络栈。

上篇回顾：上篇讲的是"网络是怎么搭的"——物理拓扑 / SDN 逻辑网络 / 租户 IaaS 对象 / DNS / Gateway / 混合连接。本篇讲的是"出问题时怎么查、怎么改、怎么监控"——四类核心组件的监控、容量告警、四类典型故障（VIP 连通 / 出栈 / DNS / VPN）的排查手法、以及最后一公里的日志收集。

版本基础：与上篇一致，基于azs-1901 至当前主流 azs 版本的 Azure Stack Hub Operator 文档整理。不同 OEM 集成系统以及不同 azs 版本之间可能存在差异；当版本与本文表述不一致时，以当期版本 Azure Stack Hub Operator 文档为准。

本文不展开的边界：① 物理网络交换机 / ToR / BMC 的故障更换流程 ② Az PowerShell 模块的完整安装步骤 ③ Microsoft 内部 Support 工单流程 ④ 与 Azure 公有云一致的通用网络理论（OSI / TCP / DNS / DHCP 等不在本文逐条展开）

修订说明：

本篇为Azure Stack Hub 网络服务管理与排错的新章首发，基于材料（内训课程 - "Azure Stack Hub 网络服务"）中排错章节整理，按档编写准则做工程化改写。

目录

1. Azure Stack Hub 网络栈的四类核心组件

2. 网络服务管理工具的能力矩阵

3. 网络健康监控告警：门户怎么显示 + 怎么修

4. 公共 IP 池容量告警：70% / 90% / 100%

5. 故障前的预防清单：四类检查

6. 故障现象 1：VIP 连通性失败

7. 故障现象 2：出栈 NAT 无法访问 Internet

8. 故障现象 3：DNS 解析失败

9. 故障现象 4：边缘网关 / VPN 异常

10. 四个常见误判信号

11. 日志收集：Get-AzureStackLog

12. 运维节奏：上线 / 巡检 / 处置 / 复盘

13. 下篇小结

1. Azure Stack Hub 网络栈的四类核心组件

Azure Stack Hub 把网络栈的责任切给了四个核心组件。理解这个分工，是看懂后续监控告警、排错流程的基础。

1.1 四个核心组件角色速查

1.2 责任划分：控制面 vs 数据面

[用户 / 租户] └─ ARM API ─► [NRP] ─► [NC] ─► [SLB MUX / vSwitch / Gateway] │ │ │ │ │ │ │ └─ 数据面（实际转发流量） │ │ └─ SDN 控制面（调度 + 健康检查） │ └─ 资源对象生命周期管理 └─ 用户入口

为什么要分清楚：

• 数据面故障（如 SLB MUX 进程崩溃）→网络转发中断，但新资源创建不受影响；

• 控制面故障（如 NC 失联）→所有 SDN 转发降级或停止；

• 资源管理面故障（如 NRP 失联）→新资源无法创建 / 修改，已有资源仍可工作。

1.3 "基础设施角色"与"租户资源"的关系

L2 微软实现

Azure Stack Hub 把 NC / SLB MUX / Gateway 等组件作为基础设施角色（Infrastructure Role）运行，租户看不到这些组件本身——只能在 Operator 门户的"区域管理 / 系统运行状况"里看到它们的状态。这个分层是 L0 官方设计选择，租户只能通过 NRP 与 SDN 间接使用这些能力。

2. 网络服务管理工具的能力矩阵

三个层次的能力矩阵：资源可用性 / 系统监控 / 网络服务提供者，对应三个工具集合。

2.1 三层工具矩阵速查

2.2 工具集合的具体形态

L0 版本事实

3. 网络健康监控告警：门户怎么显示 + 怎么修

3.1 健康告警的呈现位置

L0 版本事实——明确表述

网络服务的健康监控告警显示在Operator 门户 → 区域管理中：

• 告警内容包含：

  1. 系统运行状况警报—— 哪个组件失联 / 异常；

  2. 如何修复建议—— Microsoft 内置的 runbook，给出修复操作指引；

  3. 允许服务管理员通过管理门户自行修复—— 这是 Microsoft 设计哲学：常见问题让运营商自助修复，只把"复杂 / 硬件级"问题升级到 Support。

3.2 健康告警的典型场景

3.3 ⚠️ "门户说告警"的常见误用

L3 最佳实践

• 不要直接根据告警点击"修复"按钮——先看告警描述，判断是临时抖动还是持续异常；

• 多次出现的同类告警才算"持续问题"，单次抖动通常无需干预；

• 告警 ≠ 故障——某些告警是为了提醒（如"NC 证书将在 7 天后过期"），而不是"已出故障"。

4. 公共 IP 池容量告警：70% / 90% / 100%

精确的容量告警阈值表——这是 L0 官方事实（Microsoft 在 Operator 文档中明确给出的阈值），本文保留。

4.1 三级容量告警阈值

4.2 为什么是 70% / 90% / 100% 三档

L0 官方事实

直接原因："由于获取公共 IP 地址块需要时间，因此在 70%、90% 和 100% 阈值处会有警报"。

• 70%= 第一次提醒（你有时间）——从 ISP 申请新 IP 段需要走流程（合同 / 路由通告 / BGP 重配 / 防火墙白名单），可能耗时数天到数周；

• 90%= 第二次提醒（很紧急）——剩余 10% 很快耗光；

• 100%= Critical（已经出故障）——租户开始无法创建资源。

4.3 容量告警处置流程

[1] Operator 门户 - 区域管理 - 容量管理 │ ▼ [2] 公共 IP 池 - 查看使用率 │ ├── < 70% → 归档关闭，无需操作 ├── ≥ 70% → 从 ISP 申请新 IP 段（建议至少 /24） ├── ≥ 90% → 紧急申请，标记为 P1 工单 └── = 100% → Critical，立即扩容（参考已有 PPT 输出指标） │ ▼ [3] 扩容操作 = 扩展操作 → 提供新 IP 段（CIDR + 起始 IP）→ 提交 │ ▼ [4] NRP 自动把新 IP 段加入公共 IP 池 │ ▼ [5] 验证：Operator 门户 - NRP - 公共 IP 使用情况 - 利用率下降

4.4 ⚠️ 静态路由环境的容量扩容陷阱

关键陷阱（与上篇 §8.3 对应）

如果网络拓扑里选择了静态路由而不是 BGP 路由公共 IP：

• 添加新公共 IP 段后，必须为每个新 IP 在数据中心交换机上手动添加静态路由——这是上篇 §8.3 的延续；

• 扩容前先确认客户是 BGP 还是静态路由——这是容量规划阶段的遗留问题，新建系统建议 BGP。

5. 故障前的预防清单：四类检查

L3 最佳实践

预防 > 排错。在生产上线前 / 容量变更前 / 版本升级前，应做四类检查：

5.1 物理网络巡检

5.2 SDN 资源健康

5.3 容量预警

5.4 版本与补丁

6. 故障现象 1：VIP 连通性失败

最常见故障之一

VIP 是租户对外服务的唯一入口；VIP 不通意味着所有外部访问都受影响。

6.1 故障诊断流程图

[租户报告：我的网站打不开了] │ ▼ [1] 验证 VIP 自身可达性 测试方法：Test-NetConnection -ComputerName <VIP> -Port <Port> │ ├── TCP 端口通 → VIP 工作正常，转查后端 ├── TCP 端口失败 → 继续 │ │ │ ▼ │ [2] 验证后端 VM 自身是否在运行 │ Operator 门户 / SCVMM - 检查 VM 状态 │ │ │ ├── VM 停止 → 启动 VM │ ├── VM 运行 → 继续 │ │ │ ▼ │ [3] 验证后端 VM 的端口是否在监听 │ RDP 到 VM，netstat -an | findstr :<port> │ │ │ ├── 不监听 → 检查应用配置 / 服务状态 │ ├── 监听 → 继续 │ │ │ ▼ │ [4] 验证 NSG / 后端 ACL 是否允许 │ 检查 Backend NSG 的入站规则 │ │ │ ├── 拒绝 → 修正 NSG │ ├── 允许 → 继续 │ │ │ ▼ │ [5] 验证 SLB 后端池是否健康 │ Operator 门户 / PowerShell - SLB 健康探测 │ │ │ ├── 不健康 → 检查 health probe 配置 │ └── 健康 → 检查 NSG / 入栈 NAT 规则 │ │ │ └─→ 进入下篇 §数据面抓包 │ └── PING 失败 → 【正常】！SLB 不支持 ICMP，详见 §10

6.2 五步定位表

6.3 关键事实（避免误判）

L1 微软硬要求

VIP 由 SLB 管理，只支持 TCP / UDP，不支持 ICMP——这是关键提示：

• 所以即使一切配置正确，从外部 PING VIP 也会失败；

• 不要把 PING 失败当成"VIP 不通"；

• 正确的连通性测试是Test-NetConnection -Port而不是Ping。

6.4 修复常见模式

7. 故障现象 2：出栈 NAT 无法访问 Internet

7.1 故障诊断流程图

[租户报告：我的 VM 访问不了 Internet] │ ▼ [1] VM 是否有 Public IP？ Operator 门户 → VM → 网络接口 → IP 配置 │ ├── 有 PIP → 用自己的 PIP 出栈（参照 §14 上篇） ├── 无 PIP → 继续 │ ▼ [2] 该 VM 所在 vNet 是否有 vNet NAT IP？ Operator 门户 → NRP → vNet → 出栈配置 │ ├── 有 NAT IP → 用 vNet NAT IP 出栈 │ │ │ └─→ 检查：是否真的访问了 Internet？tracert 看路径 │ │ │ └── 路径过 ToR → 出栈正常，问题可能在远程端 │ ├── 无 NAT IP → 继续 │ ▼ [3] 公共 IP 池是否耗尽？ Operator 门户 → 容量 → 公共 IP 池 │ ├── 100% Critical → 立即扩容（详见 §4） ├── < 100% → 继续 │ ▼ [4] 默认出栈 NAT 是否被关闭（罕见） Operator 门户 → NRP → vNet → 出栈 NAT 开关 │ ├── 关闭 → 打开出栈 NAT └── 开启 → 检查 vSwitch / NSG

7.2 关键问题清单

7.3 出栈 NAT 的两个常见误判

L3 最佳实践

1. "没配网关怎么出去"—— 上篇 §4 已说明，Azure Stack Hub默认启用vNet 级出栈 NAT，租户不需要配置网关；

2. "PING 公网 IP 不通 ≠ 出栈故障"—— 即使出栈正常，公网也会因为防火墙 / ICMP 过滤而不响应 PING。应该用curl https://www.bing.com或Test-NetConnection bing.com -Port 443来验证出栈。

8. 故障现象 3：DNS 解析失败

8.1 故障诊断流程图

[租户报告：我的 VM 解析不了域名] │ ▼ [1] 验证 ping IP 通不通 │ ├── IP 通 → 出栈正常，问题在 DNS ├── IP 不通 → 转 §7 出栈 NAT │ ▼ [2] 验证 DNS 服务器是 168.63.129.16 来自 VM：`ipconfig /all` │ ├── 自定义 DNS（如租户手填）→ 临时改为 168.63.129.16 重试 ├── 默认 → 继续 │ ▼ [3] 测试到 MAS-DNS 的连通性 `Test-NetConnection 168.63.129.16 -Port 53` │ ├── 通 → DNS 服务器响应 ├── 不通 → 继续 │ ▼ [4] 查询名称类型？ │ ├── Azure Stack Hub 内部名称（如 *.azurestack.local） │ → iDNS 应能解析 ├── 外部名称（如 www.bing.com） │ → 检查 DNS 转发器 / 数据中心上游 DNS │ ▼ [5] 如果是 Azure Stack 内部名称 → 检查 iDNS Forwarder 配置 如果是外部名称 → 检查数据中心上游 DNS / DNS 转发器可达性

8.2 关键问题清单

8.3 DNS 排错的常见误判

L3 最佳实践

• 租户手改 DNS 服务器 → 失败—— 默认指向 168.63.129.16；

• 添加"自定义 DNS"作为 vNet 设置 → 可能丢 iDNS 递归解析—— 自定义 DNS 仅在租户 VM 内生效，iDNS 的递归 DNS 解析能力丢失；

• 外部名称解析失败 ≠ Azure Stack Hub 故障—— 可能是上游 DNS 转发器问题。

9. 故障现象 4：边缘网关 / VPN 异常

9.1 故障诊断流程图

[租户报告：VPN 隧道断了 / 本地资源访问不了] │ ▼ [1] VPN 连接对象是否已创建 Operator 门户 - 网络 - VPN 连接 │ ├── 未创建 → 创建 Local Network Gateway + VPN Connection ├── 已创建 → 继续 │ ▼ [2] 网关 VIP 是否已分配 Operator 门户 → VPN 连接 - 网关 IP │ ├── 未分配 → 上篇 §11.3 提示：在创建连接前不会分配 VIP，这是预期行为 ├── 已分配 → 继续 │ ▼ [3] 本地 VPN 设备是否已配置 │ ├── 未配置 → 参考 §9.3 设备兼容性 / 9.4 IPSec 参数 ├── 已配置 → 继续 │ ▼ [4] IKE 阶段 1 / 阶段 2 协商成功？ Operator 门户 - VPN 连接状态 / 本地 VPN 设备日志 │ ├── IKE 失败 → 检查 Pre-Shared Key / IKE 版本 / IPSec 算法匹配 ├── IKE 成功 → 继续 │ ▼ [5] 数据流测试 从 Azure Stack Hub VM 测试到本地网络 IP 从本地网络测试到 Azure Stack Hub VM IP

9.2 VPN 排错的两类常见陷阱

L3 最佳实践

1. "VPN 状态显示未连接" ≠ 故障

   • 在创建连接资源之前不会获得 VIP（上篇 §11.3 已说明）；

   • 即使配置完成，有实际流量前状态可能显示"断开连接"——这是正常行为；

   • 不要因状态显示断开就直接重启 Gateway——会让客户 VPN 隧道意外中断。

2. VPN 带宽瓶颈 ≠ Azure Stack Hub 限制

   • 上篇 §13.1 已说明 S2S VPN 带宽受"隧道最大吞吐量带宽限制"，但微软未给出固定数字；

   • 实操建议：业务规划阶段实测，避免被纸面参数误导。

9.3 VPN 设备兼容性

L0 官方事实

Azure Stack Hub 的VPN 设备兼容性与 Azure 公有云共用同一份清单——参考 https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices。

• Azure Stack Hub 不独立维护 VPN 设备清单；

• 实操影响：① 客户 VPN 设备不在该清单里时，Azure Stack Hub 也不支持② 自定义 IPSec / IKE 策略的可用算法与 Azure 公有云一致。

9.4 IPSec / IKE 默认策略（精确表）

L0 版本事实——PPT 直接给出

Main Mode 策略默认值：

Quick Mode 设置：

使用方式：本地 VPN 设备配置时，这三组参数必须与 Azure Stack Hub VPN 一致，否则 IKE 阶段 1 协商就会失败。

10. 四个常见误判信号

没有明说，但实操里最频繁导致误操作的四个"假象"。本文作为补足。

10.1 误判 1：VIP PING 失败 = 故障

L1 客观事实 + L3 最佳实践

• 真实现象：VIP PING 永远会失败，因为 SLB 不支持 ICMP（详见 §6.3）；

• 正确动作：用 TCP 端口测试代替 PING——Test-NetConnection -Port；

• 避坑：不要给客户"VIP 通"或"VIP 不通"的判断，除非用端口测试。

10.2 误判 2：VPN 显示"未连接" = 故障

L3 最佳实践

• 真实现象：见 §9.2 + 上篇 §11.3——未创建连接前无 VIP；创建完成但无流量也可能显示"未连接"；

• 正确动作：先看是否有实际流量需求，再决定是否重启 Gateway；

• 避坑：重启 Gateway = 短暂中断所有 VPN 隧道，非必要不要做。

10.3 误判 3：DNS 解析失败 = DNS 故障

L3 最佳实践

• 真实现象：可能是 DNS 服务器故障，也可能是上游 DNS 转发器问题，还可能是 vNet 配置了"自定义 DNS"导致 iDNS 失效（详见 §8.3）；

• 正确动作：用 168.63.129.16 当 DNS 临时回退测试；

• 避坑：不要先重启 DNS 服务——大概率问题不在 DNS 服务本身。

10.4 误判 4：静态路由 + 公共 IP 失效 = 公共 IP 异常

L0 官方事实 + L3 最佳实践

• 真实现象：上篇 §8.3 已说明——静态路由模式下，每个新公共 IP 都需要为数据中心交换机添加静态路由；

• 正确动作：扩容公共 IP 后，先查数据中心交换机路由表再下结论；

• 避坑：这是容量变更最容易踩的坑——扩容了公共 IP 但忘了手动配静态路由，结果"公共 IP 加了但访问不了"。

11. 日志收集：Get-AzureStackLog

11.1 日志收集的 cmdlet

L1 微软硬要求

PPT 给出精确的日志收集命令（Microsoft 内部运维 cmdlet）：

Get-AzureStackLog ` -OutputPath C:\AzureStackLogs ` -FilterByRole NRP,NC,SLB,Gateway

11.2 四个目标角色

11.3 适用场景

11.4 ⚠️ 重要边界

L1 客观边界

这是 Microsoft 内部运维 cmdlet，通常在以下情况执行：

• OEM Support 工程师在客户现场调试时执行；

• 微软 Support 工程师通过远程会话执行；

• 租户 / 企业 IT 通常不需要执行——遇到网络问题联系 OEM Support 或微软 Support。

租户在使用 Operator 门户时通常不会用到此 cmdlet——这是 Microsoft 内部运维的一环，不应被租户当成"日常维护工具"使用。

11.5 日志收集后的流程

[1] 在 DVM 或 ERCS VM 上执行 Get-AzureStackLog │ ▼ [2] 收集到的日志以 zip 形式保存到 OutputPath │ ▼ [3] 上传到 OEM Support / 微软 Support 案件 │ ▼ [4] Support 工程师分析后给出修复建议

12. 运维节奏：上线 / 巡检 / 处置 / 复盘

本文"全生命周期运维节奏"，把单点排错升级为可重复的运维流程。

12.1 上线前

12.2 日常巡检

12.3 故障处置 SOP（标准模板）

[1] 故障接收：工单系统记录现象、时间、影响范围 │ ▼ [2] 故障定位：参见 §6-§9 流程图 │ ▼ [3] 故障处置：执行相应修复（VM 启动 / NSG 修正 / Gateway 重启等） │ ▼ [4] 故障验证：用端口测试 / PING IP / DNS 测试 等核对 │ ▼ [5] 故障归档：纳入知识库 │ ▼ [6] 故障复盘：4 个问题 ├── 根本原因是什么？ ├── 为什么之前没被发现？ ├── 怎么做能预防下次？ └── 是否需要变更流程？

12.4 ⚠️ 运维红线（绝对禁止）

L1 微软硬要求

13. 下篇小结

Azure Stack Hub 网络栈的管理与排错可以分成三个层次：

13.1 监控层（§3-§4）

• 网络健康监控告警：Operator 门户 - 区域管理；告警本身不等于故障；

• 公共 IP 池容量告警：70% / 90% / 100% 三档阈值——这是 L0 官方事实，租户请勿拖延到 100%；

• 四个核心组件的角色：NRP / NC / SLB / Gateway——出问题先看是哪个角色。

13.2 排错层（§5-§10）

• 排错方法学：先看现象是否真的存在（避开四个常见误判信号），再按诊断流程图逐项排除；

• 四类典型故障：VIP 连通 / 出栈 NAT / DNS 解析 / VPN 异常——每类都有"现象 → 五步检查 → 修复"流程；

• 关键背景：SLB 不支持 ICMP = "VIP PING 永远失败 ≠ 故障"；VPN 状态显示"未连接"可能是预期行为。

13.3 运维层（§11-§12）

• 日志收集：Get-AzureStackLog -FilterByRole NRP,NC,SLB,Gateway—— 主要是 OEM / 微软 Support 工具；

• 运维节奏：上线前 / 日常巡检 / 故障处置 / 故障复盘——四个阶段都需要 SOP；

• 运维红线：不修改 OEM 验证的物理 / 网络配置；不擅自重启 ERCS VM；不在生产时段做破坏性变更。

13.4 与上篇的连接

• 上篇讲网络是怎么搭的——本文讲网络是怎么查的；

• 上篇区分的"L0/L1/L2/L3"四层在排错时仍适用：

  • L1 客观约束（如"SLB 不支持 ICMP"）——理解约束比绕过约束更重要；

  • L3 最佳实践（如"公共 IP 用 BGP 宣告"）——建设阶段就避免常见问题。

维护说明

• 维护版本：v1.0（2026-07-27 首发）

• 核心来源： 内训资料 "Azure Stack Hub 网络服务"

• 版本基础：azs-1901 至 azs-2503 当前主流版本；如版本与本文表述不一致，以当期版本 Azure Stack Hub Operator 文档为准

• 上篇文件名：azure-stack-hub-network-overview-and-tenant-services.md

文末引用：

• 本文严格区分四层（L0 版本事实 / L1 微软硬要求 / L2 OEM 实现 / L3 最佳实践）

• 容量告警阈值 70%/90%/100% 保留原值——属 L0 官方事实

• VPN Main Mode / Quick Mode 默认参数保留——属 Microsoft 官方默认值

• 不写任何未经微软权威来源认证的性能数字