Application Gateway-Listenerkonfiguration

Hinweis

Es wird empfohlen, das Azure Az PowerShell-Modul für die Interaktion mit Azure zu verwenden. Informationen zu den ersten Schritten finden Sie unter Installieren von Azure PowerShell. Informationen zum Migrieren zum Az PowerShell-Modul finden Sie unter Migrieren von Azure PowerShell von AzureRM zum Az-Modul.

Ein Listener ist eine logische Entität, die mithilfe von Port, Protokoll, Host und IP-Adresse auf eingehende Verbindungsanforderungen prüft. Wenn Sie den Listener konfigurieren, müssen Sie Werte für diese Einstellungen eingeben, die mit den entsprechenden Werten in der eingehenden Anfrage auf dem Gateway übereinstimmen.

Wenn Sie ein Application Gateway mithilfe des Azure-Portals erstellen, erstellen Sie außerdem einen Standardlistener durch Auswählen von Protokoll und Port für den Listener. Sie können wahlweise HTTP2-Unterstützung auf dem Listener aktivieren. Nach der Erstellung des Application Gateways können Sie die Einstellungen dieses Standardlisteners (appGatewayHttpListener) bearbeiten oder neue Listener erstellen.

Listenertyp

Wenn Sie einen neuen Listener erstellen, wählen Sie zwischen basic und Multi-Site aus. Die Wahl hängt davon ab, ob das Routing vom Hostnamen der eingehenden Anfrage abhängt.

Das Routing hängt vom Hostnamen ab	Listenertyp	Behavior
No	Basic	Akzeptieren und leiten Sie alle Anfragen für jede Domain an Backend-Pools weiter. Erfahren Sie, wie Sie ein Application Gateway mit einem grundlegenden Listener erstellen.
Yes	Mehrere Standorte	Leite Anfragen basierend auf dem host-Header oder Hostnamen an verschiedene Backend-Pools weiter. Application Gateway verwendet HTTP 1.1-Hostheader, um mehrere Websites an der gleichen öffentlichen IP-Adresse und dem gleichen Port zu hosten. Um Anfragen auf demselben Port zu unterscheiden, müssen Sie einen Hostnamen angeben, der mit der eingehenden Anfrage übereinstimmt.

Um mehr über Multi-Site-Listener zu erfahren, siehe Hosting mehrerer Standorte mit Application Gateway.

Verarbeitungsreihenfolge von Listenern

Bei der v1-SKU werden Anforderungen entsprechend der Reihenfolge der Regeln und des Listenertyps abgeglichen. Wenn eine Regel mit einem einfachen Listener zuerst in der Reihenfolge steht, wird sie zuerst verarbeitet und akzeptiert jede Anfrage für diese Port- und IP-Kombination. Um dieses Verhalten zu vermeiden, konfigurieren Sie die Regeln zunächst mit Multi-Site-Listenern und verschieben Sie die Regel mit dem einfachen Listener an das Ende der Liste.

Bei der v2-SKU definiert die Regelpriorität die Reihenfolge, in der Listener verarbeitet werden. Definiere Wildcard- und Basic-Listener mit einer Prioritätsnummer, die höher ist als standortspezifische und Multi-Site-Listener. Diese Konfiguration stellt sicher, dass standortspezifische und Multi-Site-Listener vor den Wildcard- und Basis-Listenern ausgeführt werden.

Die folgende Tabelle fasst zusammen, wie die Verarbeitungsreihenfolge in jeder SKU bestimmt wird.

Artikelnummer (SKU)	Was die Reihenfolge bestimmt	Empfohlene Konfiguration
v1	Die Reihenfolge der Regeln und die Art des Zuhörers. Eine Regel mit einem einfachen Listener, die in der Reihenfolge an erster Stelle steht, verarbeitet Anfragen zuerst und nimmt jede Anfrage für diese Kombination aus Port und IP-Adresse an.	Konfigurieren Sie die Regeln zuerst mit Multi-Site-Listenern und verschieben Sie die Regel mit dem Basis-Listener auf die letzte Position in der Liste.
v2	Regelpriorität.	Definieren Sie Wildcard- und Basic-Listener mit einer Prioritätszahl, die höher ist als die Prioritätszahl, die für standortspezifische und Multi-Site-Listener verwendet wird, sodass die standortspezifischen und Multi-Site-Listener zuerst ausgeführt werden.

Frontend-IP-Adresse

Wählen Sie die Front-End-IP-Adresse aus, die Sie diesem Listener zuordnen möchten. Der Listener wartet auf eingehende Anfragen an dieser IP-Adresse.

Wählen Sie eine öffentliche Frontend-IP-Adresse, wenn Clients die Anwendung hinter diesem Listener über das Internet erreichen. Wählen Sie eine private Frontend-IP-Adresse für einen internen Endpunkt, der nicht mit dem Internet verbunden ist, wie etwa eine interne Geschäftsanwendung oder eine Ebene einer Multi-Tier-Anwendung, die weiterhin Lastverteilung, Sitzungs-Stickiness oder TLS-Terminierung benötigt. Für die unterstützten Kombinationen siehe Frontend-IP-Adresskonfiguration.

Hinweis

Das Application Gateway-Front-End unterstützt Dual-Stack-IP-Adressen. Sie können bis zu vier Front-End-IP-Adressen erstellen: zwei IPv4-Adressen (öffentlich und privat) und zwei IPv6-Adressen (öffentlich und privat).

Frontend-Port

Ordnen Sie einen Front-End-Port zu. Sie können einen vorhandenen Port auswählen oder einen neuen erstellen. Wählen Sie einen beliebigen Wert aus dem zulässigen Portbereich aus. Sie können nicht nur die bekannten Ports wie 80 und 443 verwenden, sondern jeden geeigneten zulässigen benutzerdefinierten Port. Derselbe Port kann für öffentliche und private Listener verwendet werden.

Port 80 ist die typische Wahl für einen HTTP-Listener, und Port 443 ist die typische Wahl für einen HTTPS-Listener. Verwenden Sie einen benutzerdefinierten Port, wenn Ihre Anwendung einen verlangt, und bestätigen Sie, dass der Wert im erlaubten Bereich Ihrer SKU liegt, da der unterstützte Bereich zwischen den v1- und v2-SKUs unterschiedlich ist.

Hinweis

Wenn Sie private und öffentliche Listener mit demselben Port verwenden, ändert das Anwendungsgateway das Ziel des eingehenden Flows in die Front-End-IP-Adressen Ihres Gateways. Je nach Konfiguration Ihrer Netzwerksicherheitsgruppe benötigen Sie daher möglicherweise eine eingehende Regel mit Ziel-IP-Adressen als öffentliche und private Front-End-IP-Adressen Ihres Anwendungsgateways.

Eingehende Regel:

• Quelle: (gemäß Ihren Anforderungen)
• Ziel-IP-Adressen: öffentliche und private Front-End-IP-Adressen Ihres Anwendungsgateways.
• Zielport: (gemäß Listenerkonfiguration)
• Protokoll: TCP

Ausgangsregel: (keine spezifische Anforderung)

Protokoll

Wähle HTTP oder HTTPS. Wählen Sie HTTPS, wenn der Datenverkehr zwischen Client und Anwendungsgateway verschlüsselt sein muss, was es dem Gateway auch ermöglicht, die Verschlüsselung und Entschlüsselung zu entlasten, sodass Ihre Backend-Server nicht durch TLS-Berechnungsaufwand belastet sind. Wählen Sie HTTP, wenn diese Verschlüsselung für den Datenverkehr, den dieser Listener akzeptiert, nicht erforderlich ist.

• Wenn Sie sich für HTTP entscheiden, ist der Datenverkehr zwischen dem Client und dem Application Gateway unverschlüsselt.

• Wählen Sie HTTPS aus, wenn Sie die TLS-Beendigung oder End-to-End-TLS-Verschlüsselung verwenden möchten. Der Datenverkehr zwischen dem Client und dem Anwendungsgateway wird verschlüsselt, und die TSL-Verbindung endet am Anwendungsgateway. Wenn Sie End-to-End-TLS-Verschlüsselung für das Back-End-Ziel wünschen, müssen Sie HTTPS auch in der Back-End-HTTP-Einstellung auswählen. Dadurch wird sichergestellt, dass der Datenverkehr verschlüsselt wird, wenn das Anwendungsgateway eine Verbindung mit dem Back-End-Ziel initiiert.

Zum Konfigurieren der TLS-Terminierung muss dem Listener ein TLS/SSL-Zertifikat hinzugefügt werden. Dadurch kann der Application Gateway eingehenden Datenverkehr entschlüsseln und den Antwortdatenverkehr an den Client verschlüsseln. Das Zertifikat für die Application Gateway muss im PFX-Format (Personal Information Exchange) vorliegen, das sowohl die privaten als auch die öffentlichen Schlüssel enthält.

Hinweis

Wenn Sie ein TLS-Zertifikat aus Key Vault für einen Listener verwenden, müssen Sie sicherstellen, dass Ihr Application Gateway immer Zugriff auf diese verknüpfte Schlüsseltresorressource und das darin gespeicherte Zertifikatobjekt hat. Dies ermöglicht nahtlose Vorgänge der TLS-Terminierungsfunktion und erhält die allgemeine Integrität Ihrer Gatewayressource. Wenn eine Application Gateway-Ressource einen fehlerhaft konfigurierten Schlüsseltresor erkennt, versetzt sie die zugeordneten HTTPS-Listener automatisch in einen deaktivierten Zustand. Weitere Informationen

Unterstützte Zertifikate

Siehe Überblick über TLS-Terminierung und End-to-End-TLS mit Application Gateway.

Unterstützung zusätzlicher Protokolle

HTTP/2-Unterstützung

Application Gateway unterstützt das HTTP/2-Protokoll für Clienten, die sich mit Application Gateway-Listenern verbinden. Die Kommunikation mit Backend-Serverpools erfolgt immer über HTTP/1.1. Die HTTP/2-Unterstützung ist standardmäßig deaktiviert. Der folgende Azure PowerShell-Code-Ausschnitt zeigt, wie man diese Unterstützung aktiviert:

$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm

$gw.EnableHttp2 = $true

Set-AzApplicationGateway -ApplicationGateway $gw

Von Bedeutung

Wenn Sie eine Anwendungs-Gateway-Ressource über das Azure-Portal erstellen, ist die Standardoption für HTTP2 aktiviert. Sie können während der Erstellung Deaktiviert auswählen und die HTTP/2-Unterstützung wieder aktivieren, indem Sie im Azure-Portal in Application Gateway Konfiguration unter > die Option Aktiviert auswählen.

In Fällen, in denen ein Client kein HTTP/2 unterstützt, verwendet die Verbindung HTTP/1.1. Das Aktivieren von HTTP/2 deaktiviert nicht HTTP/1.1; es ermöglicht Unterstützung für beides.

Hinweis

Das Anwendungsgateway unterstützt nur HTTP/2 über TLS (HTTPS-Listener). Application Gateway unterstützt keine HTTP/2 Cleartext (h2c)-Protokoll-Upgrade-Versuche von HTTP/1.1 und liefert einen 403 Verboten-Fehler. Clienten, die H2C-Upgrades versuchen, sollten native HTTP/2-Verbindungen über HTTPS verwenden oder auf HTTP/1.1 bleiben.

HTTP/3 (QUIC) Unterstützung

Von Bedeutung

HTTP/3-Unterstützung in Azure Application Gateway befindet sich derzeit in der Vorschau. Während der Vorschau können sich Funktionen, Verfügbarkeit und andere Aspekte dieses Features als Reaktion auf Feedback ändern.

Diese Vorschauversion wird ohne Vereinbarung zum Servicelevel bereitgestellt und wird für Produktionsworkloads nicht empfohlen. Bestimmte Features werden möglicherweise nicht unterstützt oder können eingeschränkte Funktionen aufweisen.

Weitere Informationen finden Sie unter Zusätzliche Nutzungsbedingungen für Microsoft Azure-Vorschauversionen.

Application Gateway unterstützt HTTP/3 nur für Client-Verbindungen, die Basic-Listener verwenden. Ein HTTP/3-fähiger Listener kann auch HTTP/1.1- oder HTTP/2-Verkehr von Clients aufnehmen. Die Kommunikation von Application Gateway zu Backend-Serverpools erfolgt weiterhin über HTTP/1.1.

HTTP/3-Unterstützung ist standardmäßig deaktiviert.

Wie HTTP/3-Unterstützung beworben wird

Application Gateway wirbt mit HTTP/3-Unterstützung an, indem es den Alt-Svc HTTP-Antwort-Header verwendet. Wenn Sie HTTP/3 auf einem Listener aktivieren, enthält Application Gateway in den Antworten folgenden Alt-Svc Header.

Alt-Svc: h3=":<listener-port>"; ma=86400

Wenn du HTTP/3 deaktivierst, enthält Application Gateway nicht den Alt-Svc-Header.

Clienten, die HTTP/3 unterstützen, können den beworbenen Dienst nutzen, um eine QUIC-Verbindung am Listener-Port herzustellen. Clienten, die HTTP/3 nicht unterstützen, verwenden weiterhin HTTP/2 oder HTTP/1.1 über TCP.

WebSocket-Unterstützung

Die WebSocket-Unterstützung ist standardmäßig aktiviert. Es gibt keine benutzerkonfigurierbare Einstellung, um sie zu aktivieren oder zu deaktivieren. Sie können das WebSocket-Protokoll sowohl mit HTTP- als auch mit HTTPS-Listenern verwenden.

Benutzerdefinierte Fehlerseiten

Du kannst benutzerdefinierte Fehlerseiten für verschiedene Antwortcodes definieren, die Application Gateway zurückgibt. Sie können Fehlerseiten für die Antwortcodes 400, 403, 405, 408, 500, 502, 503 und 504 konfigurieren. Verwenden Sie die Konfiguration der Fehlerseite auf globaler Ebene oder für einen bestimmten Listener, um sie für jeden Listener granular zu konfigurieren. Weitere Informationen finden Sie unter Create Application Gateway custom error pages (Erstellen von benutzerdefinierten Application Gateway-Fehlerseiten).

Hinweis

Application Gateway leitet einen Fehler vom Backend-Server an den Client weiter, ohne ihn zu ändern.

TLS-Richtlinie

Sie können die TLS/SSL-Zertifikatverwaltung zentralisieren sowie den Ver- und Entschlüsselungsaufwand für eine Back-End-Serverfarm verringern. Zentralisierte TLS-Bearbeitung ermöglicht es Ihnen außerdem, eine zentrale TLS-Richtlinie festzulegen, die Ihren Sicherheitsanforderungen entspricht. Du kannst eine vordefinierte oder benutzerdefinierte TLS-Richtlinie wählen.

Du konfigurierst die TLS-Richtlinie so, dass sie die Versionen des TLS-Protokolls steuert. Man kann ein Anwendungsgateway so konfigurieren, dass es eine Mindestprotokollversion für TLS-Handshakes aus TLS 1.0, TLS 1.1, TLS 1.2 und TLS 1.3 verwendet. Standardmäßig sind SSL 2.0 und 3.0 deaktiviert und nicht konfigurierbar. Weitere Informationen finden Sie unter TLS-Richtlinienübersicht für Azure Application Gateway.

Nachdem Sie einen Listener erstellt haben, ordnen Sie ihm eine Anforderungsroutingregel zu. Diese Regel bestimmt, wie Anfragen, die der Hörer erhält, an das Backend weitergeleitet werden.

Nächste Schritte

• Informationen zu den Regeln für das Anforderungsrouting.