Hinweis
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.
Ein Anwendungsgateway dient als zentraler Kontaktpunkt für Clients. Es verteilt eingehenden Anwendungsdatenverkehr über mehrere Back-End-Pools hinweg, z.B. virtuelle Azure-Computer, VM-Skalierungsgruppen, Azure App Service oder lokale bzw. externe Server. Zum Verteilen von Datenverkehr verwendet ein Anwendungsgateway verschiedene Komponenten, die in diesem Artikel beschrieben werden.
Front-End-IP-Adressen
Eine Front-End-IP-Adresse ist die IP-Adresse, die einem Anwendungsgateway zugeordnet ist. Sie können ein Anwendungsgateway mit einer öffentlichen IP-Adresse, mit einer privaten IP-Adresse oder mit beidem konfigurieren. Ein Anwendungsgateway unterstützt eine öffentliche oder eine private IP-Adresse. Ihr virtuelles Netzwerk und die öffentliche IP-Adresse müssen sich am gleichen Standort befinden wie Ihr Anwendungsgateway. Eine Front-End-IP-Adresse wird nach dem Erstellen einem Listener zugeordnet.
Statische und dynamische öffentliche IP-Adresse im Vergleich
Die Azure Application Gateway V2 SKU kann so konfiguriert werden, dass sie sowohl eine statische interne IP-Adresse als auch eine statische öffentliche IP-Adresse unterstützt, oder nur eine statische öffentliche IP-Adresse. Sie können es auch nur dann mit einer statischen internen (privaten) IP-Adresse konfigurieren, wenn Sie ein privates Application Gateway mit networkIsolationEnabled auf True festgelegt bereitstellen. Für die unterstützten Frontend-IP-Adresskombinationen siehe Frontend-IP-Adresskonfiguration. Für DNS-Verhalten bei ausschließlich privaten IP-Deployments siehe Application Gateway DNS Resolution.
Die V1-SKU kann so konfiguriert werden, dass sowohl statische oder dynamische interne IP-Adressen als auch dynamische öffentliche IP-Adressen verwendet werden. Die dynamische IP-Adresse der Application Gateway-Instanz ändert sich nicht, solange das Gateway aktiv ist. Sie kann sich nur dann ändern, wenn Sie das Gateway anhalten oder starten. Wenn beispielsweise Systemfehler auftreten oder Updates und Azure-Hostupdates durchgeführt werden, ändert sich die IP-Adresse nicht.
Der einem Anwendungsgateway zugeordnete DNS-Name ändert sich während des Lebenszyklus des Gateways nicht. Daher wird empfohlen, einen CNAME-Alias zu verwenden und damit auf die DNS-Adresse des Anwendungsgateways zu verweisen.
Listener
Ein Listener ist eine logische Entität, die auf eingehende Verbindungsanforderungen prüft. Ein Listener akzeptiert eine Anforderung, wenn das Protokoll, der Port, der Hostname und die IP-Adresse mit den entsprechenden Elementen der Listenerkonfiguration übereinstimmen.
Bevor Sie ein Anwendungsgateway verwenden, müssen Sie mindestens einen Listener hinzufügen. An ein Anwendungsgateway können mehrere Listener angefügt sein, und sie können für dasselbe Protokoll verwendet werden.
Wenn ein Listener eingehende Anforderungen von Clients erkannt hat, leitet das Anwendungsgateway diese Anforderungen an in der Regel konfigurierte Mitglieder im Back-End-Pool weiter.
Listener unterstützen die folgenden Ports und Protokolle.
Häfen
Ein Port wird von einem Listener auf die Clientanforderung überwacht. Du kannst Ports für v1- und v2-SKUs wie folgt konfigurieren:
| Artikelnummer (SKU) | Unterstützter Portbereich | Ausnahmen |
|---|---|---|
| V2 | 1 bis 64999 | Die Nutzung von Port 22 wird bei Private Link-fähigen Gateways nicht unterstützt. Port 53 |
| V1 | 1 bis 65502 | Port 3389 |
Protokolle
Application Gateway unterstützt die Webprotokolle HTTP, HTTPS, HTTP/2 und WebSocket über seinen Layer-7-Proxy. Es unterstützt außerdem TLS- und TCP-Protokolle über seinen Layer-4-Proxy, den Sie auf derselben Ressource konfigurieren können.
- Wählen Sie in der Listener-Konfiguration das HTTP-, HTTPS-, TLS- oder TCP-Protokoll.
- Verwenden Sie einen HTTPS- oder TLS-Listener für die TLS-Termination. Ein HTTPS/TLS-Listener offloads die Verschlüsselung und Entschlüsselung an Ihr Anwendungsgateway, sodass Ihre Server nicht durch TLS-Berechnungsaufwand belastet werden.
- Application Gateway unterstützt WebSockets und HTTP/2-Protokolle nativ, und WebSocket-Unterstützung ist standardmäßig aktiviert. Die WebSocket-Unterstützung kann von Benutzern nicht selektiv aktiviert oder deaktiviert werden. Sie können das WebSocket-Protokoll sowohl mit HTTP- als auch mit HTTPS-Listenern verwenden.
Die folgende Tabelle fasst zusammen, wie Application Gateway jedes Protokoll unterstützt.
| Protokoll | Proxy | Wählbar als Listenerprotokoll | Details zum Support |
|---|---|---|---|
| HTTP | Ebene 7 | Yes | Nativ über den Layer-7-Proxy unterstützt. |
| HTTPS | Ebene 7 | Yes | Nutze einen HTTPS-Listener für die TLS-Terminierung, damit das Gateway Verschlüsselung und Entschlüsselung von deinen Servern entlastet. |
| HTTP/2 | Ebene 7 | No | Nur für Clients verfügbar, die sich mit Application Gateway-Listenern verbinden. Die Kommunikation mit Backend-Serverpools erfolgt immer über HTTP/1.1. Standardmäßig deaktiviert; Du kannst es aktivieren. |
| WebSocket | Ebene 7 | No | Standardmäßig aktiviert, ohne benutzerkonfigurierbare Einstellung zum selektiven Aktivieren oder Deaktivieren. Sie können das WebSocket-Protokoll sowohl mit HTTP- als auch mit HTTPS-Listenern verwenden. |
| TLS | Ebene 4 | Yes | Unterstützt über den Layer-4-Proxy, den du auf derselben Ressource konfigurieren kannst. |
| TCP | Ebene 4 | Yes | Unterstützt über den Layer-4-Proxy, den du auf derselben Ressource konfigurieren kannst. |
Hinweis
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. Sie können es aktivieren.
Benutzerdefinierte Fehlerseiten
Mit Application Gateway können Sie benutzerdefinierte Fehlerseiten erstellen, anstatt Standardfehlerseiten anzuzeigen. Sie können Ihr eigenes Branding und Layout verwenden, indem Sie eine benutzerdefinierte Fehlerseite verwenden. Application Gateway zeigt eine benutzerdefinierte Fehlerseite an, wenn eine Anforderung das Back-End nicht erreichen kann.
Weitere Informationen finden Sie unter Benutzerdefinierte Application Gateway-Fehlerseiten.
Arten von Listenern
Es gibt zwei Arten von Listenern:
Basic Diese Listener lauschen an einer einzelnen Domänenwebsite, wo eine einzelne DNS-Zuordnung zur IP-Adresse des Anwendungsgateways vorliegt. Sie benötigen diese Listener-Konfiguration, wenn Sie eine einzelne Website hinter einem Application Gateway hosten.
Mehrere Websites. Sie benötigen diese Listener-Konfiguration, wenn Sie Routing basierend auf dem Hostnamen oder Domainnamen für mehr als eine Webanwendung auf demselben Anwendungsgateway konfigurieren möchten. Mit diesem Listener können Sie eine effizientere Topologie für Ihre Deployments konfigurieren, indem Sie bis zu 100+ Websites zu einem Anwendungsgateway hinzufügen. Jede Website kann an ihren eigenen Back-End-Pool weitergeleitet werden. Beispielsweise können die drei Domänen „contoso.com“, „fabrikam.com“ und „adatum.com“ auf die IP-Adresse des Anwendungsgateways verweisen. Sie erstellen drei Listener vom Typ „Mehrere Websites“ und konfigurieren jeden Listener für den jeweiligen Port und die jeweilige Protokolleinstellung.
Sie können außerdem Wildcard-Hostnamen in einem Multi-Site-Listener und bis zu fünf Hostnamen pro Listener definieren. Weitere Informationen finden Sie unter Hostnamen mit Platzhaltern in Listenern.
Weitere Informationen zur Konfiguration eines Multi-Site-Listeners finden Sie unter Multiple-site hosting in Application Gateway using Azure Portal.
Nachdem Sie einen Listener erstellt haben, ordnen Sie ihm eine Anforderungsroutingregel zu. Diese Regel bestimmt, wie die vom Listener empfangene Anforderung an das Back-End weitergeleitet werden soll. Die Request-Routing-Regel enthält außerdem den Backend-Pool, zu dem geroutet werden soll, sowie die HTTP-Einstellung, in der der Backend-Port, das Protokoll und andere Einstellungen genannt werden.
Anforderungsroutingregeln
Eine Anforderungsroutingregel ist eine wichtige Komponente eines Anwendungsgateways, da sie bestimmt, wie Datenverkehr im Listener weitergeleitet wird. Diese Regel bindet den Listener, den Back-End-Serverpool und die Back-End-HTTP-Einstellungen.
Wenn ein Listener eine Anforderung akzeptiert, leitet die Anforderungsroutingregel die Anwendung an das Back-End weiter oder an einen anderen Ort um. Wenn die Anforderung an das Back-End weitergeleitet wird, definiert die Anforderungsroutingregel, an welchen Back-End-Serverpool die Weiterleitung erfolgen soll. Die Anforderungsroutingregel legt fest, ob die Header in der Anforderung neu geschrieben werden sollen. Ein Listener kann mit genau einer Regel verknüpft werden.
Es gibt drei Arten von Request-Routing-Regeln:
Basic Alle Anforderungen für den zugeordneten Listener (Beispiel: blog.contoso.com/*) werden mit der zugeordneten HTTP-Einstellung an den zugeordneten Back-End-Pool weitergeleitet.
Fortgeschrittenes Routing. Diese Art von Regel ermöglicht es Ihnen, dynamische Routing-Entscheidungen basierend auf den HTTP-Anfrageattributen zu treffen. Es bewertet die eingehenden Anfragen anhand konfigurierter Bedingungen und leitet den Verkehr basierend auf den Bewertungsergebnissen zu festgelegten Zielen.
Important
Die erweiterte Regel befindet sich derzeit in der Vorschau. Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten rechtliche Bedingungen. Sie gelten für diejenigen Azure-Features, die sich in der Beta- oder Vorschauversion befinden oder aber anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.
Diese Funktion wird für Multisite-Listener und Layer-4-TCP/TLS-Proxys nicht unterstützt
Die folgende Tabelle vergleicht die drei Regeltypen.
| Regeltyp | Anwendungsfall | Grundlage für das Routing | Unterstützte Backends |
|---|---|---|---|
| Basic | Senden Sie jede Anfrage, die ein Zuhörer akzeptiert, an dieselbe Anwendung. | Alle Anfragen an den zugehörigen Listener, zum Beispiel blog.contoso.com/*. |
Ein einzelner zugehöriger Backend-Pool, der über die zugehörige HTTP-Einstellung erreicht wird. |
| Advanced | Triff dynamische Routing-Entscheidungen basierend auf HTTP-Anfrageattributen. | Konfigurierte Bedingungen wurden anhand eingehender Anfragen ausgewertet. | Spezifizierte Ziele wurden aus den Ergebnissen der Bedingungsauswertung ausgewählt. |
| Pfadbasiert | Leite Anfragen, die von einem Listener ankommen, basierend auf der angeforderten URL an verschiedene Anwendungen zu. | Der Pfad der URL in der Anfrage. Das Pfadmuster gilt nur für den URL-Pfad, nicht für dessen Abfrageparameter. | Ein spezieller Backend-Pool für jedes passende Pfadmuster, dazu ein Standard-Backend-Pool und HTTP-Einstellungen für Anfragen, die keiner pfadbasierten Regel entsprechen. |
Weitere Informationen finden Sie unter URL-basiertes Routing.
Umleitungsunterstützung
Die Routingregel für Anforderungen ermöglicht es Ihnen auch, Datenverkehr im Anwendungsgateway umzuleiten. Dieser Umleitungsmechanismus ist generisch, sodass Sie mit Regeln zu und von jedem von Ihnen definierten Port umleiten können.
Sie können als Umleitungsziel einen anderen Listener (wodurch die automatische Umleitung von HTTP zu HTTPS ermöglicht werden kann) oder eine externe Website auswählen. Sie können außerdem auswählen, ob die Umleitung temporär oder dauerhaft erfolgen soll, oder angeben, dass der URI-Pfad und die Abfragezeichenfolge an die Umleitungs-URL angefügt werden sollen.
Weitere Informationen finden Sie unter Umleiten von Datenverkehr im Application Gateway.
Neuschreibung von HTTP-Headern und der URL
Application Gateway kann HTTP(S)-Anfrage- und Antwortheader hinzufügen, entfernen oder aktualisieren, zusammen mit URL-Pfad- und Abfragestring-Parametern, während der Datenverkehr zwischen Clients und Backend-Pools wechselt. Für eine vollständige Erklärung und Konfigurationsschritte siehe HTTP-Header und URL auf Ihrem Anwendungsgateway neu schreiben.
HTTP-Einstellungen
Eine HTTP-Einstellung, auch Backend-Einstellung genannt, ist die Konfiguration, die bestimmt, wie der Datenverkehr die Backend-Server erreicht. Es definiert den Port und das Protokoll, das das Anwendungsgateway zur Verbindung zu diesen Servern verwendet, wie sich Verbindungen verhalten und wie das Gateway die Backend-Gesundheit überwacht. Eine Request-Routing-Regel legt fest, welche HTTP-Einstellung angewendet werden soll, wenn eine Anfrage an einen Backend-Pool weitergeleitet wird.
Die Angaben für den Port und das Protokoll in den HTTP-Einstellungen bestimmen, ob der Datenverkehr zwischen dem Anwendungsgateway und den Back-End-Servern verschlüsselt wird (um End-to-End-TLS bereitzustellen) oder ob er unverschlüsselt bleibt.
Nutzen Sie diese Komponente, um:
Bestimmen Sie, ob eine Benutzersitzung auf demselben Server gehalten werden soll, indem Sie die cookie-basierte Session-Affinität verwenden.
Ordnungsgemäßes Entfernen von Mitgliedern des Back-End-Pools über den Verbindungsausgleich.
Ordnen Sie einen benutzerdefinierten Tests zum Überwachen der Integrität des Back-Ends zu, legen Sie das Timeoutintervall fest, überschreiben Sie den Hostnamen und -pfad in der Anforderung, und legen Sie die Einstellungen für das App Service-Back-End mit nur einem einfachen Klick fest.
Back-End-Pools
Ein Backend-Pool leitet Anfragen an Backend-Server weiter, die die Anfragen bedienen. Back-End-Pools können Folgendes umfassen:
- NICs
- VM-Skalierungsgruppen
- Öffentliche IP-Adressen
- Interne IP-Adressen
- FQDN (vollqualifizierte Domänennamen) oder Kurznamen (Single-Label Domain Names), sofern Ihr DNS-Server sie auflösen kann
- Multitenant Back-Ends wie Azure App Service und Azure Container Apps. Anleitungen zur Implementierung finden Sie unter Schutz von Container-Apps mit Application Gateway und WAF.
Mitglieder des Application Gateway-Back-End-Pools sind nicht an eine Verfügbarkeitsgruppe gebunden. Ein Anwendungsgateway kann mit Instanzen außerhalb des eigenen virtuellen Netzwerks kommunizieren. Mitglieder von Back-End-Pools können auf mehrere Cluster und Rechenzentren verteilt sein oder sich außerhalb von Azure befinden, sofern sie über IP-Konnektivität verfügen.
Wenn Sie interne IP-Adressen als Back-End-Pool-Mitglieder verwenden, ist das Peering virtueller Netzwerke oder ein VPN-Gateway erforderlich. Das Peering virtueller Netzwerke wird unterstützt und bietet Vorteile für den Lastenausgleich von Datenverkehr in anderen virtuellen Netzwerken.
Ein Anwendungsgateway kann auch mit lokalen Servern kommunizieren, wenn diese über Azure ExpressRoute oder VPN-Tunnel verbunden sind und Datenverkehr zulässig ist.
Sie können verschiedene Back-End-Pools für verschiedene Arten von Anforderungen erstellen. Sie können z.B. einen Back-End-Pool für allgemeine Anforderungen und einen anderen für Anforderungen an die Microservices Ihrer Anwendung erstellen.
Nachdem Sie VM-Skalierungsgruppen als Back-End-Poolmitglieder hinzugefügt haben, müssen Sie ein Upgrade der VM-Skalierungsgruppeninstanzen durchführen. Bis du die Scale-Set-Instanzen aktualisierst, ist das Backend ungesund.
Integritätstests
In der Standardeinstellung überwacht ein Anwendungsgateway die Integrität aller Ressourcen in seinem Back-End-Pool und entfernt automatisch alle fehlerhaften Ressourcen. Es überwacht die fehlerhaften Instanzen weiterhin und fügt sie dem fehlerfreien Back-End-Pool hinzu, sobald sie verfügbar sind und auf Integritätsüberprüfungen reagieren.
Zusätzlich zur Nutzung der standardmäßigen Überwachung der Integritätsüberprüfung können Sie die Integritätsüberprüfung auch an die Anforderungen Ihrer Anwendung anpassen. Benutzerdefinierte Überprüfungen ermöglichen Ihnen eine präzisere Kontrolle über die Überwachung des Systemzustands. Bei der Verwendung benutzerdefinierter Probes können Sie einen individuellen Hostnamen, einen URL-Pfad, ein Probe-Intervall sowie die Anzahl der fehlgeschlagenen Antworten festlegen, ab der eine Instanz im Backend-Pool als fehlerhaft markiert wird. Zudem lassen sich benutzerdefinierte Statuscodes, Übereinstimmungen im Antworttext (Response Body) und weitere Parameter konfigurieren. Konfigurieren Sie benutzerdefinierte Sonden, um die Gesundheit jedes Backend-Pools zu überwachen.
Weitere Informationen finden Sie unter Überwachen der Integrität Ihres Anwendungsgateways.
Nächste Schritte
Erstellen eines Anwendungsgateways