Lezen in het Engels

Hoe Azure Application Gateway werkt

  • 5 minuten

Azure Application Gateway heeft een reeks onderdelen die combineren om aanvragen veilig te routeren en te verdelen over een groep webservers. Application Gateway bevat de volgende onderdelen:

diagram met Azure Application Gateway-onderdelen.

  • front-end-IP-adres: clientaanvragen worden ontvangen via een front-end-IP-adres. U kunt Application Gateway configureren voor een openbaar IP-adres, een privé-IP-adres of beide. Application Gateway mag niet meer dan één openbaar IP-adres en één privé-IP-adres hebben.
  • Luisteraars: De Application Gateway gebruikt een of meer luisteraars om binnenkomende aanvragen te ontvangen. Een listener accepteert verkeer dat binnenkomt op een opgegeven combinatie van protocol, poort, host en IP-adres. Elke listener stuurt aanvragen naar een back-endpool met servers volgens routeringsregels die u opgeeft. Een listener kan Basic of Multi-site zijn. Een Basic listener stuurt alleen een aanvraag op basis van het pad in de URL. Een multi-site listener kan aanvragen ook routeren met behulp van het hostname-element van de URL. Listeners verwerken ook TLS/SSL-certificaten voor het beveiligen van uw toepassing tussen de gebruiker en Application Gateway.
  • routeringsregels: een routeringsregel verbindt een listener met de back-endpools. Een regel geeft aan hoe u de hostnaam en padelementen in de URL van een aanvraag interpreteert en de aanvraag doorstuurt naar de juiste back-endpool. Een routeringsregel heeft ook een gekoppelde set HTTP-instellingen. Deze HTTP-instellingen geven aan of (en hoe) verkeer wordt versleuteld tussen Application Gateway en de back-endservers. Andere configuratie-informatie omvat Protocol, sessieklevendheid, verbinding lediging, verzoektime-outperiode en gezondheidscontroles.

Taakverdeling in Application Gateway

Application Gateway verdeelt automatisch de verzoeken die naar de servers in elke back-endpool worden verzonden met behulp van een round-robin-mechanisme. Taakverdeling werkt met de OSI-laag 7-routering die wordt geïmplementeerd door Application Gateway-routering. Dit betekent dat aanvragen worden verdeeld op basis van de routeringsparameters (hostnamen en paden) die worden gebruikt door de Application Gateway-regels. Ter vergelijking: andere load balancers, zoals Azure Load Balancer, werken op het niveau OSI-laag 4 en distribueren verkeer op basis van het IP-adres van het doel van een aanvraag.

U kunt sessiestickiness configureren als u ervoor moet zorgen dat alle aanvragen voor een client in dezelfde sessie worden gerouteerd naar dezelfde server in een back-end-pool.

Web Application Firewall

WaF (Web Application Firewall) is een optioneel onderdeel dat binnenkomende aanvragen verwerkt voordat ze een listener bereiken. De Web Application Firewall controleert elke aanvraag op veel veelvoorkomende bedreigingen op basis van het Open Web Application Security Project (OWASP). Veelvoorkomende bedreigingen zijn: SQL-injectie, cross-site scripting, opdrachtinjectie, HTTP-aanvraagsmokkel, HTTP-antwoord splitsen, externe bestandsopname, bots, crawlers en scanners, en schendingen en afwijkingen van HET HTTP-protocol.

OWASP definieert een set algemene regels voor het detecteren van aanvallen. Deze regels worden de Core Rule Set (CRS) genoemd. De regelsets worden continu beoordeeld naarmate aanvallen zich ontwikkelen in verfijning. WAF ondersteunt vier regelsets: CRS 3.2, 3.1, 3.0 en 2.2.9. CRS 3.1 is de standaardwaarde. Indien nodig kunt u ervoor kiezen om alleen specifieke regels in een regelset te selecteren die gericht zijn op bepaalde bedreigingen. Daarnaast kunt u de firewall aanpassen om op te geven welke elementen in een aanvraag moeten worden onderzocht en de grootte van berichten beperken om te voorkomen dat grote uploads uw servers overweldigen.

Back-end-pools

Een back-endpool is een verzameling webservers die kunnen bestaan uit: een vaste set virtuele machines, een virtuele-machineschaalset, een app die wordt gehost door Azure App Services of een verzameling on-premises servers.

Elke back-endpool heeft een gekoppelde load balancer die werk over de pool distribueert. Bij het configureren van de pool geeft u het IP-adres of de naam van elke webserver op. Alle servers in de back-endpool moeten op dezelfde manier worden geconfigureerd, met inbegrip van hun beveiligingsinstellingen.

Als u TLS/SSL gebruikt, heeft de back-endpool een HTTP-instelling die verwijst naar een certificaat dat wordt gebruikt om de back-endservers te verifiëren. De gateway versleutelt het verkeer opnieuw met behulp van dit certificaat voordat het naar een van uw servers in de back-endpool wordt verzonden.

Als u Azure App Service gebruikt om de back-endtoepassing te hosten, hoeft u geen certificaten in Application Gateway te installeren om verbinding te maken met de back-endpool. Alle communicatie wordt automatisch versleuteld. Application Gateway vertrouwt de servers omdat Azure deze beheert.

Application Gateway gebruikt een regel om op te geven hoe de berichten die worden ontvangen op de binnenkomende poort naar de servers in de back-endpool worden doorgestuurd. Als de servers TLS/SSL gebruiken, moet u de regel configureren om het volgende aan te geven:

  • Dat uw servers verkeer via het HTTPS-protocol verwachten.
  • Welk certificaat moet worden gebruikt om verkeer te versleutelen en de verbinding met een server te verifiëren.

Routering van Application Gateway

Wanneer de gateway een clientaanvraag doorstuurt naar een webserver in de back-endpool, wordt er een set regels gebruikt die zijn geconfigureerd voor de gateway om te bepalen waar de aanvraag naartoe moet gaan. Er zijn twee primaire methoden voor het routeren van dit clientaanvraagverkeer: routering op basis van paden en routering met meerdere sites.

Routering op basis van pad

Padgebaseerde routering verzendt aanvragen met verschillende URL-paden naar verschillende pools van back-endservers. U kunt bijvoorbeeld aanvragen met het pad /video/* doorsturen naar een back-endpool met servers die zijn geoptimaliseerd voor het verwerken van videostreaming en directe /images/* aanvragen naar een groep servers die het ophalen van afbeeldingen verwerken.

diagram met padgebaseerde routering in Azure Application Gateway.

Routering met meerdere sites

Routering met meerdere sites configureert meer dan één webtoepassing op hetzelfde Application Gateway-exemplaar. In een configuratie met meerdere sites registreert u meerdere DNS-namen (CNAMEs) voor het IP-adres van de toepassingsgateway, waarbij u de naam van elke site opgeeft. Application Gateway gebruikt afzonderlijke listeners om te wachten op aanvragen voor elke site. Elke listener geeft de aanvraag door aan een andere regel, waarmee de aanvragen naar servers in een andere back-endpool kunnen worden doorgestuurd. U kunt bijvoorbeeld alle aanvragen voor http://contoso.com doorsturen naar servers in één back-endpool en aanvragen voor http://fabrikam.com naar een andere back-endpool. In het volgende diagram ziet u deze configuratie:

diagram met routering met meerdere sites in Azure Application Gateway.

Configuraties met meerdere sites zijn handig voor het ondersteunen van multitenant-toepassingen, waarbij elke tenant een eigen set virtuele machines of andere resources heeft die als host fungeren voor een webtoepassing.

Application Gateway-routering bevat ook de volgende functies:

  • Omleiding. Omleiding kan worden gebruikt voor een andere site of van HTTP naar HTTPS.
  • HTTP-headers opnieuw schrijven. Met HTTP-headers kunnen de client en server parameterinformatie doorgeven met de aanvraag of de reactie.
  • aangepaste foutpagina's. Met Application Gateway kunt u aangepaste foutpagina's maken in plaats van standaardfoutpagina's weer te geven. U kunt uw eigen huisstijl en indeling gebruiken met behulp van een aangepaste foutpagina.

TLS/SSL-beëindiging

Wanneer u de TLS/SSL-verbinding bij de toepassingsgateway beëindigt, wordt de CPU-intensieve TLS/SSL-beëindigingsbelasting van uw servers uitbesteed. U hoeft ook geen certificaten te installeren en TLS/SSL op uw servers te configureren.

Als u end-to-end-versleuteling nodig hebt, kan Application Gateway het verkeer op de gateway ontsleutelen met behulp van uw persoonlijke sleutel en vervolgens opnieuw versleutelen met de openbare sleutel van de service die wordt uitgevoerd in de back-endpool.

Verkeer gaat via een front-end-poort naar de gateway. U kunt veel poorten openen en Application Gateway kan berichten ontvangen op een van deze poorten. Een listener is het eerste dat uw verkeer tegenkomt wanneer het de gateway binnengaat via een poort. De listener is ingesteld om te luisteren naar een specifieke hostnaam en een specifieke poort op een specifiek IP-adres. De listener kan een TLS/SSL-certificaat gebruiken om het verkeer dat de gateway binnenkomt, te ontsleutelen. De listener gebruikt vervolgens een regel die u definieert om de binnenkomende aanvragen naar een back-endpool te leiden.

diagram met TLS/SSL-beëindiging in Azure Application Gateway.

Als u uw website of webtoepassing beschikbaar maakt via de toepassingsgateway, betekent dit ook dat u uw servers niet rechtstreeks met het web verbindt. Er wordt alleen poort 80 of poort 443 op de applicatiegateway blootgelegd, die vervolgens naar de back-end poolserver wordt doorgestuurd. In deze configuratie zijn uw webservers niet rechtstreeks toegankelijk vanaf internet, waardoor de kwetsbaarheid voor aanvallen van uw infrastructuur wordt verminderd.

Gezondheidsonderzoeken

Gezondheidstests bepalen welke servers beschikbaar zijn voor load balancing in een back-endpool. Application Gateway gebruikt een statustest om een aanvraag naar een server te verzenden. Wanneer de server een HTTP-antwoord retourneert met een statuscode tussen 200 en 399, wordt de server beschouwd als in orde. Als u geen statustest configureert, maakt Application Gateway een standaardtest die 30 seconden wacht voordat wordt besloten dat een server niet beschikbaar is. Gezondheidscontroles zorgen ervoor dat verkeer niet wordt doorgestuurd naar een niet-reagerend of mislukt webeindpunt in de back-endpool.

Automatisch schalen

Application Gateway biedt ondersteuning voor automatisch schalen en kan omhoog of omlaag worden geschaald op basis van veranderende verkeersbelastingspatronen. Met automatisch schalen wordt ook de vereiste voor het kiezen van een implementatiegrootte of het aantal exemplaren tijdens het inrichten verwijderd.

WebSocket en HTTP/2-verkeer

Application Gateway biedt systeemeigen ondersteuning voor de WebSocket- en HTTP/2-protocollen. De WebSocket- en HTTP/2-protocollen maken volledige duplex-communicatie mogelijk tussen een server en een client via een langlopende TCP-verbinding. Dit type communicatie is interactiever tussen de webserver en de client en kan bidirectioneel zijn zonder dat polling is vereist in implementaties op basis van HTTP. Deze protocollen hebben weinig overhead (in tegenstelling tot HTTP) en kunnen dezelfde TCP-verbinding opnieuw gebruiken voor meerdere aanvragen/antwoorden, wat resulteert in een efficiënter resourcegebruik. Deze protocollen zijn ontworpen om te werken via traditionele HTTP-poorten van 80 en 443.