openUBMC QEMU Web 端口访问问题

QA SIG
1

现象

在 openUBMC QEMU 环境中，QEMU 启动参数包含 Web 端口转发：

hostfwd=tcp::10443-:443

按预期，主机侧访问下面地址应能进入 Web 页面：

https://127.0.0.1:10443/

但实际在主机侧执行：

curl -k -I https://127.0.0.1:10443/

结果连接失败：

curl: (7) Failed to connect to 127.0.0.1 port 10443 after 2027 ms: Could not connect to server

89495c9c8f38e85f98ddc66719e60c4f
89495c9c8f38e85f98ddc66719e60c4f1509×313 10.5 KB

当前使用的 manifest 版本信息如下：

image
image1303×363 25.9 KB

已确认信息

1. Web 相关微组件存在

进入 QEMU guest 后执行：

source /etc/profile
mdbctl lsmc

可以看到 web_backend、redfish 等微组件存在，说明 Web 后端相关组件已经在当前系统中注册。

e34c179a12383bcc7c5f055066cf35d8
e34c179a12383bcc7c5f055066cf35d82542×138 9.89 KB

2. guest 内 nginx 已启动

在 QEMU guest 中执行：

netstat -tunpl

能看到 nginx 已监听 HTTP/HTTPS 相关端口：

tcp  0  0 127.0.0.1:80     0.0.0.0:*  LISTEN  4409/nginx
tcp  0  0 127.0.0.1:443    0.0.0.0:*  LISTEN  4409/nginx
tcp  0  0 127.0.0.1:40443  0.0.0.0:*  LISTEN  4409/nginx

这说明 guest 内部 Web 入口进程已经起来。

eca274c3ab29f581ec8e90c17b857c6e
eca274c3ab29f581ec8e90c17b857c6e1228×1357 30.4 KB

3. nginx 只监听 loopback 地址

当前 nginx 监听地址是：

127.0.0.1:443

而不是：

0.0.0.0:443

因此它只接受 guest 内部本机 loopback 访问。

当前判断

当前问题不像是 Web 后端组件完全没有启动，也不像是浏览器证书问题。

可能的问题是：

QEMU hostfwd 将主机 10443 转发到 guest 443，
但 guest 内 nginx 只监听 127.0.0.1:443，
没有监听 guest 对外网络地址或 0.0.0.0:443，
导致主机侧无法通过 10443 访问到 guest 内的 Web 服务。
2

答案内容由AI生成，仅供参考：

排查与解决方案

根据知识库文档，这个问题有明确的排查路径和解决方案，特别是关于 nsm（网络服务管理） 组件的设计。

1. 理解 openUBMC 的网络架构

根据 知识库文档 和 搜索结果 中的描述：

  • nsm 组件 是 openUBMC 系统中负责管理网络服务的核心组件。
  • 其设计理念是 “所有网络服务监听环回地址（127.0.0.1），由 iptables 将外部请求转发到对应服务的内部端口”（参考文档：nsm.md）。
  • 这意味着 Nginx 监听 127.0.0.1:443 是正常的、预期的行为，而非配置错误。Nginx 本就不应该直接监听外部网络接口。

2. 问题真正根源：iptables 转发规则缺失或未生效

既然 Nginx 的设计是只监听回环地址，那么外部的流量（包括从 QEMU 转发过来的）必须通过 guest 内部的 iptables 规则进行中转。您的问题很可能是因为 负责将外部端口（如来自 QEMU 转发的连接）流量转发到 127.0.0.1:443 的 iptables 规则未能正常加载或配置错误。

3. 行动步骤建议

您可以按照 nsm 文档 中提供的诊断流程进行排查：

第一步：检查 iptables 转发规则

  • 命令：在 QEMU guest 内执行 iptables -t nat -L -n -v（查看 NAT 表规则，这是端口转发发生的地方）。
  • 目标：查找是否有将目的端口为 443 的入站流量转发到 127.0.0.1:443 的规则。例如，规则可能类似于 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 to:127.0.0.1:443。
  • 结论：如果找不到这样的规则，或者规则不完整，这就是问题的根本原因。

第二步：检查 nsm 服务状态

  • 命令：在 QEMU guest 内执行 ipmcget -d nsm -t status 或类似命令来检查 nsm 组件的状态。
  • 目标：确认 nsm 服务是否正常运行。如果 nsm 服务未启动或工作异常，它可能未能正确应用 iptables 规则。

第三步：参考“Qemu相关FAQ”进行环境重置

如果 iptables 规则缺失，您可以参考 知识库 中的 Qemu相关FAQ 文档，它提供了针对类似问题的标准恢复流程。特别是当“ssh和ipmi启动时间比web的启动时间要快”或“web连接不通可能在于nginx还没拉起”时，建议尝试以下步骤：

  1. 清除本地构建缓存：
    rm -rf ~/.conan2/p/*   # 或 conan2 路径
  2. 重新构建 QEMU 环境：
    rm -rf ./temp && rm -rf ./output
bingo build -sc qemu
  3. 使用默认的config.json文件，重新启动 QEMU：
    python3 build/works/packet/qemu_shells/vemake_1711.py

这个流程可以确保所有后台服务，包括 nsm 及其管理的 iptables 规则，以一个干净、正确的状态启动。

4. 关于 Nginx 监听 127.0.0.1:40443 的说明

您还注意到 Nginx 监听了 127.0.0.1:40443。这很可能是 nsm 为 KVM（键盘-视频-鼠标重定向） 或 VMM（虚拟机管理） 等服务配置的内部端口。这类服务的流量通常通过 Nginx 反向代理，再由 iptables 或 Nginx 自身路由到对应的后端服务，而不会直接暴露给 QEMU 的端口转发。具体功能需要参考完整的 nsm 配置文件。

总结

您的问题并非 Nginx 配置错误，而是 openUBMC 的网络架构设计（nsm + iptables） 未能正确运行。故障场景与知识库中 “Qemu启动后，SSH能访问、Ipmi命令能通，但是web不通” 的FAQ高度吻合。建议按照以下顺序操作：

  1. 核心诊断：在 guest 内执行 iptables -t nat -L -n -v，检查 iptables 规则是否缺少了将流量从外部端口 (443) 转发到内部回环地址 (127.0.0.1:443) 的 DNAT 规则。
  2. 清理重建：如果无法确定具体错误，执行知识库 FAQ 中推荐的“清除缓存并重建”的完整流程，以恢复一个干净、完整的起始环境。
点击此处查看详细分析解答

好的，根据您提供的详细现象描述和已确认信息，并结合所提供的知识库上下文，我对您遇到的问题进行分析和解答。

问题分析

您的判断非常准确。问题的核心在于 QEMU 的端口转发与 guest 内部网络服务监听地址不匹配。

  1. QEMU 端口转发规则：QEMU 启动参数 hostfwd=tcp::10443-:443 的作用是，将宿主机（Host）上的 10443 端口接收到的所有 TCP 流量，转发到 QEMU 虚拟机（Guest）的 网络接口 上的 443 端口。这意味着，流量到达 guest 时，其目标 IP 地址是 guest 的虚拟网卡 IP（通常不是 127.0.0.1），而不是回环地址。

  2. Nginx 监听配置：您在 guest 内执行 netstat -tunpl 看到的结果 tcp 0 0 127.0.0.1:443 0.0.0.0:* LISTEN 4409/nginx 表明，Nginx 只监听在 127.0.0.1（回环地址）。这意味着 Nginx 只接受来自 guest 本机内部（即 guest 自身）发出的请求，而拒绝任何来自外部的网络连接。

    • 对比：如果 Nginx 监听的是 0.0.0.0:443，则表示它接受来自任何网络接口（包括连接宿主机的外部接口）的连接。如果监听的是 guest网卡IP:443，则只接受特定网络接口的连接。

因此，QEMU 的端口转发将外部流量送到了 Guest 的虚拟网卡，但 Guest 内的 Nginx 却只监听本机回环地址，从而拒绝了这些连接。这解释了为什么 curl 命令虽然能触发 10443 端口（QEMU 在监听），但连接建立后，QEMU 将流量转发给 Guest，Nginx 不会响应，导致连接失败。

排查与解决方案

根据知识库文档，这个问题有明确的排查路径和解决方案，特别是关于 nsm（网络服务管理） 组件的设计。

1. 理解 openUBMC 的网络架构

根据 知识库文档 和 搜索结果 中的描述：

  • nsm 组件 是 openUBMC 系统中负责管理网络服务的核心组件。
  • 其设计理念是 “所有网络服务监听环回地址（127.0.0.1），由 iptables 将外部请求转发到对应服务的内部端口”（参考文档：nsm.md）。
  • 这意味着 Nginx 监听 127.0.0.1:443 是正常的、预期的行为，而非配置错误。Nginx 本就不应该直接监听外部网络接口。

2. 问题真正根源：iptables 转发规则缺失或未生效

既然 Nginx 的设计是只监听回环地址，那么外部的流量（包括从 QEMU 转发过来的）必须通过 guest 内部的 iptables 规则进行中转。您的问题很可能是因为 负责将外部端口（如来自 QEMU 转发的连接）流量转发到 127.0.0.1:443 的 iptables 规则未能正常加载或配置错误。

3. 行动步骤建议

您可以按照 nsm 文档 中提供的诊断流程进行排查：

第一步：检查 iptables 转发规则

  • 命令：在 QEMU guest 内执行 iptables -t nat -L -n -v（查看 NAT 表规则，这是端口转发发生的地方）。
  • 目标：查找是否有将目的端口为 443 的入站流量转发到 127.0.0.1:443 的规则。例如，规则可能类似于 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 to:127.0.0.1:443。
  • 结论：如果找不到这样的规则，或者规则不完整，这就是问题的根本原因。

第二步：检查 nsm 服务状态

  • 命令：在 QEMU guest 内执行 ipmcget -d nsm -t status 或类似命令来检查 nsm 组件的状态。
  • 目标：确认 nsm 服务是否正常运行。如果 nsm 服务未启动或工作异常，它可能未能正确应用 iptables 规则。

第三步：参考“Qemu相关FAQ”进行环境重置

如果 iptables 规则缺失，您可以参考 知识库 中的 Qemu相关FAQ 文档，它提供了针对类似问题的标准恢复流程。特别是当“ssh和ipmi启动时间比web的启动时间要快”或“web连接不通可能在于nginx还没拉起”时，建议尝试以下步骤：

  1. 清除本地构建缓存：
    rm -rf ~/.conan2/p/*   # 或 conan2 路径
  2. 重新构建 QEMU 环境：
    rm -rf ./temp && rm -rf ./output
bingo build -sc qemu
  3. 使用默认的config.json文件，重新启动 QEMU：
    python3 build/works/packet/qemu_shells/vemake_1711.py

这个流程可以确保所有后台服务，包括 nsm 及其管理的 iptables 规则，以一个干净、正确的状态启动。

4. 关于 Nginx 监听 127.0.0.1:40443 的说明

您还注意到 Nginx 监听了 127.0.0.1:40443。这很可能是 nsm 为 KVM（键盘-视频-鼠标重定向） 或 VMM（虚拟机管理） 等服务配置的内部端口。这类服务的流量通常通过 Nginx 反向代理，再由 iptables 或 Nginx 自身路由到对应的后端服务，而不会直接暴露给 QEMU 的端口转发。具体功能需要参考完整的 nsm 配置文件。

总结

您的问题并非 Nginx 配置错误，而是 openUBMC 的网络架构设计（nsm + iptables） 未能正确运行。故障场景与知识库中 “Qemu启动后，SSH能访问、Ipmi命令能通，但是web不通” 的FAQ高度吻合。建议按照以下顺序操作：

  1. 核心诊断：在 guest 内执行 iptables -t nat -L -n -v，检查 iptables 规则是否缺少了将流量从外部端口 (443) 转发到内部回环地址 (127.0.0.1:443) 的 DNAT 规则。
  2. 清理重建：如果无法确定具体错误，执行知识库 FAQ 中推荐的“清除缓存并重建”的完整流程，以恢复一个干净、完整的起始环境。
3

后台已识别问题，在着手修改