Configuratie van HTTP-instellingen voor Application Gateway
De toepassingsgateway stuurt verkeer naar de back-endservers met behulp van de configuratie die u hier opgeeft. Nadat u een HTTP-instelling hebt gemaakt, moet u deze koppelen aan een of meer regels voor aanvraagroutering.
Affiniteit op basis van cookies
Azure-toepassing Gateway maakt gebruik van door gateway beheerde cookies voor het onderhouden van gebruikerssessies. Wanneer een gebruiker de eerste aanvraag naar Application Gateway verzendt, wordt er een affiniteitscookie ingesteld in het antwoord met een hashwaarde die de sessiegegevens bevat, zodat de volgende aanvragen met de affiniteitscookie worden doorgestuurd naar dezelfde back-endserver voor het behoud van de plakkerigheid.
Deze functie is handig als u een gebruikerssessie op dezelfde server wilt behouden en wanneer de sessiestatus lokaal op de server wordt opgeslagen voor een gebruikerssessie. Als de toepassing geen affiniteit op basis van cookies kan verwerken, kunt u deze functie niet gebruiken. Als u deze wilt gebruiken, moet u ervoor zorgen dat de klanten cookies ondersteunen.
Notitie
Sommige scans van beveiligingsproblemen kunnen de cookie application gateway-affiniteit markeren omdat de secure- of HttpOnly-vlaggen niet zijn ingesteld. Bij deze scans wordt niet rekening gehouden met het feit dat de gegevens in de cookie worden gegenereerd met behulp van een hash in één richting. De cookie bevat geen gebruikersgegevens en wordt uitsluitend gebruikt voor routering.
De Chromium-browser v80-update heeft een mandaat gebracht waarbij HTTP-cookies zonder samesite-kenmerk moeten worden behandeld als SameSite=Lax. Voor CORS-aanvragen (Cross-Origin Resource Sharing), als de cookie moet worden verzonden in een context van derden, moet deze SameSite=None gebruiken ; Beveiligde kenmerken en deze moeten alleen via HTTPS worden verzonden. Anders verzendt de browser in een HTTP-scenario de cookies niet in de context van derden. Het doel van deze update van Chrome is om de beveiliging te verbeteren en CSRF-aanvallen (Cross-Site Request Forgery) te voorkomen.
Om deze wijziging te ondersteunen, zal Application Gateway (alle SKU-typen) vanaf 17 februari 2020 een andere cookie met de naam ApplicationGatewayAffinityCORS injecteren naast de bestaande ApplicationGatewayAffinity-cookie . De cookie ApplicationGatewayAffinityCORS heeft nog twee kenmerken toegevoegd ("SameSite=None; Veilig") zodat plaksessies worden onderhouden, zelfs voor cross-origin-aanvragen.
De standaardnaam van de affiniteitscookie is ApplicationGatewayAffinity en u kunt deze wijzigen. Als u in uw netwerktopologie meerdere toepassingsgateways in de regel implementeert, moet u voor elke resource unieke cookienamen instellen. Als u een aangepaste affiniteitscookienaam gebruikt, wordt er een extra cookie toegevoegd als CORS achtervoegsel. Bijvoorbeeld: CustomCookieNameCORS.
Notitie
Als het kenmerk SameSite=None is ingesteld, is het verplicht dat de cookie ook de secure-vlag bevat en moet worden verzonden via HTTPS. Als sessieaffiniteit is vereist via CORS, moet u uw workload migreren naar HTTPS. Raadpleeg hier de tls-offload- en end-to-end TLS-documentatie voor Application Gateway: overzicht, Een toepassingsgateway configureren met TLS-beëindiging met behulp van Azure Portal, end-to-end TLS configureren met behulp van Application Gateway met de portal.
Verwerkingsstop voor verbindingen
Het leegmaken van verbindingen helpt u bij het probleemloos verwijderen van leden van back-endpools tijdens geplande service-updates. Dit is van toepassing op back-endexemplaren die
- expliciet verwijderd uit de back-endpool of
- gerapporteerd als beschadigd door de statustests.
U kunt deze instelling toepassen op alle leden van de back-endpool door verbindingsafvoer in te schakelen in de back-endinstelling. Het zorgt ervoor dat alle registratie van exemplaren in een back-endpool geen nieuwe aanvragen/verbindingen ontvangt terwijl de bestaande verbindingen behouden blijven totdat de geconfigureerde time-outwaarde is geconfigureerd. Dit geldt ook voor WebSocket-verbindingen.
| Configuratietype | Weergegeven als |
|---|---|
| Standaardwaarde wanneer verbindingsafvoer niet is ingeschakeld in back-endinstelling | 30 seconden |
| Door de gebruiker gedefinieerde waarde wanneer verbindingsafvoer is ingeschakeld in back-endinstelling | 1 tot 3600 seconden |
De enige uitzondering hierop zijn aanvragen die zijn gebonden aan de registratie van exemplaren vanwege door gateway beheerde sessieaffiniteit. Deze aanvragen worden nog steeds doorgestuurd naar de registratie van instanties.
Protocol
Application Gateway ondersteunt zowel HTTP als HTTPS voor routeringsaanvragen naar de back-endservers. Als u HTTP kiest, wordt verkeer naar de back-endservers niet versleuteld. Als niet-versleutelde communicatie niet acceptabel is, kiest u HTTPS.
Deze instelling in combinatie met HTTPS in de listener ondersteunt end-to-end TLS. Hierdoor kunt u veilig gevoelige gegevens verzenden die zijn versleuteld naar de back-end. Elke back-endserver in de back-endpool waarvoor end-to-end TLS is ingeschakeld, moet worden geconfigureerd met een certificaat om beveiligde communicatie mogelijk te maken.
Poort
Met deze instelling geeft u de poort op waar de back-endservers naar verkeer van de toepassingsgateway luisteren. U kunt poorten tussen 1 en 65535 configureren.
Vertrouwd basiscertificaat
Als u HTTPS als back-endprotocol selecteert, vereist application gateway een vertrouwd basiscertificaat om de back-endpool te vertrouwen voor end-to-end SSL. Standaard is de optie Bekende CA-certificaat gebruiken ingesteld op Nee. Als u van plan bent een zelfondertekend certificaat of een certificaat te gebruiken dat is ondertekend door een interne certificeringsinstantie, moet u de Application Gateway het overeenkomende openbare certificaat opgeven dat wordt gebruikt door de back-endpool. Dit certificaat moet rechtstreeks worden geüpload naar de Application Gateway in. CER-indeling.
Als u van plan bent een certificaat te gebruiken in de back-endpool die is ondertekend door een vertrouwde openbare certificeringsinstantie, kunt u de optie Bekend CA-certificaat gebruiken instellen op Ja en het uploaden van een openbaar certificaat overslaan.
Time-out van aanvraag
Deze instelling is het aantal seconden dat de toepassingsgateway wacht om een antwoord van de back-endserver te ontvangen.
Back-endpad overschrijven
Met deze instelling kunt u een optioneel aangepast doorstuurpad configureren dat moet worden gebruikt wanneer de aanvraag wordt doorgestuurd naar de back-end. Een deel van het binnenkomende pad dat overeenkomt met het aangepaste pad in het veld back-endpad overschrijven, wordt gekopieerd naar het doorgestuurde pad. In de volgende tabel ziet u hoe deze functie werkt:
Wanneer de HTTP-instelling is gekoppeld aan een eenvoudige regel voor aanvraagroutering:
Oorspronkelijke aanvraag Back-endpad overschrijven Aanvraag doorgestuurd naar back-end /thuis/ /afjakkeren/ /override/home/ /home/secondhome/ /afjakkeren/ /override/home/secondhome/ Wanneer de HTTP-instelling is gekoppeld aan een padgebaseerde regel voor aanvraagroutering:
Oorspronkelijke aanvraag Padregel Back-endpad overschrijven Aanvraag doorgestuurd naar back-end /pathrule/home/ /pathrule* /afjakkeren/ /override/home/ /pathrule/home/secondhome/ /pathrule* /afjakkeren/ /override/home/secondhome/ /thuis/ /pathrule* /afjakkeren/ /override/home/ /home/secondhome/ /pathrule* /afjakkeren/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /afjakkeren/ /afjakkeren/ /pathrule/home/secondhome/ /pathrule/home* /afjakkeren/ /override/secondhome/ /pathrule/ /pathrule/ /afjakkeren/ /afjakkeren/
Aangepaste test gebruiken
Deze instelling koppelt een aangepaste test aan een HTTP-instelling. U kunt slechts één aangepaste test koppelen aan een HTTP-instelling. Als u geen aangepaste test expliciet koppelt, wordt de standaardtest gebruikt om de status van de back-end te controleren. U wordt aangeraden een aangepaste test te maken voor meer controle over de statuscontrole van uw back-ends.
Notitie
De aangepaste test bewaakt niet de status van de back-endpool, tenzij de bijbehorende HTTP-instelling expliciet is gekoppeld aan een listener.
De hostnaam configureren
Met Application Gateway kan de verbinding met de back-end een andere hostnaam gebruiken dan de naam die door de client wordt gebruikt om verbinding te maken met Application Gateway. Hoewel deze configuratie in sommige gevallen nuttig kan zijn, moet u voorzichtig zijn bij het overschrijven van de hostnaam, zodat deze verschilt tussen de toepassingsgateway en de client in vergelijking met het back-enddoel.
In productie is het raadzaam om de hostnaam die door de client wordt gebruikt, in de richting van de toepassingsgateway te houden als dezelfde hostnaam die door de toepassingsgateway wordt gebruikt voor het back-enddoel. Dit voorkomt mogelijke problemen met absolute URL's, omleidings-URL's en hostgebonden cookies.
Voordat u Application Gateway instelt die hiervan afwijkt, bekijkt u de gevolgen van een dergelijke configuratie, zoals nader besproken in Architecture Center: de oorspronkelijke HTTP-hostnaam behouden tussen een omgekeerde proxy en de back-endwebtoepassing
Er zijn twee aspecten van een HTTP-instelling die van invloed zijn op de Host HTTP-header die wordt gebruikt door Application Gateway om verbinding te maken met de back-end:
- "Hostnaam kiezen uit back-endadres"
- "Host name override"
Hostnaam kiezen uit back-endadres
Met deze mogelijkheid wordt de hostheader in de aanvraag dynamisch ingesteld op de hostnaam van de back-endpool. Er wordt een IP-adres of FQDN gebruikt.
Deze functie helpt wanneer de domeinnaam van de back-end verschilt van de DNS-naam van de toepassingsgateway en de back-end afhankelijk is van een specifieke hostheader die moet worden omgezet naar het juiste eindpunt.
Een voorbeeld hiervan is services met meerdere tenants als back-end. Een app-service is een service met meerdere tenants die gebruikmaakt van een gedeelde ruimte met één IP-adres. Een app-service kan dus alleen worden geopend via de hostnamen die zijn geconfigureerd in de aangepaste domeininstellingen.
De aangepaste domeinnaam is standaard example.azurewebsites.net. Als u toegang wilt krijgen tot uw app-service met behulp van een toepassingsgateway via een hostnaam die niet expliciet is geregistreerd in de app-service of via de FQDN van de toepassingsgateway, kunt u de hostnaam in de oorspronkelijke aanvraag overschrijven naar de hostnaam van de app-service. Hiervoor schakelt u de hostnaam kiezen uit de instelling van het back-endadres in.
Voor een aangepast domein waarvan de bestaande aangepaste DNS-naam is toegewezen aan de app-service, is de aanbevolen configuratie niet om de hostnaam kiezen uit het back-endadres in te schakelen.
Notitie
Deze instelling is niet vereist voor App Service Environment. Dit is een toegewezen implementatie.
Onderdrukking van hostnaam
Deze mogelijkheid vervangt de hostheader in de binnenkomende aanvraag op de toepassingsgateway door de hostnaam die u opgeeft.
Als bijvoorbeeld www.contoso.com is opgegeven in de hostnaaminstelling, wordt de oorspronkelijke aanvraag * gewijzigd in *https://appgw.eastus.cloudapp.azure.com/path1https://www.contoso.com/path1 wanneer de aanvraag wordt doorgestuurd naar de back-endserver.