Azure-toepassing Gateway-onderdelen configureren
Azure-toepassing Gateway heeft een reeks onderdelen die worden gecombineerd om aanvragen te routeren naar een groep webservers en om de status van deze webservers te controleren. Deze onderdelen omvatten het front-end-IP-adres, back-endpools, routeringsregels, statustests en listeners. Als optie kan de gateway ook een firewall implementeren.
Dingen die u moet weten over Application Gateway-onderdelen
Laten we eens kijken hoe de onderdelen van een toepassingsgateway samenwerken.
Het front-end-IP-adres ontvangt de clientaanvragen.
Een optionele Web Application Firewall controleert binnenkomend verkeer op veelvoorkomende bedreigingen voordat de aanvragen de listeners bereiken.
Een of meer listeners ontvangen het verkeer en sturen de aanvragen door naar de back-endpool.
Routeringsregels definiëren hoe u de aanvraag analyseert om de aanvraag naar de juiste back-endpool te leiden.
Een back-endpool bevat webservers voor resources zoals virtuele machines of virtuele-machineschaalsets. Elke pool heeft een load balancer om de workload over de resources te verdelen.
Statustests bepalen welke back-endpoolservers beschikbaar zijn voor taakverdeling.
In het volgende stroomdiagram ziet u hoe de Application Gateway-onderdelen samenwerken om verkeersaanvragen tussen de front-end- en back-endpools in uw configuratie te sturen.
Front-end-IP-adres
Clientaanvragen worden ontvangen via uw front-end-IP-adres. Uw toepassingsgateway kan een openbaar of privé-IP-adres hebben, of beide. U kunt slechts één openbaar IP-adres en slechts één privé-IP-adres hebben.
Web Application Firewall (optioneel)
U kunt Azure Web Application Firewall inschakelen voor Azure-toepassing Gateway om binnenkomende aanvragen te verwerken voordat ze uw listener bereiken. De firewall controleert elke aanvraag op bedreigingen op basis van het Open Web Application Security Project (OWASP). Veelvoorkomende bedreigingen zijn SQL-injectie, cross-site scripting, opdrachtinjectie, smokkelen van HTTP-aanvragen en het splitsen van reacties en het opnemen van externe bestanden. Andere bedreigingen kunnen afkomstig zijn van bots, crawlers, scanners en schendingen van het HTTP-protocol en afwijkingen.
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. Azure Web Application Firewall ondersteunt twee regelsets: CRS 2.2.9 en CRS 3.0. CRS 3.0 is de standaard en recentere van deze regelsets. Indien nodig kunt u ervoor kiezen om alleen specifieke regels in een regelset te selecteren om bepaalde bedreigingen aan te pakken. 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.
Listeners
Listeners accepteren 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 uw routeringsregels. Een listener kan een basislistener zijn of een listener met meerdere sites. Met een basislistener kan een aanvraag alleen worden gerouteerd 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.
Regels voor doorsturen
Een routeringsregel verbindt uw listeners met de back-endpools. Een regel geeft aan hoe u de hostnaam en padelementen in de URL van een aanvraag interpreteert en de aanvraag vervolgens 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, verbindingsafvoer, time-outperiode aanvragen en statustests.
Back-endpools
Een back-endpool verwijst naar een verzameling webservers. Tijdens het configureren van de pool geeft u het IP-adres van elke webserver op en de poort waarop deze luistert naar aanvragen. Elke pool kan een vaste set virtuele machines, virtuele-machineschaalsets, een app die wordt gehost door Azure-app Services of een verzameling on-premises servers opgeven. Elke back-endpool heeft een gekoppelde load balancer die werk over de pool distribueert.
Statuscontroles
Statustests bepalen welke servers in uw back-endpool beschikbaar zijn voor taakverdeling. Application Gateway maakt gebruik van een statuscontrole om een aanvraag te verzenden naar de server. 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 een server wordt geïdentificeerd als niet beschikbaar (niet in orde).