Hoe Azure-toepassing Gateway werkt
Azure-toepassing 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:
- Front-end-IP-adres: clientaanvragen worden ontvangen via een front-end-IP-adres. U kunt Application Gateway configureren met een openbaar IP-adres, een privé-IP-adres, of met beide. Application Gateway mag niet meer dan één openbaar IP-adres en één privé-IP-adres hebben.
- Listeners: Application Gateway gebruikt een of meer listeners om binnenkomende aanvragen te ontvangen. Een listener accepteert verkeer dat binnenkomt bij een specifieke combinatie van protocol, poort, host en IP-adres. Met elke listener worden aanvragen naar een back-endpool met servers gerouteerd, volgens de regels voor doorsturen die u opgeeft. Een listener kan een basislistener zijn of een listener met meerdere sites. Een Basic-listener routeert alleen een aanvraag op basis van het pad in de URL. Een listener voor meerdere sites kan aanvragen ook routeren met behulp van het hostnaamelement 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 regel voor doorsturen heeft ook een gekoppelde set met 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, Sessie stickiness, Verbinding maken ion draining, Time-outperiode aanvragen en Statustests.
Taakverdeling in Application Gateway
Application Gateway verdeelt automatisch de aanvragen 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 met Application Gateway-routering. Dit betekent dat aanvragen worden verdeeld op basis van de routeringsparameters (hostnamen en -paden) die worden gebruikt voor 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 sessie stickiness configureren als u ervoor moet zorgen dat alle aanvragen voor een client in dezelfde sessie worden gerouteerd naar dezelfde server in een back-endpool.
Web Application Firewall
De WAF (Web Application Firewall) is een optioneel onderdeel waarmee binnenkomende aanvragen worden 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 CRS (Core Rule Set) genoemd. De regelsets worden continu gecontroleerd, aangezien aanvallen steeds complexer worden. WAF ondersteunt vier regelsets: CRS 3.2, 3.1, 3.0 en 2.2.9. CRS 3.1 is de standaardwaarde. Indien nodig kunt ervoor kiezen om alleen specifieke regels in een regelset te selecteren, met het oog op bepaalde specifieke bedreigingen. Bovendien kunt u de firewall aanpassen om op te geven welke elementen in een aanvraag moeten worden onderzocht, en kunt u de grootte van berichten beperken om te voorkomen dat servers worden overbelast door toedoen van enorm grote uploads.
Back-endpools
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 deze met Azure worden beheerd.
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 voor het versleutelen van verkeer en het verifiëren van de verbinding met een server.
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.
Padgebaseerde routering
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.
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, waardoor de aanvragen kunnen worden gerouteerd naar servers in een andere back-endpool. U kunt bijvoorbeeld alle aanvragen voor http://contoso.com servers in de ene back-endpool en aanvragen http://fabrikam.com voor een andere back-endpool doorsturen. In het volgende diagram ziet u deze configuratie:
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 genereren. Met HTTP-headers kan de client en server parametergegevens doorgeven aan de aanvraag of het antwoord.
- 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 lay-out hanteren door een aangepaste foutpagina te gebruiken.
TLS/SSL-beëindiging
Wanneer u de TLS/SSL-verbinding op de toepassingsgateway beëindigt, wordt de CPU-intensieve TLS/SSL-beëindigingsworkload van uw servers offload. 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-endpoort naar de gateway. U kunt meerdere poorten openen en Application Gateway kan berichten op al deze poorten ontvangen. Een listener is het eerste wat uw verkeer tegenkomt bij het binnenkomen in de gateway 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.
Door uw website of webtoepassing via de toepassingsgateway beschikbaar te maken hoeft u uw servers niet rechtstreeks te verbinden met internet. U opent alleen poort 80 of poort 443 op de toepassingsgateway, die vervolgens wordt doorgestuurd naar de back-endpoolserver. In deze configuratie zijn uw webservers niet rechtstreeks toegankelijk vanaf internet, waardoor de kwetsbaarheid voor aanvallen van uw infrastructuur wordt verminderd.
Statuscontroles
Statustests bepalen welke servers beschikbaar zijn voor taakverdeling 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 statuscontrole configureert, wordt in Application Gateway een standaardcontrole gemaakt. Het duurt vervolgens 30 seconden voordat wordt besloten dat een server niet beschikbaar is. Statustests zorgen ervoor dat verkeer niet wordt omgeleid 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. Automatisch schalen heft ook de vereiste op om tijdens het inrichten een implementatiegrootte of het aantal instanties te kiezen.
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 de traditionele HTTP-poorten: 80 en 443.