configuratie van HTTP-instellingen Application Gateway

De toepassingsgateway routeert 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.

Azure Application 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 sessiedetails bevat, zodat de volgende aanvragen met de affiniteitscookie naar dezelfde back-endserver worden gerouteerd om de stickiness te behouden.

Deze functie is handig als u een gebruikerssessie op dezelfde server wilt houden 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 clients cookies ondersteunen.

Notitie

Sommige scans van beveiligingsproblemen kunnen de Application Gateway affiniteitscookie markeren omdat de markeringen Beveiligd of HttpOnly 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 Chromiumbrowserv80-update heeft een mandaat opgeleverd waarbij HTTP-cookies zonder het kenmerk SameSite moeten worden behandeld als SameSite=Lax. In het geval van 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 het verbeteren van de beveiliging en het voorkomen van CSRF-aanvallen (Cross-Site Request Forgery).

Om deze wijziging te ondersteunen, zal Application Gateway (alle SKU-typen) vanaf 17 februari 2020 een ander 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 een aangepaste affiniteitscookienaam gebruikt, wordt er een extra cookie toegevoegd met CORS als 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 documentatie voor TLS-offload en end-to-end TLS voor Application Gateway: overzicht, een toepassingsgateway configureren met TLS-beëindiging met behulp van de Azure Portal, end-to-end TLS configureren met behulp van Application Gateway met de portal.

Verwerkingsstop voor verbindingen

Door de verbinding te verwijderen, kunt u leden van back-endpools probleemloos verwijderen tijdens geplande service-updates. U kunt deze instelling toepassen op alle leden van een back-endpool door verbindingsafvoer in te schakelen op de HTTP-instelling. Het zorgt ervoor dat alle registratie-instanties van een back-endpool bestaande verbindingen blijven onderhouden en on-going aanvragen verwerken voor een configureerbare time-out en geen nieuwe aanvragen of verbindingen ontvangen. De enige uitzondering hierop zijn aanvragen die zijn gebonden aan het deregistereren van exemplaren vanwege door de gateway beheerde sessieaffiniteit en blijven worden doorgestuurd naar de registratie-exemplaren. Verbindingsafvoer is van toepassing op back-endexemplaren die expliciet uit de back-endpool worden verwijderd.

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 luisteren naar verkeer van de toepassingsgateway. U kunt poorten van 1 tot 65535 configureren.

Time-out van aanvraag

Deze instelling is het aantal seconden dat de toepassingsgateway wacht op het ontvangen van een antwoord van de back-endserver.

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 basisregel voor aanvraagroutering:

    Oorspronkelijke aanvraag Back-endpad overschrijven Aanvraag doorgestuurd naar back-end
    /home/ /overschrijven/ /onderdrukking/home/
    /home/secondhome/ /overschrijven/ /override/home/secondhome/
  • Wanneer de HTTP-instelling is gekoppeld aan een aanvraagrouteringsregel op basis van een pad:

    Oorspronkelijke aanvraag Padregel Back-endpad overschrijven Aanvraag doorgestuurd naar back-end
    /pathrule/home/ /pathrule* /overschrijven/ /onderdrukking/home/
    /pathrule/home/secondhome/ /pathrule* /overschrijven/ /override/home/secondhome/
    /home/ /pathrule* /overschrijven/ /onderdrukking/home/
    /home/secondhome/ /pathrule* /overschrijven/ /override/home/secondhome/
    /pathrule/home/ /pathrule/home* /overschrijven/ /overschrijven/
    /pathrule/home/secondhome/ /pathrule/home* /overschrijven/ /override/secondhome/
    /pathrule/ /pathrule/ /overschrijven/ /overschrijven/

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

Met de aangepaste test wordt de status van de back-endpool niet bewaakt, tenzij de bijbehorende HTTP-instelling expliciet is gekoppeld aan een listener.

De hostnaam configureren

Application Gateway maakt het mogelijk dat de verbinding met de back-end een andere hostnaam gebruikt dan de hostnaam die door de client wordt gebruikt om verbinding te maken met Application Gateway. Hoewel deze configuratie in sommige gevallen nuttig kan zijn, moet het overschrijven van de hostnaam anders zijn tussen de client en de toepassingsgateway en de toepassingsgateway naar het back-enddoel.

In productie is het raadzaam om de hostnaam die door de client wordt gebruikt, naar 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, raadpleegt u de gevolgen van een dergelijke configuratie, zoals nader besproken in Architecture Center: de oorspronkelijke HTTP-hostnaam behouden tussen een omgekeerde proxy en de bijbehorende back-endwebtoepassing

Er zijn twee aspecten van een HTTP-instelling die van invloed zijn op de Host HTTP-header die door Application Gateway wordt gebruikt om verbinding te maken met de back-end:

  • "Hostnaam kiezen uit back-endadres"
  • "Hostnaam overschrijven"

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. U doet dit door de hostnaam kiezen in te schakelen vanuit de instelling van het back-endadres .

Voor een aangepast domein waarvan de bestaande aangepaste DNS-naam is toegewezen aan de app-service, is de aanbevolen configuratie het niet inschakelen van de hostnaam van het back-endadres.

Notitie

Deze instelling is niet vereist voor App Service Environment, een toegewezen implementatie.

Hostnaam overschrijven

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 *https://appgw.eastus.cloudapp.azure.com/path1 gewijzigd in *https://www.contoso.com/path1 wanneer de aanvraag wordt doorgestuurd naar de back-endserver.

Volgende stappen