Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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.
Affiniteit op basis van cookies
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-affiniteit cookie 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 met volledige TLS-validatie te gebruiken, moet u het bijbehorende basis-CA-certificaat (.cer) opgeven in de configuratie van de back-endinstellingen.
Instellingen voor HTTPS-validatie van back-end
Wanneer HTTPS is geselecteerd in de back-endinstellingen van Azure Application Gateway, voert de gateway volledige TLS-handshakevalidatie uit tijdens het tot stand brengen van een beveiligde verbinding met back-endservers. Deze validaties zijn onder andere:
- Controleer de certificaatketen om ervoor te zorgen dat het certificaat wordt vertrouwd.
- Controleer de onderwerpnaam van het certificaat op basis van de servernaamindicatie (SNI) die is verzonden door de Application Gateway.
- De vervaldatum van het certificaat controleren om te bevestigen dat het certificaat nog geldig is.
De standaardvalidatie-instellingen zorgen voor beveiligde TLS-communicatie tussen de gateway en back-endservices. In bepaalde scenario's kan het nodig zijn om een of meer van deze validatie-instellingen aan te passen. Application Gateway biedt de volgende configureerbare opties om aan diverse klantvereisten te voldoen. U kunt één of beide opties gebruiken als dat nodig is.
| Eigenschappen | Waarden |
|---|---|
| validateCertChainAndExpiration | Type: Booleaanse waarde (waar of onwaar). De standaardinstelling is waar. Hiermee worden zowel certificaatketen- als vervaldatumverificaties gecontroleerd of overgeslagen. |
| validerenSNI | Type: Booleaanse waarde (waar of onwaar). De standaardinstelling is waar. Er wordt gecontroleerd of de algemene naam van het certificaat van de back-endserver overeenkomt met de SNI-waarde (Server Name Indication) die is verzonden door de Application Gateway. |
| sniNaam | Type: Tekenreeks. Deze eigenschap is alleen vereist wanneer validateSNI is ingesteld als true. U kunt een SNI-waarde opgeven die overeenkomt met de algemene naam van het certificaat in de back-end. Standaard gebruikt de toepassingsgateway de hostheader van de binnenkomende aanvraag als SNI. |
Opmerking
- Het is raadzaam om alle validaties ingeschakeld te houden voor productieomgevingen. Het uitschakelen van sommige of alle validaties wordt alleen voorgesteld voor test- en ontwikkelingsdoeleinden, zoals wanneer zelfondertekende certificaten worden gebruikt.
- Deze instellingen zijn niet van toepassing op testtestfunctionaliteit bij het toevoegen van een aangepaste statustest. Als gevolg hiervan ziet u mogelijk verschillen in de resultaten bij vergelijking met periodieke gezondheidscontroles.
- Momenteel wordt deze niet ondersteund voor TLS-proxy.
- PowerShell en CLI worden binnenkort ondersteund.
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. Acceptabele waarden zijn van 1 seconde tot 86400 seconden (24 uur).
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 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.
Toegewezen backendverbinding
Azure Application Gateway hergebruikt standaard niet-actieve back-endverbindingen om het resourcegebruik van TCP-verbindingen voor zowel de Application Gateway als de back-endserver te optimaliseren. Azure Application Gateway V2 biedt speciale verbindingen met back-endservers om beveiligingsfuncties in klantgegevenspaden te ondersteunen die unieke back-endverbindingen per client vereisen.
Met deze functie wordt een directe een-op-een-toewijzing tussen front-end- en back-endverbindingen tot stand gebracht, waardoor continue connectiviteit voor elke individuele client wordt gegarandeerd.
Opmerking
Zorg ervoor dat de instelling voor de Specifieke Backend-verbinding is ingeschakeld om NTLM- of Kerberos-passthrough-verificatie mogelijk te maken. Deze configuratie onderhoudt een een-op-een-toewijzing tussen front-end- en back-endverbindingen. Dit is essentieel voor het behouden van sessie-integriteit die vereist is voor deze verificatieprotocollen.
Belangrijk
Toegewezen back-endverbindingen leiden tot een toename van het aantal verbindingen, waardoor mogelijk meer resources nodig zijn om de verhoogde gelijktijdige verbindingen op de Application Gateway en de back-endservers te ondersteunen. Bij Application Gateway moet u overwegen het aantal instanties te verhogen of automatische schaling in te schakelen.
Wanneer de back-end een externe server is, maken Application Gateway-exemplaren gebruik van SNAT-poorten voor elke verbinding. Naarmate elke clientverbinding een toegewezen back-endverbinding tot stand brengt, neemt het verbruik van de SNAT-poort dienovereenkomstig toe. Daarom is het belangrijk om rekening te houden met mogelijke SNAT-poortuitputting. Ga naar de aanbevolen procedures voor architectuur voor hulp.
Een toegewezen backendverbinding wordt niet ondersteund door HTTP/2.