Anmerkung
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Mit den Back-End-Einstellungen können Sie die Konfigurationen für Back-End-Verbindungen verwalten, die von einer Anwendungsgatewayressource zu einem Server im Back-End-Pool hergestellt wurden. Eine Back-End-Einstellungskonfiguration kann einer oder mehreren Routingregeln zugeordnet werden.
Typen von Back-End-Einstellungen im Anwendungsgateway
Während Portalbenutzer nur die Option "Back-End-Einstellungen" sehen, haben API-Benutzer Zugriff auf zwei Arten von Einstellungen. Sie müssen die richtige Konfiguration gemäß dem Protokoll verwenden.
- Back-End-HTTP-Einstellungen – Es gilt für Proxykonfigurationen der Ebene 7, die HTTP- und HTTPS-Protokolle unterstützen.
- Back-End-Einstellungen – Es gilt für Layer 4-Proxykonfigurationen (Vorschau), die TLS- und TCP-Protokolle unterstützen.
Cookiebasierte Affinität
Azure Application Gateway verwendet vom Gateway verwaltete Cookies zum Beibehalten von Benutzersitzungen. Wenn ein Benutzer die erste Anforderung an das Anwendungsgateway sendet, legt er ein Affinitätscookie in der Antwort mit einem Hashwert fest, der die Sitzungsdetails enthält. Der Prozess ermöglicht es, dass nachfolgende Anfragen mit dem Affinitätscookie zum selben Backend-Server geleitet werden, um die Sessionbindung zu gewährleisten.
Diese Funktion ist hilfreich, wenn eine Benutzersitzung auf demselben Server bleiben soll und der Sitzungszustand lokal auf dem Server für eine Benutzersitzung gespeichert wird. Wenn die Anwendung cookiebasierte Affinität nicht verarbeiten kann, können Sie diese Funktion nicht verwenden. Um sie zu verwenden, stellen Sie sicher, dass die Clients Cookies unterstützen.
Hinweis
Einige Schwachstellen-Scans kennzeichnen möglicherweise das Anwendungsgateway-Affinitäts-Cookie, da die Flags "Secure" oder "HttpOnly" nicht gesetzt sind. Diese Scans berücksichtigen nicht, dass die Daten im Cookie mit einem unidirektionalem Hash generiert werden. Das Cookie enthält keine Benutzerinformationen und wird ausschließlich für das Routing verwendet.
Das Chromiumv80-Browserupdate führte eine Vorschrift ein, bei der HTTP-Cookies ohne SameSite-Attribut als SameSite=Lax behandelt werden müssen. Im Fall von CORS-Anforderungen (Cross-Origin Resource Sharing, Ressourcenfreigabe zwischen verschiedenen Ursprüngen), wenn das Cookie in einem Drittanbieterkontext gesendet werden soll, muss es das Attribut SameSite=None; Secure verwenden und sollte nur über HTTPS gesendet werden. Anderenfalls sendet der Browser in einem reinen HTTP-Szenario die Cookies nicht im Drittanbieterkontext. Das Ziel dieses Updates von Chrome besteht darin, die Sicherheit zu erhöhen und CSRF-Angriffe (Cross-Site Request Forgery, siteübergreifende Anforderungsfälschung) zu vermeiden.
Zur Unterstützung dieser Änderung fügt Application Gateway (alle SKU-Typen) ab dem 17. Februar 2020 ein weiteres Cookie namens ApplicationGatewayAffinityCORS zusätzlich zum vorhandenen Cookie ApplicationGatewayAffinity hinzu. Dem ApplicationGatewayAffinityCORS-Cookie wurden zwei weitere Attribute hinzugefügt („SameSite=None; Secure“), damit persistente Sitzungen selbst für ursprungsübergreifende Anforderungen erhalten bleiben.
Der Standardmäßige Affinitätscookiename ist ApplicationGatewayAffinity , und Sie können ihn ändern. Wenn Sie in Ihrer Netzwerktopologie mehrere Anwendungsgatewayinstanzen in Reihe bereitstellen, müssen Sie für jede Instanz eindeutige Cookienamen festlegen. Falls Sie einen benutzerdefinierten Affinitätscookienamen verwenden, wird ein zusätzliches Cookie mit CORS als Suffix hinzugefügt. Beispielsweise CustomCookieNameCORS.
Hinweis
Wenn das Attribut SameSite=None festgelegt ist, ist es obligatorisch, dass das Cookie auch das Secure-Flag enthält und über HTTPS gesendet werden muss. Wenn Sitzungsaffinität über CORS erforderlich ist, müssen Sie Ihren Workload zu HTTPS migrieren. Weitere Informationen finden Sie in der TLS-Offload- und End-to-End-TLS-Dokumentation für Application Gateway. Weitere Informationen finden Sie in der SSL-Übersicht, Konfigurieren eines Anwendungsgateways mit TLS-Beendigung und Konfigurieren von End-to-End-TLS.
Verbindungsausgleich
Mit dem Verbindungsausgleich können Sie Elemente des Back-End-Pools bei geplanten Dienstupdates korrekt entfernen. Sie gilt für Back-End-Instanzen, die explizit aus dem Back-End-Pool entfernt werden.
Sie können diese Einstellung auf alle Elemente eines Back-End-Pools anwenden, indem Sie Einstellung für Verbindungsausgleich im Back-End aktivieren. Dadurch wird sichergestellt, dass Instanzen, deren Registrierung in einem Back-End-Pool aufgehoben wird, keine neuen Anforderungen/Verbindungen erhalten und gleichzeitig die vorhandenen Verbindungen bis zum konfigurierten Timeoutwert beibehalten werden. Dieser Vorgang gilt auch für WebSocket-Verbindungen.
| Konfigurationstyp | Wert |
|---|---|
| Standardwert, wenn die Verbindungsabwässerung in der Back-End-Einstellung nicht aktiviert ist | 30 Sekunden |
| Benutzerdefinierter Wert, wenn der Verbindungsausgleich in der Back-End-Einstellung aktiviert ist. | 1 bis 3600 Sekunden |
Die einzige Ausnahme für diesen Prozess sind Anforderungen zur Aufhebung der Registrierung von Instanzen aufgrund der durch das Gateway verwalteten Sitzungsaffinität. Diese Anforderungen werden weiterhin an die Instanzen weitergeleitet, deren Registrierung aufgehoben wird.
Hinweis
Es gibt eine Einschränkung, bei der ein Konfigurationsupdate laufende Verbindungen nach der Zeitüberschreitung des Verbindungsausgleichs beendet. Um diese Einschränkung zu beheben, müssen Sie das Verbindungsentleerungs-Timeout in den Backend-Einstellungen auf einen Wert erhöhen, der höher ist als die erwartete maximale Client-Downloadzeit.
Protocol
Application Gateway unterstützt sowohl HTTP als auch HTTPS für das Routing von Anforderungen an die Back-End-Server. Bei Auswahl von HTTP ist Datenverkehr an die Back-End-Server unverschlüsselt. Wenn unverschlüsselte Kommunikation nicht akzeptabel ist, wählen Sie HTTPS.
Diese Einstellung unterstützt zusammen mit HTTPS im Listener End-to-End-TLS. Damit können Sie vertrauliche Daten sicher verschlüsselt an das Back-End übertragen. Jeder Back-End-Server im Back-End-Pool mit aktiviertem End-to-End-TLS muss mit einem Zertifikat konfiguriert sein, um die sichere Kommunikation zuzulassen.
Hafen
Diese Einstellung gibt den Port an, an dem die Back-End-Server auf Datenverkehr vom Anwendungsgateway lauschen. Sie können Ports im Bereich von 1 bis 65535 konfigurieren.
Vertrauenswürdiges Stammzertifikat
Wenn Sie das HTTPS-Protokoll in den Back-End-Einstellungen auswählen, verwendet die Anwendungsgatewayressource den standardmäßigen Zertifikatspeicher für vertrauenswürdige Stammzertifizierungsstellen, um die Kette und Authentizität des vom Back-End-Server bereitgestellten Zertifikats zu überprüfen.
Standardmäßig enthält die Application Gateway-Ressource beliebte Zertifizierungsstellenzertifikate, sodass nahtlose TLS-Verbindungen möglich sind, wenn das Back-End-Serverzertifikat von einer öffentlichen Zertifizierungsstelle ausgestellt wird. Wenn Sie jedoch eine private Zertifizierungsstelle oder ein selbst generiertes Zertifikat mit vollständiger TLS-Überprüfung verwenden möchten, müssen Sie das entsprechende Stammzertifizierungsstellenzertifikat (.cer) in der Back-End-Einstellungskonfiguration bereitstellen.
Back-End HTTPS-Überprüfungseinstellungen
Wenn HTTPS in den Back-End-Einstellungen des Azure-Anwendungsgateways ausgewählt ist, führt das Gateway eine vollständige TLS-Handshake-Überprüfung durch, während eine sichere Verbindung mit Back-End-Servern hergestellt wird. Diese Validierungen umfassen:
- Überprüfen der Zertifikatkette, um sicherzustellen, dass das Zertifikat vertrauenswürdig ist.
- Überprüfen des Subjektnamens des Zertifikats anhand der SNI (Server Name Indication), die vom Anwendungsgateway gesendet wurde.
- Überprüfen des Ablaufs des Zertifikats, um zu bestätigen, ob das Zertifikat noch gültig ist.
Die Standardüberprüfungseinstellungen stellen eine sichere TLS-Kommunikation zwischen Gateway- und Back-End-Diensten sicher. In bestimmten Szenarien kann es erforderlich sein, eine oder mehrere dieser Überprüfungseinstellungen anzupassen. Um unterschiedliche Kundenanforderungen zu erfüllen, bietet Application Gateway die folgenden konfigurierbaren Optionen. Sie können bei Bedarf entweder oder beide Optionen verwenden.
| Eigenschaften | Werte |
|---|---|
| validateCertChainAndExpiry | Typ: Boolean (true oder false). Die Standardeinstellung ist true. Sowohl die Überprüfung der Zertifikatkette als auch die Überprüfung des Verfallsdatums werden entweder durchgeführt oder übersprungen. |
| validateSNI | Typ: Boolean (true oder false). Die Standardeinstellung ist true. Es wird überprüft, ob der allgemeine Name des vom Back-End-Server bereitgestellten Zertifikats mit dem Server Name Indication (SNI)-Wert übereinstimmt, der vom Anwendungsgateway gesendet wurde. |
| sniName | Typ: Zeichenfolge. Diese Eigenschaft ist nur erforderlich, wenn validateSNI als true festgelegt ist. Sie können einen SNI-Wert angeben, der dem gemeinsamen Namen des Zertifikats im Back-End entspricht. Standardmäßig verwendet das Anwendungsgateway den Hostheader der eingehenden Anforderung als SNI. |
Hinweis
- Es wird empfohlen, alle Überprüfungen für Produktionsumgebungen aktiviert zu halten. Das Deaktivieren einiger oder aller Überprüfungen wird nur zu Test- und Entwicklungszwecken vorgeschlagen, z. B. wenn selbstsignierte Zertifikate verwendet werden.
- Diese Einstellungen gelten nicht für die Funktionalität von Tests beim Hinzufügen eines benutzerdefinierten Überwachungstests. Daher werden möglicherweise Unterschiede in den Ergebnissen beim Vergleich mit regelmäßigen Gesundheitschecks angezeigt.
- Derzeit nicht unterstützt für TLS-Proxy.
- PowerShell und CLI werden in Kürze unterstützt.
Anforderungszeitlimit
Diese Einstellung ist die Anzahl der Sekunden, die das Anwendungsgateway auf eine Antwort vom Back-End-Server wartet. Der Standardwert beträgt 20 Sekunden. Sie können diese Einstellung jedoch an die Anforderungen Ihrer Anwendung anpassen. Zulässige Werte liegen zwischen 1 Sekunde und 86400 Sekunden (24 Stunden).
Back-End-Pfad außer Kraft setzen
Mit dieser Einstellung können Sie einen optionalen benutzerdefinierten Weiterleitungspfad konfigurieren, der für die Weiterleitung der Anforderung an das Back-End verwendet werden soll. Ein beliebiger Teil des Eingangspfads, der mit dem benutzerdefinierten Pfad im Feld Back-End-Pfad außer Kraft setzen übereinstimmt, wird in den weitergeleiteten Pfad kopiert. Die folgende Tabelle zeigt die Funktionsweise dieses Features:
Wenn die HTTP-Einstellung einer einfachen Routingregel für Anforderungen zugeordnet ist:
Ursprüngliche Anforderung Back-End-Pfad außer Kraft setzen An das Back-End weitergeleitete Anforderung /Heim/ /override/ /override/home/ /home/secondhome/ /override/ /override/home/secondhome/ Wenn die HTTP-Einstellung einer pfadbasierten Routingregel für Anforderungen zugeordnet ist:
Ursprüngliche Anforderung Pfadregel Back-End-Pfad außer Kraft setzen An das Back-End weitergeleitete Anforderung /pathrule/home/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /Heim/ /pathrule* /override/ /override/home/ /home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /override/ /override/ /pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/ /pathrule/ /pathrule/ /override/ /override/
Benutzerdefinierten Test verwenden
Diese Einstellung ordnet einen benutzerdefinierten Test einer HTTP-Einstellung zu. Einer HTTP-Einstellung kann nur ein benutzerdefinierter Test zugeordnet werden. Wenn Sie nicht explizit einen benutzerdefinierten Test zuordnen, wird der Standardtest zur Überwachung der Integrität des Back-Ends verwendet. Sie sollten einen benutzerdefinierten Test erstellen, um größere Kontrolle über die Integritätsüberwachung Ihrer Back-Ends zu haben.
Hinweis
Der benutzerdefinierte Test überwacht die Integrität des Back-End-Pools nur dann, wenn die entsprechende HTTP-Einstellung explizit einem Listener zugeordnet ist.
Konfigurieren des Hostnamens
Application Gateway ermöglicht es, dass bei der Verbindung mit dem Back-End ein anderer Hostname als der Hostname verwendet werden kann, der vom Client zum Herstellen einer Verbindung mit Application Gateway verwendet wird. Während diese Konfiguration in einigen Fällen nützlich sein kann, achten Sie beim Überschreiben des Hostnamens darauf, dass sie sich zwischen dem Anwendungsgateway und dem Client im Vergleich zum Back-End-Ziel unterscheidet.
In Produktionsumgebungen empfiehlt es sich, denselben Hostnamen für die Verbindung vom Client zum Anwendungsgateway und vom Anwendungsgateway zur Backend-Verbindung zu verwenden. In dieser Praxis werden potenzielle Probleme mit absoluten URLs, Umleitungs-URLs und hostgebundenen Cookies vermieden.
Bevor Sie das Anwendungsgateway einrichten, das von diesem abweicht, überprüfen Sie die Auswirkungen einer solchen Konfiguration, wie im Architecture Center ausführlicher erläutert: Beibehalten des ursprünglichen HTTP-Hostnamens zwischen einem Reverseproxy und seiner Back-End-Webanwendung
Es gibt zwei Aspekte bei einer HTTP-Einstellung, die den HTTP-Header Host beeinflussen, der von Application Gateway zum Herstellen einer Verbindung mit dem Back-End verwendet wird:
- „Hostnamen aus Back-End-Adresse auswählen“
- „Hostnamen überschreiben“
Hostnamen aus Back-End-Adresse auswählen
Diese Funktion legt den Hostheader in der Anforderung dynamisch auf den Hostnamen des Back-End-Pools fest. Sie verwendet dazu eine IP-Adresse oder einen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN ).
Dieses Feature ist nützlich, wenn der Domänenname des Back-Ends vom DNS-Namen des Application Gateways abweicht und sich das Back-End für die Auflösung zum richtigen Endpunkt auf einen bestimmten Hostheader stützt.
Ein Beispielfall sind Multitenant-Dienste als das Back-End. Ein App-Dienst ist ein mehrinstanzenfähiger Dienst, der einen freigegebenen Speicherplatz mit einer einzelnen IP-Adresse verwendet. Daher kann der Zugriff auf einen App Service nur über die Hostnamen erfolgen, die in den Einstellungen der benutzerdefinierten Domäne konfiguriert werden.
Standardmäßig ist der benutzerdefinierte Domänenname example.azurewebsites.net. Sie können den Hostnamen in der ursprünglichen Anforderung an den Hostnamen des App-Diensts überschreiben, um mithilfe eines Anwendungsgateways über einen Hostnamen, der nicht explizit im App-Dienst registriert ist, oder über den FQDN des Anwendungsgateways auf Ihren App-Dienst zuzugreifen. Aktivieren Sie zu diesem Zweck die Einstellung Hostnamen aus Back-End-Adresse auswählen.
Bei einer benutzerdefinierten Domäne, deren vorhandener benutzerdefinierter DNS-Name dem App-Dienst zugeordnet ist, empfiehlt es sich nicht, den Auswahlhostnamen aus der Back-End-Adresse zu aktivieren.
Hinweis
Diese Einstellung ist für die App-Dienstumgebung, bei der es sich um eine dedizierte Bereitstellung handelt, nicht erforderlich.
Hostnamen außer Kraft setzen
Diese Funktion ersetzt den Host-Header in der beim Application Gateway eingehenden Anforderung durch den Hostnamen, den Sie angeben.
Wenn beispielsweise www.contoso.com in der Einstellung " Hostname " angegeben ist, wird die ursprüngliche Anforderung *https://appgw.eastus.cloudapp.azure.com/path1 in *https://www.contoso.com/path1 geändert, wenn die Anforderung an den Back-End-Server weitergeleitet wird.
Dedizierte Back-End-Verbindung
Das Azure-Anwendungsgateway verwendet standardmäßig Leerlauf-Back-End-Verbindungen, um die Ressourcennutzung von TCP-Verbindungen sowohl für das Anwendungsgateway als auch für den Back-End-Server zu optimieren. Um Sicherheitsfunktionen in Kundendatenpfaden zu unterstützen, die eindeutige Back-End-Verbindungen pro Client erfordern, stellt Azure Application Gateway V2 dedizierte Verbindungen zu Back-End-Servern bereit.
Diese Funktion stellt eine direkte 1:1-Zuordnung zwischen Frontend- und Back-End-Verbindungen her und stellt eine dauerhafte Konnektivität für jeden einzelnen Client sicher.
Hinweis
Um die NTLM- oder Kerberos-Passthrough-Authentifizierung zu aktivieren, stellen Sie sicher, dass die Einstellung "Dedizierte Back-End-Verbindung" aktiviert ist. Diese Konfiguration verwaltet eine 1:1-Zuordnung zwischen Frontend- und Back-End-Verbindungen, die für die Beibehaltung der Sitzungsintegrität, die von diesen Authentifizierungsprotokollen erforderlich ist.
Von Bedeutung
Dedizierte Back-End-Verbindung führt zu einer Erhöhung der Anzahl der Back-End-Verbindungen und kann daher mehr Ressourcen erfordern, um die erhöhten gleichzeitigen Verbindungen auf Application Gateway und den Back-End-Servern zu unterstützen. Im Anwendungsgateway müssen Sie erwägen, die Anzahl der Instanzen zu erhöhen oder die automatische Skalierung zu aktivieren.
Wenn das Back-End ein Remoteserver ist, verwenden Anwendungsgatewayinstanzen SNAT-Ports für jede Verbindung. Da jede Clientverbindung eine dedizierte Back-End-Verbindung herstellt, erhöht sich der SNAT-Portverbrauch entsprechend. Daher ist es wichtig, die potenzielle SNAT-Portausschöpfung zu berücksichtigen. Besuchen Sie die bewährten Methoden der Architektur , um Anleitungen zu erhalten.
Dedizierte Back-End-Verbindung wird mit HTTP/2 nicht unterstützt.