Hoe een toepassingsgateway werkt
In dit artikel wordt uitgelegd hoe een toepassingsgateway binnenkomende aanvragen accepteert en deze doorstuurt naar de back-end.
Hoe een toepassingsgateway een aanvraag accepteert
Voordat een client een aanvraag naar een toepassingsgateway verzendt, wordt de domeinnaam van de toepassingsgateway omgezet met behulp van een DNS-server (Domain Name System). Azure bepaalt de DNS-vermelding omdat alle toepassingsgateways zich in het azure.com domein bevinden.
Azure DNS retourneert het IP-adres naar de client. Dit is het front-end-IP-adres van de toepassingsgateway.
De toepassingsgateway accepteert binnenkomend verkeer op een of meer listeners. Een listener is een logische entiteit die controleert op verbindingsaanvragen. Deze is geconfigureerd met een front-end-IP-adres, protocol en poortnummer voor verbindingen van clients naar de toepassingsgateway.
Als een Web Application Firewall (WAF) in gebruik is, controleert de toepassingsgateway de aanvraagheaders en de hoofdtekst, indien aanwezig, op basis van WAF-regels. Met deze actie wordt bepaald of de aanvraag een geldige aanvraag of een beveiligingsrisico is. Als de aanvraag geldig is, wordt deze doorgestuurd naar de back-end. Als de aanvraag niet geldig is en WAF zich in de preventiemodus bevindt, wordt deze geblokkeerd als een beveiligingsrisico. Als deze zich in de detectiemodus bevindt, wordt de aanvraag geëvalueerd en geregistreerd, maar nog steeds doorgestuurd naar de back-endserver.
Azure-toepassing Gateway kan worden gebruikt als een interne load balancer voor toepassingen of als een internetgerichte load balancer voor toepassingen. Een internetgerichte toepassingsgateway maakt gebruik van openbare IP-adressen. De DNS-naam van een internetgerichte toepassingsgateway kan openbaar worden omgezet in het openbare IP-adres. Hierdoor kunnen internetgerichte toepassingsgateways clientaanvragen van internet routeren.
Interne toepassingsgateways gebruiken alleen privé-IP-adressen. Als u een aangepaste of Privé-DNS zone gebruikt, moet de domeinnaam intern kunnen worden omgezet in het privé-IP-adres van de Application Gateway. Daarom kunnen interne load balancers alleen aanvragen van clients routeren met toegang tot een virtueel netwerk voor de toepassingsgateway.
Hoe een toepassingsgateway een aanvraag routeert
Als een aanvraag geldig is en niet wordt geblokkeerd door WAF, evalueert de toepassingsgateway de regel voor aanvraagroutering die is gekoppeld aan de listener. Met deze actie wordt bepaald naar welke back-endpool de aanvraag moet worden doorgestuurd.
Op basis van de regel voor aanvraagroutering bepaalt de toepassingsgateway of alle aanvragen op de listener naar een specifieke back-endpool moeten worden gerouteerd, aanvragen worden doorgestuurd naar verschillende back-endpools op basis van het URL-pad of omleidingsaanvragen naar een andere poort of externe site.
Notitie
Regels worden verwerkt in de volgorde waarin ze worden vermeld in de portal voor v1 SKU.
Wanneer de toepassingsgateway de back-endpool selecteert, wordt de aanvraag verzonden naar een van de goede back-endservers in de pool (y.y.y.y.y). De status van de server wordt bepaald door een statustest. Als de back-endpool meerdere servers bevat, gebruikt de toepassingsgateway een round robin-algoritme om de aanvragen tussen gezonde servers te routeren. Met deze taak worden de aanvragen op de servers verdeeld.
Nadat de toepassingsgateway de back-endserver heeft bepaald, wordt er een nieuwe TCP-sessie geopend met de back-endserver op basis van HTTP-instellingen. HTTP-instellingen geven het protocol, de poort en andere instellingen voor routering op die nodig zijn om een nieuwe sessie met de back-endserver tot stand te brengen.
De poort en het protocol dat wordt gebruikt in HTTP-instellingen bepalen of het verkeer tussen de toepassingsgateway en back-endservers is versleuteld (waardoor end-to-end TLS wordt bereikt) of niet is versleuteld.
Wanneer een toepassingsgateway de oorspronkelijke aanvraag naar de back-endserver verzendt, wordt elke aangepaste configuratie uitgevoerd in de HTTP-instellingen die betrekking hebben op het overschrijven van de hostnaam, het pad en het protocol. Deze actie onderhoudt sessieaffiniteit op basis van cookies, het leegmaken van verbindingen, het selecteren van hostnamen uit de back-end, enzovoort.
Notitie
Als de back-endpool:
- Is een openbaar eindpunt, de toepassingsgateway gebruikt het openbare IP-adres van de front-end om de server te bereiken. Als er geen openbaar IP-adres van de front-end is, wordt er een toegewezen voor de uitgaande externe connectiviteit.
- Bevat een intern om te zetten FQDN of een privé-IP-adres, de toepassingsgateway stuurt de aanvraag naar de back-endserver met behulp van privé-IP-adressen van het exemplaar.
- Bevat een extern eindpunt of een extern om te zetten FQDN, de toepassingsgateway stuurt de aanvraag naar de back-endserver met behulp van het openbare IP-adres van de front-end. Als het subnet service-eindpunten bevat , stuurt de toepassingsgateway de aanvraag naar de service via het privé-IP-adres. DNS-omzetting is gebaseerd op een privé-DNS-zone of aangepaste DNS-server, indien geconfigureerd, of maakt gebruik van de standaard door Azure geleverde DNS. Als er geen openbaar IP-adres van de front-end is, wordt er een toegewezen voor de uitgaande externe connectiviteit.
DNS-omzetting van back-endserver
Wanneer de server van een back-endpool is geconfigureerd met een FQDN (Fully Qualified Domain Name), voert Application Gateway een DNS-zoekopdracht uit om het IP-adres(en) van de domeinnaam op te halen. De IP-waarde wordt opgeslagen in de cache van uw toepassingsgateway, zodat deze sneller de doelen kan bereiken wanneer binnenkomende aanvragen worden verwerkt.
De Application Gateway bewaart deze gegevens in de cache voor de periode die gelijk is aan de TTL van die DNS-record (time to live) en voert een nieuwe DNS-zoekopdracht uit zodra de TTL is verlopen. Als een gateway een wijziging in IP-adres detecteert voor de volgende DNS-query, wordt het verkeer omgeleid naar deze bijgewerkte bestemming. In het geval van problemen zoals de DNS-zoekactie die geen antwoord meer ontvangt of de record niet meer bestaat, blijft de gateway gebruikmaken van het laatst bekende goede IP-adres(en). Dit zorgt voor minimale impact op het gegevenspad.
Belangrijk
- Wanneer u aangepaste DNS-servers gebruikt met het virtuele netwerk van Application Gateway, is het belangrijk dat alle servers consistent reageren met dezelfde DNS-waarden. Wanneer een exemplaar van uw Application Gateway een DNS-query uitgeeft, wordt de waarde van de server gebruikt die als eerste reageert.
- Gebruikers van on-premises aangepaste DNS-servers moeten zorgen voor connectiviteit met Azure DNS via privé-resolver van Azure DNS (aanbevolen) of een VM voor DNS-doorstuurserver wanneer ze een Privé-DNS zone voor privé-eindpunt gebruiken.
Wijzigingen in de aanvraag
Application Gateway voegt zes extra headers toe aan alle aanvragen voordat deze de aanvragen doorstuurt naar de back-end. Deze headers zijn x-forwarded-for, x-forwarded-port, x-forwarded-proto, x-original-host, x-original-url en x-appgw-trace-id. De indeling voor x-forwarded-for-header is een door komma's gescheiden lijst met IP:port.
De geldige waarden voor x-forwarded-proto zijn HTTP of HTTPS. X-doorgestuurde poort geeft de poort aan waar de aanvraag de toepassingsgateway heeft bereikt. X-original-hostheader bevat de oorspronkelijke hostheader waarmee de aanvraag is aangekomen. Deze header is handig in de integratie van Azure-websites, waarbij de binnenkomende hostheader wordt gewijzigd voordat verkeer naar de back-end wordt gerouteerd. Als sessieaffiniteit is ingeschakeld als optie, wordt er een door gateway beheerde affiniteitscookie toegevoegd.
X-appgw-trace-id is een unieke guid die wordt gegenereerd door application gateway voor elke clientaanvraag en wordt weergegeven in de doorgestuurde aanvraag naar het lid van de back-endpool. De guid bestaat uit 32 alfanumerieke tekens die worden weergegeven zonder streepjes (bijvoorbeeld: ac882cd65a2712a0fe1289ec2bb6aee7). Deze guid kan worden gebruikt om een aanvraag te correleren die is ontvangen door de toepassingsgateway en geïnitieerd aan een lid van de back-endpool via de eigenschap transactionId in diagnostische logboeken.
U kunt de toepassingsgateway configureren om aanvraag- en antwoordheaders en -URL's te wijzigen met behulp van HTTP-headers en URL's herschrijven of om het URI-pad te wijzigen met behulp van een pad-onderdrukkingsinstelling. Tenzij dit is geconfigureerd, worden alle binnenkomende aanvragen echter naar de back-end geproxied.