Azure-toepassing Gateway-functies

Azure Application Gateway is een load balancer voor webverkeer waarmee u het verkeer naar uw webapps kunt beheren.

Application Gateway conceptual

Notitie

Voor webworkloads raden we u ten zeerste aan azure DDoS-beveiliging en een webtoepassingsfirewall te gebruiken om te beschermen tegen opkomende DDoS-aanvallen. Een andere optie is om Azure Front Door samen met een webtoepassingsfirewall te gebruiken. Azure Front Door biedt beveiliging op platformniveau tegen DDoS-aanvallen op netwerkniveau. Zie de beveiligingsbasislijn voor Azure-services voor meer informatie.

Application Gateway bevat de volgende functies:

Ssl/TLS-beëindiging (Secure Sockets Layer)

Application Gateway ondersteunt SSL/TLS-beëindiging bij de gateway, waarna verkeer doorgaans niet-versleuteld naar de back-endservers stroomt. Met deze functie voorkomt u prijzige overhead voor het versleutelen en ontsleutelen voor uw webservers. Maar soms is niet-versleutelde communicatie met de servers geen acceptabele optie. Dit kan komen door beveiligingsvereisten, nalevingsvereisten of de toepassing kan alleen een beveiligde verbinding accepteren. Voor deze toepassingen ondersteunt application gateway end-to-end SSL/TLS-versleuteling.

Zie Overzicht van SSL-beëindiging en end-to-end SSL met Application Gateway voor meer informatie

Automatisch schalen

Application Gateway Standard_v2 ondersteunt automatisch schalen en kan omhoog of omlaag schalen op basis van veranderende verkeersbelastingspatronen. Automatisch schalen heft ook de vereiste op om tijdens het inrichten een implementatiegrootte of het aantal instanties te kiezen.

Zie Wat is Azure-toepassing Gateway v2 voor meer informatie over de functies van Application Gateway Standard_v2.

Zoneredundantie

Een Standard_v2 Application Gateway kan meerdere Beschikbaarheidszones omvatten, wat betere fouttolerantie biedt en de noodzaak om afzonderlijke Application Gateways in elke zone in te richten.

Statisch VIP

De toepassingsgateway Standard_v2 SKU ondersteunt exclusief statisch VIP-type. Dit zorgt ervoor dat het VIP dat is gekoppeld aan de toepassingsgateway niet verandert, zelfs niet gedurende de levensduur van de Application Gateway.

Web Application Firewall

Web Application Firewall (WAF) is een service die gecentraliseerde beveiliging van uw webtoepassingen biedt tegen veelvoorkomende aanvallen en beveiligingsproblemen. WAF is gebaseerd op regels uit de kernregel OWASP (Open Web Application Security Project) ingesteld op 3.1 (alleen WAF_v2), 3.0 en 2.2.9.

Webtoepassingen zijn in toenemende mate het doel van aanvallen die gebruikmaken van veelvoorkomende bekende beveiligingsproblemen. Veelvoorkomende aanvallen zijn hierbij onder andere aanvallen met SQL-injecties en aanvallen via scripting op meerdere sites. Het kan een hele uitdaging zijn om dergelijke aanvallen in toepassingscode te voorkomen en dit kan tevens veel onderhoud, patching en controle vereisen op meerdere lagen van de toepassingstopologie. Een gecentraliseerde firewall voor webtoepassingen maakt het beveiligingsbeheer veel eenvoudiger en biedt toepassingsbeheerders meer veiligheid tegen bedreigingen of aanvallen. Een WAF-oplossing kan ook sneller reageren op een beveiligingsrisico door een patch voor een bekend beveiligingsprobleem toe te passen op een centrale locatie in plaats van elke afzonderlijke webtoepassing te beveiligen. Bestaande toepassingsgateways kunnen eenvoudig worden geconverteerd naar een toepassingsgateway met Web Application Firewall.

Raadpleeg application DDoS-beveiliging voor hulp bij het gebruik van Azure WAF met Application Gateway om te beschermen tegen DDoS-aanvallen. Zie Wat is Azure Web Application Firewall voor meer informatie.

Controller van inkomend verkeer voor AKS

Met Application Gateway Ingress Controller (AGIC) kunt u Application Gateway gebruiken als inkomend verkeer voor een AKS-cluster (Azure Kubernetes Service).

De ingangscontroller wordt uitgevoerd als een pod in het AKS-cluster en verbruikt Kubernetes-toegangsbeheerbronnen en converteert deze naar een Application Gateway-configuratie, waardoor de gateway verkeer naar de Kubernetes-pods kan verdelen. De ingangscontroller ondersteunt alleen Application Gateway-Standard_v2- en WAF_v2-SKU's.

Zie Application Gateway Ingress Controller (AGIC) voor meer informatie.

URL-gebaseerde routering

Met routering op basis van URL-pad kunt u verkeer routeren naar back-endserverpools op basis van URL-paden van de aanvraag. Een van de scenario's is het routeren van aanvragen voor verschillende inhoudstypen naar een andere pool.

Aanvragen voor http://contoso.com/video/* worden bijvoorbeeld doorgestuurd naar VideoServerPool en aanvragen voor http://contoso.com/images/* worden doorgestuurd naar ImageServerPool. Als geen van de padpatronen overeenkomen, wordt DefaultServerPool geselecteerd.

Zie overzicht van routering op basis van URL-pad voor meer informatie.

Hosting van meerdere sites

Met Application Gateway kunt u routering configureren op basis van hostnaam of domeinnaam voor meer dan één webtoepassing op dezelfde toepassingsgateway. Dit stelt u in staat om een efficiëntere topologie voor uw implementaties te configureren door maximaal 100 websites toe te voegen aan één toepassingsgateway. Elke website kan worden omgeleid naar een eigen back-endpool. Drie domeinen - contoso.com, fabrikam.com en adatum.com - wijzen bijvoorbeeld naar het IP-adres van de toepassingsgateway. U maakt dat drie listeners voor meerdere sites, en configureert elke listener voor de respectieve poort en protocolinstelling.

http://contoso.com Aanvragen voor worden doorgestuurd naar ContosoServerPool, http://fabrikam.com worden doorgestuurd naar FabrikamServerPool, enzovoort.

Op dezelfde manier kunnen twee subdomeinen van hetzelfde bovenliggende domein worden gehost op dezelfde implementatie van een toepassingsgateway. Voorbeelden van subdomeinen die worden gehost op één toepassingsgateway-implementatie, zijn http://blog.contoso.com en http://app.contoso.com. Zie Application Gateway meerdere sites hosten voor meer informatie.

U kunt ook hostnamen met jokertekens definiëren in een listener voor meerdere sites (maximaal vijf hostnamen per listener). Zie hostnamen met jokertekens in listener voor meer informatie.

Omleiding

Een veelvoorkomend scenario voor veel webtoepassingen is de ondersteuning van automatische HTTP-naar-HTTPS-omleiding zodat alle communicatie tussen een toepassing en gebruikers plaatsvindt via een versleuteld pad.

In het verleden hebt u mogelijk technieken gebruikt, zoals het maken van een toegewezen pool waarvan het enige doel is om aanvragen om te leiden die worden ontvangen op HTTP naar HTTPS. Application Gateway ondersteunt het omleiden van verkeer op de Application Gateway. Dit vereenvoudigt de configuratie van toepassingen, optimaliseert het resourcegebruik en biedt ondersteuning voor nieuwe omleidingsscenario's, waaronder de globale en op pad gebaseerde omleidingen. Ondersteuning voor Application Gateway-omleiding is niet beperkt tot http-naar-HTTPS-omleiding. Dit is een algemeen omleidingsmechanisme, zodat u op basis van regels kunt omleiden van en naar elke poort die u gebruikt. Ook omleiding naar een externe site wordt ondersteund.

Ondersteuning voor Application Gateway-omleiding biedt de volgende mogelijkheden:

  • Globale omleiding van de ene poort naar de andere poort op de Gateway. Hierdoor is HTTP-naar-HTTPS-omleiding op een site mogelijk.
  • Padgebaseerde omleiding. Dit type omleiding maakt HTTP-naar-HTTPS-omleiding alleen mogelijk op een specifiek sitegebied, bijvoorbeeld een winkelwagengebied aangegeven door /cart/*.
  • Omleiden naar een externe site.

Zie application gateway-omleidingsoverzicht voor meer informatie.

Sessieaffiniteit

De functie Sessieaffiniteit op basis van cookies is handig als u een gebruikerssessie op dezelfde server wilt behouden. Met behulp van door gateway beheerde cookies kan application gateway volgend verkeer van een gebruikerssessie naar dezelfde server leiden voor verwerking. Dit is belangrijk wanneer de sessiestatus lokaal wordt opgeslagen op de server voor een gebruikerssessie.

Zie Hoe een toepassingsgateway werkt voor meer informatie.

Websocket- en HTTP-/2-verkeer

Application Gateway biedt systeemeigen ondersteuning voor de WebSocket- en HTTP-/2-protocollen. Er is geen door de gebruiker configureerbare instelling om selectief WebSocket-ondersteuning in of uit te schakelen.

De WebSocket- en HTTP-/2-protocollen maken full-duplex-communicatie tussen een server en een client mogelijk via een langdurige TCP-verbinding. Dit maakt een meer interactieve communicatie mogelijk tussen de webserver en de client, die bidirectioneel kan zijn zonder dat hiervoor polling nodig is, zoals 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.

Zie WebSocket-ondersteuning en HTTP/2-ondersteuning voor meer informatie.

Verwerkingsstop voor verbindingen

Verbinding maken afvoer helpt u bij het correct verwijderen van leden van back-endpools tijdens geplande service-updates of problemen met de back-endstatus. Deze instelling wordt ingeschakeld via de back-endinstelling en wordt toegepast op alle leden van de back-endpool tijdens het maken van de regel. Zodra deze optie is ingeschakeld, zorgt de toepassingsgateway ervoor dat alle registratie-exemplaren van een back-endpool geen nieuwe aanvragen ontvangen terwijl bestaande aanvragen binnen een geconfigureerde tijdslimiet kunnen worden voltooid. Dit geldt voor gevallen waarin back-endexemplaren zijn:

  • expliciet verwijderd uit de back-endpool na een configuratiewijziging door een gebruiker
  • gerapporteerd als beschadigd door de statustests of
  • verwijderd tijdens een inschaalbewerking

De enige uitzondering is wanneer aanvragen nog steeds worden geproxied voor de registratie van exemplaren vanwege door gateway beheerde sessieaffiniteit.

Het leegmaken van verbindingen wordt ook gehonoreerd voor WebSocket-verbindingen. Verbinding maken afvoer wordt aangeroepen voor elke update naar de gateway. Als u wilt voorkomen dat er verbinding verloren gaat met bestaande leden van de back-endpool, moet u het leegmaken van verbindingen inschakelen.

Zie Back-end-Instellingen-configuratie voor meer informatie over tijdslimieten.

Aangepaste foutenpagina'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.

Zie Aangepaste fouten voor meer informatie.

HTTP-headers en URL opnieuw schrijven

Met HTTP-headers kan de client en server aanvullende informatie doorgeven aan de aanvraag of het antwoord. Als u deze HTTP-headers herschrijft, kunt u verschillende belangrijke scenario's uitvoeren, zoals:

  • Beveiligingsgerelateerde headervelden toevoegen, zoals HSTS/X-XSS-Protection.
  • Het verwijderen van antwoordheadervelden waarmee gevoelige informatie kan worden weergegeven.
  • Poortgegevens verwijderen uit X-Forwarded-For-headers.

Application Gateway en WAF v2-SKU ondersteunen de mogelijkheid om HTTP-aanvraag- en antwoordheaders toe te voegen, te verwijderen of bij te werken, terwijl de aanvraag- en antwoordpakketten tussen de client- en back-endpools worden verplaatst. U kunt ook URL's, parameters voor querytekenreeksen en de hostnaam herschrijven. Met routering op basis van URL-pad en URL-pad kunt u aanvragen routeren naar een van de back-endpools op basis van het oorspronkelijke pad of het herschreven pad, met behulp van de optie padtoewijzing opnieuw beoordelen.

Het biedt ook de mogelijkheid om voorwaarden toe te voegen om ervoor te zorgen dat de opgegeven headers of URL alleen worden herschreven wanneer aan bepaalde voorwaarden is voldaan. Deze voorwaarden zijn gebaseerd op de informatie in de aanvraag en het antwoord.

Zie HTTP-headers en URL herschrijven voor meer informatie.

Grootte

Application Gateway-Standard_v2 kunnen worden geconfigureerd voor automatische schaalaanpassing of implementaties met een vaste grootte. De v2-SKU biedt geen verschillende instantiegrootten. Zie Voor meer informatie over de prestaties en prijzen van v2 de automatische schaalaanpassing van V2 en inzicht in prijzen.

Application Gateway Standard (v1) wordt aangeboden in drie grootten: Small, Medium en Large. Kleine exemplaargrootten zijn bedoeld voor het ontwikkelen en testen van scenario's.

Zie Servicelimieten voor Application Gateway voor een volledige lijst van toepassingsgateway-limieten.

In de volgende tabel ziet u een gemiddelde doorvoer van prestaties voor elk exemplaar van de toepassingsgateway v1 waarvoor SSL-offload is ingeschakeld:

Gemiddelde antwoordgrootte van back-endpagina Klein Gemiddeld Groot
6 kB 7,5 Mbps 13 Mbps 50 Mbps
100 kB 35 Mbps 100 Mbps 200 Mbps

Notitie

Deze waarden zijn geschatte waarden voor de doorvoer van een toepassingsgateway. De werkelijke doorvoer is afhankelijk van verschillende omgevingsgegevens, zoals de gemiddelde paginagrootte, de locatie van back-endexemplaren en de verwerkingstijd voor een pagina. Voor nauwkeurige prestatiecijfers moet u uw eigen tests uitvoeren. Deze waarden worden alleen geboden als richtlijn voor de capaciteitsplanning.

Vergelijking van versiefuncties

Zie Wat is Azure-toepassing Gateway v2 voor een vergelijking van functies in Application Gateway v1-v2.

Volgende stappen