Hoe een applicatiegateway werkt

• 11/16/2019
• 4 minuten om te lezen
• • a
  • j
  • D
  • s
  • v
  • +2

In dit artikel wordt uitgelegd hoe een applicatie-gateway inkomende verzoeken accepteert en deze doorstuurt naar de backend.

Hoe een applicatiegateway een verzoek accepteert

1. Voordat een client een verzoek naar een applicatiegateway verzendt, wordt de domeinnaam van de applicatiegateway omgezet met behulp van een DNS-server (Domain Name System). Azure beheert de DNS-vermelding omdat alle applicatiegateways zich in het domein azure.com bevinden.

2. De Azure DNS retourneert het IP-adres aan de client, namelijk het frontend IP-adres van de applicatiegateway.

3. De applicatiegateway accepteert inkomend verkeer op een of meer listeners. Een listener is een logische entiteit die controleert op verbindingsaanvragen. Deze wordt geconfigureerd met een frontend IP-adres, protocol en poortnummer voor verbindingen van clients naar de application gateway.

4. Als een web application firewall (WAF) in gebruik is, controleert de application gateway de headers van het verzoek en de body, indien aanwezig, aan de hand van WAF-regels. Deze actie bepaalt of het verzoek een geldig verzoek is of een veiligheidsrisico inhoudt. Als het verzoek geldig is, wordt het doorgestuurd naar de backend. Als het verzoek niet geldig is en de WAF staat in Preventie modus, dan wordt het geblokkeerd als een veiligheidsbedreiging. Als de WAF in de detectiemodus staat, wordt het verzoek geëvalueerd en gelogd, maar wel doorgestuurd naar de backendserver.

Azure Application Gateway kan worden gebruikt als een interne applicatie load balancer of als een applicatie load balancer die op internet is gericht. Een applicatiegateway die op het internet is gericht, gebruikt openbare IP-adressen. De DNS-naam van een op het internet gerichte applicatiegateway is publiekelijk herleidbaar tot het openbare IP-adres. Als gevolg hiervan kunnen op het internet gerichte applicatiegateways clientverzoeken vanaf het internet routeren.

Interne applicatiegateways gebruiken alleen privé-IP-adressen. Als u een aangepaste of privé-DNS-zone gebruikt, moet de domeinnaam intern kunnen worden omgezet naar het privé-IP-adres van de applicatiegateway. Daarom kunnen interne loadbalancers alleen verzoeken routeren van clients met toegang tot een virtueel netwerk voor de applicatiegateway.

Hoe een applicatiegateway een verzoek routeert

Als een verzoek geldig is en niet wordt geblokkeerd door WAF, evalueert de applicatiegateway de verzoekrouteringsregel die is gekoppeld aan de luisteraar. Deze actie bepaalt naar welke backend pool het verzoek moet worden gerouteerd.

Op basis van de request routing rule bepaalt de application gateway of alle verzoeken op de listener naar een specifieke backend pool moeten worden gerouteerd, verzoeken naar verschillende backend pools moeten worden gerouteerd op basis van het URL-pad, of verzoeken naar een andere poort of externe site moeten worden omgeleid.

Wanneer de application gateway de backend pool selecteert, stuurt hij het verzoek naar een van de gezonde backend servers in de pool (y.y.y.y). De gezondheid van de server wordt bepaald door een gezondheidssonde. Als de backend-pool meerdere servers bevat, gebruikt de applicatiegateway een round-robin-algoritme om de aanvragen tussen gezonde servers te routeren. Hierdoor worden de aanvragen op de servers in balans gehouden.

Nadat de application gateway de backend server heeft bepaald, opent deze een nieuwe TCP-sessie met de backend server op basis van HTTP-instellingen. HTTP-instellingen specificeren het protocol, de poort en andere routing-gerelateerde instellingen die nodig zijn om een nieuwe sessie met de backend server tot stand te brengen.

De poort en het protocol gebruikt in HTTP-instellingen bepalen of het verkeer tussen de application gateway en backend servers versleuteld is (waardoor end-to-end TLS wordt bereikt) of onversleuteld is.

Wanneer een application gateway het originele verzoek naar de backend server stuurt, honoreert het elke aangepaste configuratie die in de HTTP-instellingen is gemaakt met betrekking tot het overschrijven van de hostnaam, het pad en het protocol. Deze actie handhaaft cookie-gebaseerde sessie affiniteit, verbinding aftappen, host-naam selectie van de backend, enzovoort.

Wijzigingen aan het verzoek

Een application gateway voegt vier extra headers toe aan alle verzoeken voordat het de verzoeken doorstuurt naar de backend. Deze headers zijn x-forwarded-for, x-forwarded-proto, x-forwarded-port, en x-original-host. Het formaat voor de x-forwarded-for header is een door komma’s gescheiden lijst van IP:port.

De geldige waarden voor x-forwarded-proto zijn HTTP of HTTPS. X-forwarded-port specificeert de poort waar het verzoek de applicatie-gateway heeft bereikt. X-original-host header bevat de originele host header waarmee het verzoek is aangekomen. Deze header is nuttig in Azure website integratie, waar de inkomende host header wordt aangepast voordat het verkeer wordt gerouteerd naar de backend. Als sessie affiniteit is ingeschakeld als een optie, dan voegt het een gateway-beheerde affiniteit cookie.

U kunt applicatie gateway configureren om verzoek en antwoord headers en URL te wijzigen door gebruik te maken Rewrite HTTP headers en URL of om het URI-pad te wijzigen door gebruik te maken van een path-override instelling. Echter, tenzij geconfigureerd om dit te doen, alle inkomende verzoeken worden proxied naar de backend.

Lees over application gateway componenten