谁能向我建议如何在VNET上配置两个应用程序服务（或其他方式），以便App Service“ A”可以提供静止的API和Service“ B”，而无需经历SNAT端口耗尽，可以反复致电API？
我们当前的设置仅为2个无VNET的应用程序服务（一个呼叫另一个）。两者都可以公开访问，我想以这种方式保留它1）进行调试，以及2）其他服务器可能连接到服务器“ A”。问题在于我们在端口耗尽...
在B上的服务器A和VNET集成上的“私有端点”似乎很容易配置，但这会使A在Internet上变得无法使用。
我尝试在虚拟网络中使用子网和服务终点选项，但无济于事。我还尝试了“端点服务策略”功能，但这似乎只让我选择Microsoft存储资源...
任何提示或建议都将不胜感激。
谢谢
Can anyone advise me on how to configure two app services on a vnet (or otherwise) so that app service 'A' can offer up a restful API and service 'B' call the API on A repeatedly without experiencing SNAT port exhaustion?
Our current set up is just 2 app services (one calling the other) without a vnet. Both are accessible publicly and I'd like to keep it this way 1) for debugging, and 2) as other servers may be connecting to server 'A'. The problem is we're seeing port exhaustion...
"Private endpoint" on server A and vnet integration on B seems easy enough to configure but this causes A to become unavailable over the internet.
I've tried fiddling with the subnets and service end points options in the virtual network to no avail. I've also tried the "endpoint service policy" feature but that only seems to let me select Microsoft Storage resources...
Any tips or advice would be gratefully appreciated.
Thank you
发布评论
评论（2）
解决方法之一，您可以关注
请检查发现是否正确： -
通过V-NET集成和一个私人链接传达了两个应用程序服务。如果您只使用V-NET集成而不是私有链接。然后出站请求是可能的，但入站请求不可能。这就是为什么应用程序无法彼此通信的原因。
私有端点具有VNET集成： - 私有端点将独特的IP地址分配给您的应用程序，以专门用于入站流量。它可以防止您的应用程序在网络中拨出呼叫。如果您想在VNET中拥有所有入站和出站流量，则必须在两个单独的子网上同时使用私人端点和区域VNET集成。您可以通过私人端点来确保入站流量，以及通过VNET集成的排出流量。
这是如何 v-net Intemration 使用应用服务：
有关更多信息，请参阅下面的链接： -
因此，线程 | Azure App Service通过私人链接 ＆amp;
Microsoft文档 | 使用私人端点用于Azure Web App ＆amp; 使用IHTTPCLIENTFACTORY实现弹性HTTP请求 。
One of the workaround , you can follow
Please check if findings are correct:-
Two app services are communicated with via v-net integration and a private link. If you're only going to use the v-net integration and not the private link. Then outbound requests are possible, but inbound requests are not. This is why apps are unable to communicate with one another.
Private Endpoint with VNet Integration:- Private Endpoint assigns a unique IP address to your app for inbound traffic exclusively. It prevents your app from making outgoing calls within your network. You must utilize both Private Endpoint and Regional VNet Integration on two separate subnets if you want to have all inbound and outbound traffic in your VNet. You can secure inbound traffic with Private Endpoint, and outbound traffic with VNet Integration.
Here is the workflow that how v-net integration working with app services:
For more information please refer the below links:-
SO THREAD|Azure App Service to App Service communication via Private Link & Connecting two App Services within the same VNet
MICROSOFT DOCUMENTATION|Using Private Endpoints for Azure Web App & Use IHttpClientFactory to implement resilient HTTP requests.
您在这里达到了Azure App Services的限制。公共应用服务（具有VNET集成）仅预先分配了128个SNAT端口。在某些情况下，这可能还不够。如详细描述的在这里可以通过使用：
连接池：通过汇总连接，您避免打开通话的新网络连接，以通往同一地址和端口。
。
服务终点：您对使用服务端点确保的服务没有SNAT端口。
私人端点：您没有限制使用私人端点的服务的SNAT端口。
nat Gateway ：使用NAT网关，您有64K出站SNAT端口，这些端口可由通过它发送流量的资源可用。
如果我将这些建议的解决方案应用于您的特定方案，我认为唯一的选择是解决方案1（连接池）和4（Azure Firewall）：
，我肯定会建议使用连接池。这是应用程序服务中运行的代码的较小更改。如果您是高级程序员，则可能已经正确实施了。
在您的情况下，您希望应用程序服务保持公开，因此使用服务端点是不是一个选项。
在您的情况下，您希望应用程序服务保持公开，因此使用私人端点也是不是选项。
如果仅连接池是不够的，那么您唯一的选择是实现NAT网关或Azure防火墙。 Azure防火墙本身提供2,496个SNAT端口（）每个公共IP地址配置。 Azure防火墙很漂亮昂贵 。简而言之，您必须执行以下操作：
You are hitting a limitation of Azure app Services here. A public app service (with vnet integration) is only pre-allocated 128 SNAT ports. This may not be enough in certain scenarios. As described in detail here, this can be resolved by using:
Connection pools: By pooling your connections, you avoid opening new network connections for calls to the same address and port.
Service endpoints: You don't have a SNAT port restriction to the services secured with service endpoints.
Private endpoints: You don't have a SNAT port restriction to services secured with private endpoints.
NAT gateway: With a NAT gateway, you have 64k outbound SNAT ports that are usable by the resources sending traffic through it.
If I would apply those recommended solutions to your specific scenario, I think the only options are solution 1 (connection pooling) and 4 (azure firewall):
I would certainly recommend connection pooling. This is a minor change in the code running within your app service. If you are a senior programmer you might have already implemented this correctly.
In your situation you want the app service to remain public, so using service endpoints is not an option.
In your situation you want the app service to remain public, so using private endpoints is also not an option.
If connection pooling alone is not enough, then your only option is to implement a NAT gateway or Azure firewall. Azure firewall itself provides 2,496 SNAT ports (source) per public IP address configured. Azure firewall is pretty expensive, so keep that in mind. In short, you'll have to do the following: