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 eingeben, die den entsprechenden Werten in der eingehenden Anforderung auf dem Gateway entsprechen.

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 dem Basislistener in der Reihenfolge an erster Stelle steht, wird sie zuerst verarbeitet und akzeptiert alle Anforderungen für diese Port- und IP-Kombination. Um dies zu vermeiden, konfigurieren Sie die Regeln zuerst mit Listenern für mehrere Standorte, und verschieben Sie die Regel mit dem Basislistener an die letzte Stelle in der Liste.

Bei der v2-SKU definiert die Regelpriorität die Reihenfolge, in der Listener verarbeitet werden. Für Platzhalter- und einfache Listener sollte eine Priorität mit einem Wert definiert werden, der größer als der von standortspezifischen Listenern und Listenern für mehrere Standorte ist. So wird sichergestellt, dass standortspezifische Listener und Listener für mehrere Standorte vor Platzhalter- und einfachen 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 lauscht auf eingehende Anforderungen für diese 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 Übersicht über TLS-Beendigung und End-to-End-TLS mit Application Gateway.

Unterstützung zusätzlicher Protokolle

HTTP2-Unterstützung

Die Unterstützung des HTTP/2-Protokolls ist nur für Clients verfügbar, die mit Application Gateway-Listenern verbunden sind. Die Kommunikation mit Back-End-Serverpools erfolgt immer über HTTP/1.1. Die HTTP/2-Unterstützung ist standardmäßig deaktiviert. Der folgende Azure PowerShell-Codeausschnitt zeigt, wie Sie sie aktivieren:

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

$gw.EnableHttp2 = $true

Set-AzApplicationGateway -ApplicationGateway $gw

Von Bedeutung

Beim Erstellen einer Anwendungsgatewayressource über das Azure-Portal wird die Standardoption für HTTP2 als aktiviert festgelegt. Sie können die Option "Deaktiviert" während der Erstellung auswählen und die HTTP2-Unterstützung mithilfe des Azure-Portals erneut aktivieren, indem Sie unter HTTP2 in > auswählen.

In Fällen, in denen HTTP2 von einem Client nicht unterstützt wird, wird HTTP1.1 verwendet. Durch aktivieren von HTTP2 wird HTTP1.1 nicht deaktiviert; es ermöglicht Unterstützung für beide.

Hinweis

Das Anwendungsgateway unterstützt nur HTTP/2 über TLS (HTTPS-Listener). HTTP/2 Cleartext (h2c)-Protokollupgradeversuche von HTTP/1.1 werden nicht unterstützt und führen zu einem Fehler vom Typ 403 Forbidden. Clients, die h2c-Upgrades versuchen, sollten systemeigene HTTP/2-Verbindungen über HTTPS verwenden oder auf HTTP/1.1 verbleiben.

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

Sie können benutzerdefinierte Fehlerseiten für verschiedene Antwortcodes definieren, die vom Anwendungsgateway zurückgegeben werden. Die Antwortcodes, für die Sie Fehlerseiten konfigurieren können, sind 400, 403, 405, 408, 500, 502, 503 und 504. Sie können globale oder listenerspezifische Fehlerseitenkonfigurationen verwenden, um sie für jeden Listener präzise festzulegen. Weitere Informationen finden Sie unter Create Application Gateway custom error pages (Erstellen von benutzerdefinierten Application Gateway-Fehlerseiten).

Hinweis

Ein Fehler vom Back-End-Server wird vom Anwendungsgateway unverändert an den Client weitergegeben.

TLS-Richtlinie

Sie können die TLS/SSL-Zertifikatverwaltung zentralisieren sowie den Ver- und Entschlüsselungsaufwand für eine Back-End-Serverfarm verringern. Diese zentralisierte TLS-Behandlung ermöglicht auch die Angabe einer zentralen TLS-Richtlinie, die auf Ihre Sicherheitsanforderungen abgestimmt ist. Sie können zwischen einer vordefinierten oder benutzerdefinierten TLS-Richtlinie wählen.

Sie konfigurieren die TLS-Richtlinie, um die TLS-Protokollversionen zu steuern. Sie können eine Application Gateway-Instanz so konfigurieren, dass es eine Mindestprotokollversion für TLS-Handshakes von 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 vom Listener empfangene Anforderungen an das Back-End weitergeleitet werden.

Nächste Schritte

  • Last updated on