Azure Web App 和 Azure SQL Server 的 VNet 集成答案

【问题标题】：VNet Integration For Azure Web App and Azure SQL ServerAzure Web App 和 Azure SQL Server 的 VNet 集成
【发布时间】：2020-09-28 06:23:57
【问题描述】：

我有一个 Azure Web 应用程序和一个 Azure SQL Server，它们都在同一个订阅中。它们都连接到同一个 VNet 子网，如下面的快照所示。 SQL Server 配置为不允许 Azure 资源和服务访问服务器，因为它应该只允许从连接的子网或一组 IP 规则进行访问。

不幸的是，SQL Server 正在主动拒绝来自 Web 应用程序的任何连接，声明不允许 Web 应用程序 IP 访问服务器。

有趣的是，我在另一个订阅上使用了完全相同的配置。

我可能会错过什么？

快照：

1- 在这里您可以看到连接到“webapps”子网的 Web 应用程序

2- 在这里您可以看到连接到同一子网的 SQL Server

3- 这就是我得到的错误

【问题讨论】：

子网上是否启用了 SQL 数据库的服务端点？
@shwetaOnStack 是的，也委托给 Microsoft.Web/serverFarms

标签： azure azure-web-app-service azure-virtual-network azure-sql-server

【解决方案1】：

TLDR

配置正确，但可能需要重启应用服务。

VNET 集成

使用虚拟网络将 Web 应用连接到 SQL 数据库的配置是正确的：如果 Web 应用连接到数据库的 ACL 中允许的相同子网/vnet，和 Microsoft.Sql 服务端点在子网上启用，Web 应用程序能够与数据库通信。这就是服务端点的全部原因：您不需要在数据库上配置 IP 许可。

至于为什么配置还是报错，可能是配置资源的顺序。我们遇到了完全相同的设置和问题（这就是让我提出这个问题的原因）！

我们将 Web 应用程序连接到子网/vnet，但尚未在子网上启用服务端点。然后，我们在数据库中添加/允许子网/vnet 作为 ACL，在此期间我们被提示启用 Microsoft.Sql 服务端点（我们确实这样做了）。然而，即使等待了大约 20 分钟，我们仍然看到同样的连接问题。

但是，一旦我们重新启动应用服务，问题就消失了，网络应用可以连接到 SQL 数据库。

我怀疑问题是由于在应用服务连接到子网之后启用了子网的服务端点。应用服务必须需要重启才能刷新应用服务的 vnet 配置/路由。

不需要配置

与其他答案相反，您无需配置防火墙 IP 许可，也无需启用对 Azure 服务和资源的访问。事实上，这两种方法都有缺点：

启用对 Azure 服务和资源的访问允许任何基于 Azure 的资源连接到您的数据库，其中包括不属于您的资源。来自doc：

此选项将防火墙配置为允许来自 Azure 的所有连接，包括来自其他客户订阅的连接。
除非您使用的是应用服务环境（这比普通应用服务计划贵得多），否则您的 Web 应用的出站 IP 地址既不是静态的，也不是特定于您的应用程序的。来自doc：

Azure 应用服务是一种多租户服务，应用服务环境除外。不在应用服务环境中（不在隔离层中）的应用与其他应用共享网络基础结构。因此，应用的入站和出站 IP 地址可能不同，在某些情况下甚至会发生变化。

第二点在this Github issue中进一步阐述：

IP 确实与部署到同一共享网络空间的其他应用服务计划（包括其他客户的计划）共享。即使计算实例是专用的（例如在标准层中），网络资源也会在工作空间中的计划之间共享。这是应用服务多租户模型所固有的。拥有专用网络空间（即出站 IP）的唯一方法是将应用服务计划部署到应用服务环境 (ASE)（即隔离层）中。 ASE 是唯一在应用服务中提供真正单租户的东西。

因此，如果您只想将通信与您的 Web 应用程序隔离开来，上述选项都不会真正强化您的 SQL 数据库。如果在同一个子网中有资源，使用 vnet 集成是解决问题的正确方法。

如果资源不能在同一个子网中，解决方法是使用Private Endpoints。

【讨论】：

【解决方案2】：

Azure 中的虚拟网络与其在本地的工作方式完全不同。

我在生产环境中遇到了类似的问题并深入挖掘，工作解决方案（满足安全标准并创建与数据库的安全连接）是在虚拟网络中创建一个私有端点用于 SQL 访问。然后所有对 SQL 的调用都在内部执行（它没有在 Internet 上进行），并且数据库拒绝了所有公共调用。

现在就您的情况，您停用了允许 Azure 应用程序访问，因此当您的应用程序尝试访问 SQL 时，服务器会检查 ip 以确定它是否在白名单中。如此快速的解决方案将是以下之一：

使 Azure Web 应用能够访问 SQL
查找您的 Web 应用程序的所有出站 IP，并将它们注册到您的 SQL 防火墙/安全设置中。

如果您谈论具有安全法规的适当生产环境，我建议您走更繁琐的私有端点路径。

【讨论】：

实际上，如果发出调用的应用程序通过同一子网连接，Azure SQL 防火墙允许从它所连接的子网进行连接。无需私有端点，也无需将数据中心的 IP 列入白名单。实际上，昨天，我能够通过删除 vnet 并使用不同的 IP 范围再次创建它来使其工作。这没有意义，你仍然不明白以前的 IP 范围有什么问题。但至少现在它正在工作......我的部署到生产中的手指交叉:)

【解决方案3】：

您必须在 sql fw 中配置来自应用服务的出站 IP。您可以在应用服务的属性下找到它们。 Documentation。原因是 VNET 集成没有在您配置的 VNET 中为您的应用服务提供出站 IP，因此您配置的 FW 不起作用。

【讨论】：

问题是我有很多应用服务。我假设如果应用程序和数据库服务器都连接到同一个子网，它们将使用私有 IP 进行通信。我有大约 20 个应用程序服务共享相同的应用程序计划。除了将所有 20 个应用的 IP 列入白名单之外，还有更好的解决方案吗？
暂时没有，我相信一旦 Azure 在 GA 私有端点中部署应用服务，您将能够使用您的配置。您可以配置“拒绝所有公共网络访问”，然后只有有权从 VNET 访问 sql 私有端点的应用程序服务才能访问它，但您将无法将应用程序服务列入白名单（因为它会禁用 FW 规则）。
我们使用 terraform 轻松检索和配置 FW 规则中的所有 IP。

【解决方案4】：

我有可以访问存储帐户和 KV 的正在运行的 Web 应用程序。这些存储帐户和 KV 接受来自特定子网的流量，并且 Web 应用程序已配置为与这些子网集成。我确实遇到了一个问题，即使在集成应用程序之后也无法访问这些资源。对我有用的是，我将应用服务 SKU 从标准更改为高级并重新启动应用程序。如您所见，它警告“您的应用程序的传出 IP 可能会更改”。这不是保证解决方案，但它对我有用.. 好几次！虽然不确定SQL Server。私有端点似乎是可行的方法，但您可以尝试一下。

【讨论】：