通过

排除虚拟网络与 Azure 应用程序服务集成的故障

  • 项目

本文介绍可用于排查与虚拟网络集成的Azure App 服务中的连接问题的工具。

注意

应用服务中的 Docker Compose 方案不支持虚拟网络集成。 如果存在专用终结点，则忽略访问限制策略。

验证虚拟网络集成

若要排查连接问题，必须先验证是否已正确配置虚拟网络集成，以及是否将专用 IP 分配给App 服务计划的所有实例。

为此，请使用下列方法之一：

在 Kudu 调试控制台中检查专用 IP

若要访问 Kudu 控制台，请在Azure 门户中选择应用服务，转到“开发工具”，选择“高级工具”，然后选择“转到”。 在 Kudu 服务页中，选择“工具>调试控制台>CMD”。

显示如何在Azure 门户中打开 Kudu 服务页的屏幕截图。

还可以直接通过 URL [sitename].scm.azurewebsites.net/DebugConsole转到 Kudu 调试控制台。

在调试控制台中，运行以下命令之一：

基于 Windows OS 的应用

SET WEBSITE_PRIVATE_IP

如果已成功分配专用 IP，你将获得以下输出：

WEBSITE_PRIVATE_IP=<IP address>

基于 Linux OS 的应用

set| egrep --color 'WEBSITE_PRIVATE_IP'

检查 Kudu 环境中的专用 IP

转到 Kudu 环境 [sitename].scm.azurewebsites.net/Env 并搜索 WEBSITE_PRIVATE_IP。

成功配置虚拟网络集成后，可以继续执行连接测试。

排查 Windows 应用上的出站连接问题

在本机 Windows 应用中，由于安全约束（它们在自定义 Windows 容器中工作），工具 ping、 nslookup 和 tracert 无法通过控制台工作。

直接 [sitename].scm.azurewebsites.net/DebugConsole转到 Kudu 控制台。

若要测试 DNS 功能，可以使用 nameresolver.exe。 语法为：

nameresolver.exe hostname [optional:DNS Server]

可以使用 nameresolver 来检查应用所依赖的主机名。 这样，就可以测试 DNS 配置错误，或者可能无权访问 DNS 服务器。 若要了解可供应用在控制台中使用的 DNS 服务器，请查看环境变量 WEBSITE_DNS_SERVER 和 WEBSITE_DNS_ALT_SERVER。

注意

nameresolver.exe 工具当前不适用于自定义 Windows 容器。

若要测试与主机和端口组合的 TCP 连接，可以使用 tcpping。 语法为<

tcpping.exe hostname [optional: port]

tcpping 实用程序会告知是否可访问特定主机和端口。 仅当应用程序侦听主机和端口组合以及从应用到指定主机和端口的网络访问时，它才能显示成功。

排查 Linux 应用上的出站连接问题

直接转到 Kudu。[sitename].scm.azurewebsites.net 在 Kudu 服务页中，选择“工具>调试控制台>CMD”。

若要测试 DNS 功能，可以使用命令 nslookup。 语法为：

nslookup hostname [optional:DNS Server]

根据上述结果，可以检查 DNS 服务器上是否存在错误配置的内容。

注意

nameresolver.exe工具目前在 Linux 应用中不起作用。

若要测试连接性，可以使用 Curl 命令。 语法为：

curl -v https://hostname
curl hostname:[port]

调试对虚拟网络托管的资源的访问

许多因素可能会阻止应用访问特定的主机和端口。 大多数情况下，它是以下项之一：

  • 存在防火墙。 如果存在防火墙，则会发生 TCP 超时。 本例中的 TCP 超时为 21 秒。 使用 tcpping 工具测试连接性。 除了防火墙外，还有多种原因可能导致 TCP 超时。
  • DNS 不可访问。 DNS 超时时间为每个 DNS 服务器 3 秒。 如果有两个 DNS 服务器，则超时为 6 秒。 使用 nameresolver 查看 DNS 是否正常工作。 无法使用 nslookup，因为未使用虚拟网络配置的 DNS。 如果无法访问，可以有防火墙或 NSG 阻止对 DNS 的访问，或者可能会关闭。 使用自定义 DNS 服务器的一些 DNS 体系结构可能非常复杂，有时可能会遇到超时。 若要确定情况是否如此，可以设置环境变量 WEBSITE_DNS_ATTEMPTS 。 有关App 服务中的 DNS 的详细信息，请参阅App 服务中的名称解析（DNS）。

如果这些方法未解决问题，请首先检查以下因素：

区域虚拟网络集成

  • 目标是否为非 RFC1918 地址，并且未启用全部路由？
  • 是否有 NSG 阻止了集成子网传出数据？
  • 如果通过 Azure ExpressRoute 或 VPN 传输，本地网关是否配置为将流量路由回 Azure？ 如果可以访问虚拟网络中的终结点，但不能访问本地的终结点，请检查路由。
  • 是否有足够的权限在集成子网上设置委派？ 在区域虚拟网络集成配置期间，会将集成子网委托给 Microsoft.Web/serverFarms。 VNet 集成 UI 会自动将子网委托给 Microsoft.Web/serverFarms。 如果帐户没有足够的网络权限来设置委派，将需要可设置集成子网中的属性的用户来委托子网。 若要手动委托集成子网，请转到 Azure 虚拟网络子网 UI，并设置 Microsoft.Web/serverFarms 的委派。

调试网络问题很有难度，因为你看不到哪些因素在阻止访问特定的“主机:端口”组合。 部分原因包括：

  • 在主机上开启了防火墙，导致无法从点到站点 IP 范围访问应用程序端口。 跨子网通常需要公共访问权限。
  • 目标主机已关闭。
  • 应用程序已关闭。
  • IP 或主机名错误。
  • 应用程序所侦听的端口与你预期的端口不同。 可以使用终结点主机上的“netstat -aon”匹配进程 ID 和侦听端口。
  • 网络安全组的配置方式导致无法从点到站点 IP 范围访问应用程序主机和端口。

你不知道应用实际使用的地址。 它可能是集成子网中或点到站点地址范围内的任意地址，因此你需要允许从整个地址范围进行访问。

更多调试步骤包括：

  • 连接到虚拟网络中的某个 VM，尝试在该处访问资源主机:端口。 若要针对 TCP 访问权限进行测试，请使用 PowerShell 命令 Test-NetConnection。 语法为：
Test-NetConnection hostname [optional: -Port]
  • 在某个 VM 中启动应用程序，然后使用 tcpping 测试能否在应用的控制台中访问该主机和端口。

网络疑难解答

还可以使用网络疑难解答来排查App 服务中应用的连接问题。 若要打开网络疑难解答，请转到Azure 门户中的应用服务。 选择“诊断和解决问题”，然后搜索“网络疑难解答”。

显示如何在Azure 门户中打开网络疑难解答的屏幕截图。

注意

连接 问题 方案尚不支持基于 Linux 或基于容器的应用。

连接问题 - 它将检查虚拟网络集成的状态，包括检查是否已将专用 IP 分配给App 服务计划和 DNS 设置的所有实例。 如果未配置自定义 DNS，将应用默认 Azure DNS。 还可以针对要测试其连接的特定终结点运行测试。

显示连接问题的运行疑难解答的屏幕截图。

配置问题 - 此疑难解答将检查子网是否对虚拟网络集成有效。

显示如何针对Azure 门户中的配置问题运行疑难解答的屏幕截图。

子网/VNet 删除问题 - 此疑难解答将检查子网是否有任何锁，以及它是否有任何未使用的服务关联链接，这些链接可能会阻止删除 VNet/子网。

显示如何针对子网或虚拟网络删除问题运行疑难解答的屏幕截图。

收集网络跟踪

收集网络跟踪有助于分析问题。 在Azure App 服务中，网络跟踪是从应用程序进程获取的。 若要获取准确的信息，在启动网络跟踪收集时重现问题。

注意

虚拟网络流量不会在网络跟踪中捕获。

Windows App 服务

若要收集 Windows App 服务的网络跟踪，请执行以下步骤：

  1. 在Azure 门户中，导航到 Web 应用。
  2. 在左侧导航中，选择“ 诊断并解决问题”。
  3. 在搜索框中，键入“收集网络跟踪”，然后选择“收集网络跟踪”以启动网络跟踪收集。

显示如何捕获网络跟踪的屏幕截图。

若要获取为 Web 应用提供服务的每个实例的跟踪文件，请在浏览器中转到 Web 应用的 Kudu 控制台（https://<sitename>.scm.azurewebsites.net）。 从 C：\home\LogFiles\networktrace 或 D：\home\LogFiles\networktrace 文件夹下载跟踪文件。

Linux App 服务

若要收集不使用自定义容器的 Linux App 服务的网络跟踪，请执行以下步骤：

  1. tcpdump运行以下命令安装命令行实用工具：

    apt-get update
apt install tcpdump

  2. 通过安全外壳协议（SSH）连接到容器。

  3. 通过运行以下命令来标识启动和运行的接口（例如， eth0）：

    root@<hostname>:/home# tcpdump -D

1.eth0 [Up, Running, Connected]
2.any (Pseudo-device that captures on all interfaces) [Up, Running]
3.lo [Up, Running, Loopback]
4.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless]
5.nflog (Linux netfilter log (NFLOG) interface) [none]
6.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
7.dbus-system (D-Bus system bus) [none]
8.dbus-session (D-Bus session bus) [none]

  4. 运行以下命令启动网络跟踪集合：

    root@<hostname>:/home# tcpdump -i eth0 -w networktrace.pcap

    替换为 eth0 实际接口的名称。

若要下载跟踪文件，请通过 Kudu、FTP 或 Kudu API 请求等方法连接到 Web 应用。 下面是触发文件下载的请求示例：

https://<sitename>.scm.azurewebsites.net/api/vfs/<path to the trace file in the /home directory>/filename

第三方信息免责声明

本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。

联系我们寻求帮助

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 你还可以将产品反馈提交到 Azure 反馈社区。