通过点到站点 VPN 访问私有 Container Apps 应用

内部 Container Apps 环境需要私有入口、匹配的主机名以及 VPN 可以访问的解析程序。逐步执行，然后验证拒绝。

本运行手册介绍具有工作负载配置文件的 Container Apps 环境，以及它的内部虚拟网络入口：从笔记本电脑通过已批准的点到站点 VPN 访问，使用应用的直接 FQDN，且不依赖环境级 HTTP 路由。 环境入口可从客户端访问、应用的入口范围允许调用方，且主机名解析到私有入口。下面每个步骤都会留下可验证的结果，以及不会触及你未改动内容的回滚。请按给定顺序执行，因为后面任何步骤都无法弥补第 1 步中错误的范围决策。

在改动 DNS 之前，先弄清“内部”一词。在本产品中它用于两种不同的范围，把它们混为一谈，是可用名称仍然返回不了任何有用内容的最常见原因。

第 1 步：确定环境和应用的范围

在更改任何记录之前，先阅读应用的入口配置：

SettingBoundary
Internal environmentThe environment entry is reached through its private network arrangement
App with internal ingressCallers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately
App with external ingress in an internal environmentThe app accepts outside traffic through the environment's private entry

内部入口暴露在环境 VNet 内部的环境内部负载均衡器上，因此问题不是笔记本电脑是不是另一个容器应用，而是它能否到达该 VNet。具有进入 VNet 的路由、且环境默认域通过专用区域解析的 VPN 客户端就是合格调用方，后面各步骤构建的正是这一点。没有公共入口的内部环境与具有内部入口的应用是不同的事实，而应用级的外部入口并不会给环境一扇公共门。把范围写进工单，也写进门户，因为下一位工程师会先读工单。

继续之前，请与配置负责人确认该范围，并保持关口狭窄：如果不存在进入环境 VNet 的路由，或者环境默认域无法通过专用区域解析，请停下来先修复该路径。后续任何步骤都无法替代一个无法到达 VNet 或无法解析名称的调用方。

第 2 步：收集真实主机名和入口地址

记录环境的默认域、静态私有入口地址以及应用已配置的 FQDN，应从资源中获取，而不是旧截图或维基页面：

az containerapp env show -n ENV -g RG \
  --query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
  --query "properties.configuration.ingress.fqdn"

Container Apps 的 私有入口指南 介绍了如何将环境域与其内部地址匹配，同时保持应用程序主机名不变。这正是你在此手工构建的形态，因此请让区域内容与之一致，而不是另造一套命名方案。

如果读到的域与应用报告的 FQDN 不一致，请停下来立即对齐。基于错误后缀构建区域，会得到一个解析完全正确却落在错误虚拟主机上的主机名。

第 3 步：把专用区域放到 VPN 的解析程序路径上

为环境的实际默认域创建或复用受支持的专用 DNS 区域，并让文档化的通配符记录和地址记录指向静态入口。将该区域链接到适当的虚拟网络，并通过 VPN 已批准的解析程序路径让专用权威可被访问，而不是假定链接就足够了。

点到站点客户端通常需要专用解析程序的入站终结点或受支持的 DNS 转发器才能到达该区域。链接区域会改变 Azure 为已链接网络解析的内容；它不会重定向每台外部笔记本电脑的公共解析程序。不要用从其他 Container Apps 网络模型借来的专用终结点 DNS 区域来替代它，因为记录名称和区域后缀不会对齐。

此步骤的回滚是删除区域链接或你添加的记录。记下是哪一种，因为为了撤销单个链接而删除共享区域，是破坏第二个环境的常见做法。

第 4 步：先测试名称，再测试被拒绝的受众

把主机名和 TLS 身份放在一起测试，而不是只测地址。对于受控的名称映射诊断，可以在保留主机名的同时固定地址：

curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
    https://app.ENVIRONMENT_DOMAIN/

把主机名换成应用的真实 FQDN，把地址换成真实的内部入口。这只影响那一个请求，并不是 DNS 配置。不要添加 -k 把身份失败变成看似通过，因为证书不匹配正是你打到错误监听器的信号。

直接请求数字地址即使 TCP 443 有应答，也可能选中错误的虚拟主机或验证失败，因此把成功的 IP 测试当作关于网络的证据，仅此而已。从预期的笔记本电脑出发，正常的解析程序路径是客户端的 DNS 转发器，或托管该区域的专用解析程序的入站终结点；那里的失败是解析程序可达性问题，而不是缺少记录。确认同一请求在该路径上成功，然后确认被拒绝的受众仍被拒绝。

要记录什么，以及要回滚什么

容器的目标端口和客户端的 HTTPS 端口是两项独立设置。不要因为容器在那里监听就通过 VPN 发布容器的目标端口，也不要为了让端口测试通过而放宽网络规则。这两项改动都会在事件之后继续存在，日后很难归因。

从预期的笔记本电脑、用它获授权的身份和正常 DNS 完成一次全新的应用操作，然后检查未获授权的调用方仍然失败。在应用配置中，还要确认环境级 HTTP 路由是否把此应用作为目标暴露，因为那条路由是入口范围描述不到的第二扇门。

一起记录五个值：环境范围、应用入口范围、FQDN、私有入口地址和解析程序负责人。这五项描述了整个访问契约，而下一位排查者要问的正是它们。

相关文章