One of the most frequently encountered and troublesome situations with the integration of application gateway and app services is that the app services might have a private link enabled. When a client reaches the app service directly with its public fully qualified domain name, there will be a successful response regardless of what the app’s private link connects to but when the client reaches the same app through the application gateway, it will get a 502 or 403. The 502 error occurs when the app service is added as a backend pool member using its ip address rather than the public fully qualified domain name. The 403 error occurs because Microsoft does not route the traffic over the public ip network between the gateway and the app service but chooses to determine the routing. If the app were reachable, a proper response would be 200 for success or 404 for no web page available.
An app service might want a private link for many purposes
but most of them would have been equally solvable via access rules. For
example, if an app service wanted to communicate with another app service
privately, it could establish a private link between the two comprising of
private endpoints designated with a private ip address for each of the two app
services. But this can also be equivalently set up with an IP address access
rule that puts the remote app service as the allowed traffic origin in the
local configuration of the app service. The rule would be specified in both app
services’ access restrictions. When such a rule is added, the gateway must also
be allowed with its own access rule in both app services access restrictions
assuming clients could target each app service independently through the
gateway. By maintaining connectivity to be over IP versus links, the app services
will continue to give successful response through the application gateway which
is a layer-7 reverse proxy and load balancer.
Therefore, the rule of thumb should be to not require
private endpoint for any app service. But if the private endpoints for the app
services cannot be removed, there are a few options to try although none is
guaranteed to work. These options are explained along with the concepts they
make use of.
The first is that the virtual network in which the
application gateway is deployed, can communicate with app services over either
a service endpoint or a private endpoint. Care must be taken to ensure that
this endpoint is setup in the subnet to which the application gateway is
deployed in the virtual network. The presence of such an endpoint alone does
not guarantee that the client will not get the dreaded 502/403 errors when trying
to reach an app service through the gateway because by nature of the
application gateway as a reverse proxy, its frontend communication with the
client is split from the backend communication with the app service. Also, the
app service might be deployed in its own virtual network independent from that
of the application gateway. The app service and application gateway have
independent public domains when they are initially setup with the app service
having an azurewebsites.net domain by default and the application gateway
having the cloudapp.net domain by default. Their public access and http/https-based
operations makes them more web facing rather than infrastructure facing
resources. The private links that they create with their respective virtual
networks or a shared one whenever possible gives them a private ip address on
the infrastructure side but provides no routing which must be established independently.
This brings us to the second point.
The second is that the infrastructure can determine the
routing of traffic between the gateway and the app service. If they are in two
different virtual networks, those can be peered to allow communication
originating anywhere in one network to reach anywhere else in the other
network. Putting all app services as well as the gateway in one virtual network
might solve that problem for the infrastructure but the app services might
still be in different subnets. Virtual network peering allows many to many
communications between the participating networks otherwise private endpoints
enable one-to-one communication between the gateway and the app service. Creating that private endpoint in the subnet
to which the gateway is deployed is helpful to gather private inbound traffic
to the gateway. This is reflected in the private addresses assigned to the
resources. In the peered network, the resource will have a private address on
each side of the peering. With a private endpoint only one private ip address
is assigned to the resource. This same address can be specified as the
representation of the app service to be included as the backend pool member of
the application gateway just as much as the public ip address of the app
service but its best to refer to the app service with the builitin drop-down
option and the app-services’ public fully qualified domain name.
This brings us to the third point, that name, address, and
routing determine the way gateway communicates with the app services and
remains true regardless of whether it is over private network or public
network. The name resolution is facilitated by an private DNS server when
setting up a private endpoint for the app service to communicate with the
gateway. The address is issues immediately on establishing a private endpoint
in the subnet/vnet combination specified during the creation of the endpoint.
The routing however is governed not just by the peering or the specific routing
rules but also by network security groups and access control lists. This is
where care must be taken to reuse the same NSG, ACL or policy across all
participating subnets/vnets. Also routing
and network and for that matter private connectivity need not be established if
we allow the built-in capabilities for routing that comes with service
endpoints and Microsoft based routing.
Whether we use the first, second or the third option, it
must be noted that the ways to validate the connections are with the help of
probe and client calls and neither can be done away with. While the probe tests
the backend responses, the client calls test the front-end. All other features
of the application gateway maintained same, the communication with backend pool
members public over public ip and private link connectivity have been mentioned
in this article. While the IP connectivity allows us to rely on the network to
route the traffic, the private link connectivity requires us to create inbounds
and outbounds properly along with necessary routing and associated rules.
Reference: Article on
how to author rewrite rules.
No comments:
Post a Comment