Azure Web App 和 Azure SQL Server 的 VNet 集成 [英] VNet Integration For Azure Web App and Azure SQL Server

问题描述

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

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

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

我可能会错过什么?

快照:

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

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

3- 这就是我得到的错误

解决方案

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 地址可能不同，在某些情况下甚至会发生变化.

第二点在 这个 Github 问题:

<块引用>

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

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

如果资源不能在同一个子网中，解决方案是使用 私有端点.

I have an Azure Web App and an Azure SQL Server, both in the same subscription. Both of them are connected to the same VNet Subnet as shown in the below snapshots. The SQL Server is configured not to Allow Azure Resources and Services to access the server, as it should only permit access from either the connected subnet or a set of IP rules.

Unfortunately, the SQL Server is actively refusing any connection from the web app stating that the web app IP is not allowed to access the server.

The interesting thing is that I have the exact same configuration working on another subscription.

What could I be missing?

Snapshots:

1- Here you can see the web application connected to the "webapps" subnet

2- And here you can see the SQL Server connected to the same subnet

3- And that's the error I get

解决方案

TLDR

The configuration is correct, but an app service restart may be required.

VNET Integration

The configuration of using a virtual network to connect a web app to a SQL database is correct: if the web app is connected to the same subnet/vnet which is allowed in the database's ACLs, and the Microsoft.Sql service endpoint is enabled on the subnet, the web app is able to communicate to the database. This is the whole reason for service endpoints: you do not need to configure with IP allowances on the database.

As to why the configuration still resulted in an error, it could be the order in which the resources were configured. We were experiencing the exact same setup and issue (which is what let me to this question)!

We connected our web app to the subnet/vnet but had not enabled the service endpoint on the subnet. We then added/allowed the subnet/vnet as an ACL in the database, during which we were prompted to enable the Microsoft.Sql service endpoint (we did). However, even after waiting ~20 minutes, we were still seeing the same connection issue.

However, once we restarted the app service, the issue went away and the web app could connect to the SQL database.

I suspect the issue is due to enabling the subnet's service endpoint after the app service was connected to the subnet. The app service must need a restart to refresh the app service's vnet config/routing.

Configuration NOT needed

Contrary to other answers, you do not need to configure firewall IP allowances nor enable access to Azure services and resources. In fact, there are downsides to both approaches:

• Enabling access to Azure services and resources allows any Azure-based resource to connect to your database, which includes resources not owned by you. From doc:

  This option configures the firewall to allow all connections from Azure, including connections from the subscriptions of other customers.

• Unless you're using an App Service Environment (which is significantly more expensive than normal App Service plans), your web app's outbound IP addresses are neither static nor specific to your application. From doc:

  Azure App Service is a multi-tenant service, except for App Service Environments. Apps that are not in an App Service environment (not in the Isolated tier) share network infrastructure with other apps. As a result, the inbound and outbound IP addresses of an app can be different, and can even change in certain situations.

The second point is further elaborated upon in this Github issue:

IPs are indeed shared with other App Service plans (including other customer's plans) that are deployed into the same shared webspace. The network resources are shared among the plans in a workspace even if the computing instances are dedicated (e.g. in Standard tier). This is inherent to the App Service multi-tenant model. The only way to have a dedicated webspace (i.e. outbound IPs) is to deploy an App Service plan into an App Service Environment (ASE) (i.e. Isolated tier). ASE is the only thing that offers true single-tenency in App Service.

So neither of the above options will truly harden your SQL database if you want to isolate communication from only your web app. If you have resources in the same subnet, using vnet integration is the correct way to solve the problem.

If resources cannot be in the same subnet, the solution is to use Private Endpoints.

这篇关于Azure Web App 和 Azure SQL Server 的 VNet 集成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！