Delen via

Configuratie van back-endinstellingen voor Application Gateway

Met de back-endinstellingen kunt u de configuraties beheren voor back-endverbindingen die zijn gemaakt vanuit een toepassingsgatewayresource naar een server in de back-endpool. Een configuratie van back-endinstellingen kan worden gekoppeld aan een of meer routeringsregels.

Typen back-endinstellingen in Application Gateway

Hoewel portalgebruikers alleen de optie Back-endinstellingen zien, hebben API-gebruikers toegang tot twee typen instellingen. U moet de juiste configuratie gebruiken volgens het protocol.

  • HTTP-instellingen voor back-end: dit is bedoeld voor proxyconfiguraties van Laag 7 die HTTP- en HTTPS-protocollen ondersteunen.
  • Back-endinstellingen: dit geldt voor Layer 4-proxyconfiguraties (voorbeeld) die ondersteuning bieden voor TLS- en TCP-protocollen.

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 hash-waarde die de sessiegegevens bevat. Met dit proces kunnen volgende aanvragen die de affiniteitscookie bevatten, worden doorgestuurd naar dezelfde back-endserver, waardoor de stickiteit behouden blijft.

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.

Opmerking

Sommige scans van beveiligingsproblemen kunnen de Application Gateway-affiniteitcookie 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-browserv80-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-only 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.

Opmerking

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 de documentatie voor TLS-offload en end-to-end TLS voor Application Gateway. Zie het SSL-overzicht, Een toepassingsgateway configureren met TLS-beëindiging en end-to-end TLS configureren.

Leegmaken van verbindingen

Het leegmaken van verbindingen helpt u bij het probleemloos verwijderen van leden van back-endpools tijdens geplande service-updates. Dit geldt voor back-endinstanties die expliciet uit de back-endpool worden verwijderd.

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 afmeldende exemplaren in een back-endpool geen nieuwe verzoeken/verbindingen ontvangen, terwijl de bestaande verbindingen behouden blijven tot de geconfigureerde time-outwaarde. Dit proces geldt ook voor WebSocket-verbindingen.

Configuratietype Waarde
Standaardwaarde wanneer verbindingsafvoer niet is ingeschakeld in de back-endinstelling 30 seconden
Door de gebruiker gedefinieerde waarde wanneer connection draining is ingeschakeld in de achtergrondinstelling. 1 tot 3600 seconden

De enige uitzondering op dit proces zijn aanvragen die bedoeld zijn voor het uitschrijven van exemplaren vanwege sessieaffiniteit beheerd door de gateway. Deze aanvragen worden nog steeds doorgestuurd naar de deregistrerende instanties.

Opmerking

Er is een beperking waarbij een configuratie-update lopende verbindingen beëindigt na de time-out voor het leegmaken van de verbinding. Als u deze beperking wilt verhelpen, moet u de time-out voor het leegmaken van verbindingen in de back-endinstellingen verhogen tot een waarde die hoger is dan de maximale verwachte downloadtijd van de client.

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.

Porto

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

Wanneer u het HTTPS-protocol selecteert in de back-endinstellingen, maakt de application gateway-resource gebruik van het standaardcertificaatarchief van de vertrouwde basis-CA om de keten en echtheid van het certificaat dat is geleverd door de back-endserver te controleren.

De Application Gateway-resource bevat standaard populaire CA-certificaten, waardoor naadloze TLS-back-endverbindingen worden toegestaan wanneer het back-endservercertificaat wordt uitgegeven door een openbare CERTIFICERINGsinstantie. Als u echter van plan bent een privé-CA of een zelf gegenereerd certificaat te gebruiken, moet u het bijbehorende basis-CA-certificaat (.cer) opgeven in deze configuratie van de back-endinstellingen.

Time-out van aanvraag

Deze instelling is het aantal seconden dat de toepassingsgateway wacht om een antwoord van de back-endserver te ontvangen. De standaardwaarde is 20 seconden. U kunt deze instelling echter aanpassen aan de behoeften van uw toepassing.

Achtergrondpad overschrijven

Met deze instelling kunt u een optioneel aangepast doorstuurpad configureren dat moet worden gebruikt wanneer de aanvraag wordt doorgestuurd naar de back-end. Elk deel van het binnenkomende pad dat overeenkomt met het aangepaste pad in het veld overschrijven van het back-end pad, 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 Achtergrondpad overschrijven Aanvraag doorgestuurd naar back-end
    /thuis/ /overschrijven/ /override/home/
    /home/secondhome/ /overschrijven/ /override/home/secondhome/

  • Wanneer de HTTP-instelling is gekoppeld aan een padgebaseerde regel voor aanvraagroutering:

    Oorspronkelijke aanvraag Padregel Achtergrondpad overschrijven Aanvraag doorgestuurd naar back-end
    /pathrule/home/ /pathrule* /overschrijven/ /override/home/
    /padregel/home/tweedehuis/ /pathrule* /overschrijven/ /override/home/secondhome/
    /thuis/ /pathrule* /overschrijven/ /override/home/
    /home/secondhome/ /pathrule* /overschrijven/ /override/home/secondhome/
    /pathrule/home/ /pathrule/home* /overschrijven/ /overschrijven/
    /padregel/home/tweedehuis/ /pathrule/home* /overschrijven/ /override/tweedehuis/
    /pathrule/ /pathrule/ /overschrijven/ /overschrijven/

Gebruik aangepaste sonde

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 sonde te maken voor meer controle over de gezondheidsmonitoring van uw back-ends.

Opmerking

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 productieomgevingen is het een best practice om voor zowel de verbinding van de client naar de toepassingsgateway als de verbinding van de toepassingsgateway naar de back-enddoellocatie dezelfde hostnaam te gebruiken. Deze praktijk 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: behoud de oorspronkelijke HTTP-hostnaam 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 wordt gebruikt door Application Gateway om verbinding te maken met de back-end:

  • Hostnaam ophalen uit back-end adres
  • Hostname-overschrijving

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 applicatiegateway en de back-end afhankelijk is van een specifieke hostheader om naar het juiste eindpunt om te schakelen.

Een voorbeeld is multitenant-services als back-end. Een App Service is een multitenant-service 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 instelling hostnaam kiezen van backend-adres in.

Voor een aangepast domein waarvan de bestaande aangepaste DNS-naam is toegewezen aan de app-service, wordt de aanbevolen configuratie niet gebruikt om de hostnaam kiezen uit het back-endadres in te schakelen.

Opmerking

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

Hostnaam overschrijven

Deze mogelijkheid vervangt de hostheader in de binnenkomende aanvraag op de toepassingsgateway door de hostnaam die u opgeeft.

Als bijvoorbeeldwww.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.

Volgende stappen