Freigeben über

Konfiguration der Anwendungsgateway-Back-End-Einstellungen

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.

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

Bei einigen Überprüfungen auf Sicherheitsrisiken wird möglicherweise das Application Gateway-Affinitätscookie gekennzeichnet, weil die Flags „Secure“ oder „HttpOnly“ nicht festgelegt 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 v80-Update des Chromium-Browsers enthielt ein Mandat, bei dem 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.

Protokoll

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 verwenden möchten, müssen Sie das entsprechende Stammzertifizierungsstellenzertifikat (.cer) in dieser Back-End-Einstellungskonfiguration angeben.

Anforderungstimeout

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.

Back-End-Pfad überschreiben

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 überschreiben An das Back-End weitergeleitete Anforderung
    /Heim/ /überschreiben/ /override/home/
    /home/secondhome/ /überschreiben/ /override/home/secondhome/

  • Wenn die HTTP-Einstellung einer pfadbasierten Routingregel für Anforderungen zugeordnet ist:

    Ursprüngliche Anforderung Pfadregel Back-End-Pfad überschreiben An das Back-End weitergeleitete Anforderung
    /pathrule/home/ /pathrule* /überschreiben/ /override/home/
    /pathrule/home/secondhome/ /pathrule* /überschreiben/ /override/home/secondhome/
    /Heim/ /pathrule* /überschreiben/ /override/home/
    /home/secondhome/ /pathrule* /überschreiben/ /override/home/secondhome/
    /pathrule/home/ /pathrule/home* /überschreiben/ /überschreiben/
    /pathrule/home/secondhome/ /pathrule/home* /überschreiben/ /override/secondhome/
    /pathrule/ /pathrule/ /überschreiben/ /überschreiben/

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.

Nächste Schritte