Azure Web 应用程序和 Azure SQL 服务器的 VNet 集成
VNet Integration For Azure Web App and Azure SQL Server
我有一个 Azure Web 应用程序和一个 Azure SQL 服务器，它们都在同一个订阅中。它们都连接到相同的 VNet 子网，如下面的快照所示。 SQL 服务器配置为不允许 Azure 资源和服务访问服务器，因为它应该只允许从连接的子网或一组 IP 规则进行访问。
不幸的是，SQL 服务器主动拒绝来自 Web 应用程序的任何连接，声明不允许 Web 应用程序 IP 访问服务器。
有趣的是，我在另一个订阅上使用了完全相同的配置。
我可能遗漏了什么？
快照：
1- 在这里您可以看到连接到 "webapps" 子网的 Web 应用程序
2- 在这里你可以看到 SQL 服务器连接到同一个子网
3- 这就是我得到的错误
您必须在 sql 固件中配置应用服务的出站 IP。
您可以在应用服务的属性下找到它们。 Documentation。
原因是 VNET 集成没有在您配置它的 VNET 中为您的应用服务提供出站 IP，因此您配置的 FW 不起作用。
Azure 中的虚拟网络与其在本地的工作方式大不相同。
我在生产环境和深入挖掘中遇到了类似的问题，工作解决方案（满足安全标准并创建到数据库的安全连接）是为虚拟网络中的 SQL 访问创建一个专用端点。然后所有对 SQL 的调用都在内部执行（它没有在互联网上进行），并且数据库拒绝所有 public 调用。
在您现在的情况下，您停用了允许 Azure 应用程序访问，因此当您的应用程序尝试访问 SQL 时，服务器会检查 ip 以找出是否列入白名单。如此快速的解决方案将是以下之一：
- 启用 Azure Web 应用程序以访问 SQL
- 找到您的网络应用程序的所有出站 IP 并在您的 SQL 防火墙/安全设置中注册它们。
如果您谈论具有安全法规的适当生产环境，我建议您沿着更乏味的专用端点路径走下去。
我有可以访问存储帐户和 KV 的工作 Web 应用程序。这些存储帐户和 KV 接受来自特定子网的流量，并且 Web 应用程序已配置为与这些子网集成。我确实遇到了一个问题，即使在集成应用程序之后也无法访问这些资源。对我有用的是，我将应用程序服务 SKU 从标准更改为高级，然后重新启动应用程序。如您所见，它警告说 "Outgoing IPs of your app might change"。这不是保证的解决方案，但它对我有用……好几次！虽然不确定 SQL 服务器。专用端点似乎是可行的方法，但您可以尝试一下。
TLDR
配置正确，但可能需要重启应用服务。
VNET 集成
使用虚拟网络将 Web 应用程序连接到 SQL 数据库的配置是正确的：如果 Web 应用程序连接到数据库 ACL 中允许的同一个 subnet/vnet， 和 Microsoft.Sql 服务端点在子网上启用，Web 应用程序能够与数据库通信。这就是服务端点的全部原因：您不需要在数据库上配置 IP 限额。
至于为什么配置还是出错，可能是配置资源的顺序问题。我们遇到了完全相同的设置和问题（这就是让我回答这个问题的原因）！
我们将网络应用程序连接到 subnet/vnet，但尚未在子网上启用服务端点。然后我们 added/allowed subnet/vnet 作为数据库中的 ACL，在此期间我们被提示启用 Microsoft.Sql 服务端点（我们做到了）。然而，即使在等待约 20 分钟后，我们仍然遇到相同的连接问题。
但是，一旦我们重新启动应用程序服务，问题就消失了，网络应用程序可以连接到 SQL 数据库。
我怀疑问题是由于在 应用服务连接到子网后 启用了子网的服务端点。应用服务必须重新启动才能刷新应用服务的 vnet config/routing。
不需要配置
与其他答案相反，您不需要配置防火墙 IP 许可，也不需要启用对 Azure 服务和资源的访问。事实上，这两种方法都有缺点：
- 启用对 Azure 服务和资源的访问允许 任何 基于 Azure 的资源连接到您的数据库，其中包括不属于您的资源.来自 doc：
This option configures the firewall to allow all connections from Azure, including connections from the subscriptions of other customers.
- 除非您使用的是应用服务环境（这比普通的应用服务计划贵得多），否则您的 Web 应用的出站 IP 地址既不是静态的也不是特定于您的应用的。来自 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.
第二点在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.
因此，如果您只想将通信与您的 Web 应用程序隔离开来，那么上述两个选项都不会真正强化您的 SQL 数据库。如果你在同一个子网中有资源，使用vnet集成是解决问题的正确方法。
如果资源不能在同一个子网，解决方案是使用Private Endpoints.
我有一个 Azure Web 应用程序和一个 Azure SQL 服务器，它们都在同一个订阅中。它们都连接到相同的 VNet 子网，如下面的快照所示。 SQL 服务器配置为不允许 Azure 资源和服务访问服务器，因为它应该只允许从连接的子网或一组 IP 规则进行访问。
不幸的是，SQL 服务器主动拒绝来自 Web 应用程序的任何连接，声明不允许 Web 应用程序 IP 访问服务器。
有趣的是，我在另一个订阅上使用了完全相同的配置。
我可能遗漏了什么？
快照：
1- 在这里您可以看到连接到 "webapps" 子网的 Web 应用程序
2- 在这里你可以看到 SQL 服务器连接到同一个子网
3- 这就是我得到的错误
您必须在 sql 固件中配置应用服务的出站 IP。 您可以在应用服务的属性下找到它们。 Documentation。 原因是 VNET 集成没有在您配置它的 VNET 中为您的应用服务提供出站 IP，因此您配置的 FW 不起作用。
Azure 中的虚拟网络与其在本地的工作方式大不相同。
我在生产环境和深入挖掘中遇到了类似的问题，工作解决方案（满足安全标准并创建到数据库的安全连接）是为虚拟网络中的 SQL 访问创建一个专用端点。然后所有对 SQL 的调用都在内部执行（它没有在互联网上进行），并且数据库拒绝所有 public 调用。
在您现在的情况下，您停用了允许 Azure 应用程序访问，因此当您的应用程序尝试访问 SQL 时，服务器会检查 ip 以找出是否列入白名单。如此快速的解决方案将是以下之一：
- 启用 Azure Web 应用程序以访问 SQL
- 找到您的网络应用程序的所有出站 IP 并在您的 SQL 防火墙/安全设置中注册它们。
如果您谈论具有安全法规的适当生产环境，我建议您沿着更乏味的专用端点路径走下去。
我有可以访问存储帐户和 KV 的工作 Web 应用程序。这些存储帐户和 KV 接受来自特定子网的流量，并且 Web 应用程序已配置为与这些子网集成。我确实遇到了一个问题，即使在集成应用程序之后也无法访问这些资源。对我有用的是，我将应用程序服务 SKU 从标准更改为高级，然后重新启动应用程序。如您所见，它警告说 "Outgoing IPs of your app might change"。这不是保证的解决方案，但它对我有用……好几次！虽然不确定 SQL 服务器。专用端点似乎是可行的方法，但您可以尝试一下。
TLDR
配置正确，但可能需要重启应用服务。
VNET 集成
使用虚拟网络将 Web 应用程序连接到 SQL 数据库的配置是正确的：如果 Web 应用程序连接到数据库 ACL 中允许的同一个 subnet/vnet， 和 Microsoft.Sql 服务端点在子网上启用，Web 应用程序能够与数据库通信。这就是服务端点的全部原因：您不需要在数据库上配置 IP 限额。
至于为什么配置还是出错，可能是配置资源的顺序问题。我们遇到了完全相同的设置和问题（这就是让我回答这个问题的原因）！
我们将网络应用程序连接到 subnet/vnet，但尚未在子网上启用服务端点。然后我们 added/allowed subnet/vnet 作为数据库中的 ACL，在此期间我们被提示启用 Microsoft.Sql 服务端点（我们做到了）。然而，即使在等待约 20 分钟后，我们仍然遇到相同的连接问题。
但是，一旦我们重新启动应用程序服务，问题就消失了，网络应用程序可以连接到 SQL 数据库。
我怀疑问题是由于在 应用服务连接到子网后 启用了子网的服务端点。应用服务必须重新启动才能刷新应用服务的 vnet config/routing。
不需要配置
与其他答案相反，您不需要配置防火墙 IP 许可，也不需要启用对 Azure 服务和资源的访问。事实上，这两种方法都有缺点：
- 启用对 Azure 服务和资源的访问允许 任何 基于 Azure 的资源连接到您的数据库，其中包括不属于您的资源.来自 doc：
This option configures the firewall to allow all connections from Azure, including connections from the subscriptions of other customers.
- 除非您使用的是应用服务环境（这比普通的应用服务计划贵得多），否则您的 Web 应用的出站 IP 地址既不是静态的也不是特定于您的应用的。来自 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.
第二点在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.
因此，如果您只想将通信与您的 Web 应用程序隔离开来，那么上述两个选项都不会真正强化您的 SQL 数据库。如果你在同一个子网中有资源，使用vnet集成是解决问题的正确方法。
如果资源不能在同一个子网，解决方案是使用Private Endpoints.