Application Gateway: Konfiguration der HTTP-Einstellungen
Das Anwendungsgateway leitet Datenverkehr mithilfe der Konfiguration, die Sie hier festlegen, an die Back-End-Server weiter. Nachdem Sie eine HTTP-Einstellung erstellt haben, müssen Sie sie einer oder mehreren Regeln für das Routing von Anforderungen zuordnen.
Cookiebasierte Affinität
Azure Application Gateway verwendet vom Gateway verwaltete Cookies zum Beibehalten von Benutzersitzungen. Wenn ein Benutzer die erste Anforderung an Application Gateway sendet, setzt dieses in der Antwort ein Affinitätscookie mit einem Hashwert, der die Sitzungsdetails enthält, sodass die nachfolgenden Anfragen, die das Affinitätscookie enthalten, zum selben Back-End-Server geleitet werden, um die Bindung aufrechtzuerhalten.
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. Bei diesen Überprüfungen wird nicht berücksichtigt, dass die Daten im Cookie mit einem unidirektionalen 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.
Beachten Sie, dass der Standardname des Affinitätscookies ApplicationGatewayAffinity lautet, was Sie aber ändern können. Für den Fall, dass 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 Flag Secure 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 zur TLS-Abladung und End-to-End-TLS-Dokumentation für Application Gateway finden Sie unter: Übersicht, Konfigurieren einer Application Gateway-Instanz mit TLS-Beendigung mithilfe des Azure-Portals und Konfigurieren der End-to-End-TLS-Verschlüsselung mithilfe von Application Gateway und dem Portal.
Verbindungsausgleich
Mit dem Verbindungsausgleich können Sie Elemente des Back-End-Pools bei geplanten Dienstupdates korrekt entfernen. Dies gilt für Back-End-Instanzen, die
- explizit aus dem Back-End-Pool entfernt,
- bei Skalierungsvorgängen entfernt oder
- von den Integritätstests als fehlerhaft gemeldet 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. Dies gilt auch für WebSocket-Verbindungen.
| Konfigurationstyp | Wert |
|---|---|
| Standardwert, wenn der Verbindungsausgleich 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 hierbei 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.
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.
Port
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 HTTPS als Back-End-Protokoll auswählen, erfordert das Anwendungsgateway ein vertrauenswürdiges Stammzertifikat, um dem Back-End-Pool für End-to-End-SSL zu vertrauen. Standardmäßig ist die Option Bekanntes CA-Zertifikat verwenden auf Nein festgelegt. Wenn Sie ein selbst signiertes Zertifikat oder ein von einer internen Zertifizierungsstelle signiertes Zertifikat verwenden möchten, müssen Sie für das Anwendungsgateway dasselbe öffentliche Zertifikat angeben, das der Back-End-Pool verwendet. Dieses Zertifikat muss im .CER-Format direkt zu Application Gateway hochgeladen werden.
Wenn Sie ein Zertifikat im Back-End-Pool verwenden möchten, das von einer vertrauenswürdigen öffentlichen Zertifizierungsstelle signiert ist, können Sie die Option Bekanntes CA-Zertifikat verwenden auf Ja festlegen und das Hochladen eines öffentlichen Zertifikats überspringen.
Anforderungstimeout
Diese Einstellung ist die Anzahl der Sekunden, die das Anwendungsgateway auf eine Antwort vom Back-End-Server wartet.
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 /home/ /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 überschreiben An das Back-End weitergeleitete Anforderung /pathrule/home/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /home/ /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. Obwohl diese Konfiguration in einigen Fällen nützlich sein kann, sollte das Überschreiben des Hostnamens, der sich zwischen Client und Anwendungsgateway und Anwendungsgateway und Back-End-Ziel unterscheidet, mit Vorsicht erfolgen.
In der Produktion empfiehlt es sich, für den Hostnamen, der vom Client für das Anwendungsgateway verwendet wird, denselben Hostnamen zu verwenden, der vom Anwendungsgateway für das Back-End-Ziel verwendet wird. Dadurch werden potenzielle Probleme mit absoluten URLs, Umleitungs-URLs und hostgebundenen Cookies vermieden.
Wenn Sie bei der Einrichtung von Application Gateway von dieser Empfehlung abweichen müssen oder möchten, prüfen Sie die Auswirkungen einer solchen Konfiguration, wie im Architecture Center im folgenden Artikel ausführlicher beschrieben wird: 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 mehrinstanzenfähige Dienste auf dem Back-End. Ein App Service ist ein mehrinstanzenfähiger Dienst, der einen gemeinsam genutzten Speicherplatz mit einer einzigen 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, wird davon abgeraten, die Option Hostnamen aus der Back-End-Adresse auswählen zu aktivieren.
Hinweis
Diese Einstellung ist für die App Service-Umgebung nicht erforderlich, da es sich dabei um eine dedizierte Bereitstellung handelt.
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 wurde, wird die ursprüngliche Anforderung *https://appgw.eastus.cloudapp.azure.com/path1 beim Weiterleiten der Anforderung an den Back-End-Server in *https://www.contoso.com/path1 geändert.