Konfigurieren von Azure Application Gateway-Komponenten
Azure Application Gateway weist mehrere Komponenten auf, die gemeinsam zum Weiterleiten von Anforderungen an einen Pool von Webservern und zum Überprüfen der Integrität dieser Webserver verwendet werden. Zu diesen Komponenten gehören die Front-End-IP-Adresse, Back-End-Pools, Routingregeln, Integritätstests und Listener. Optional kann das Gateway auch eine Firewall implementieren.
Wissenswertes zu Application Gateway-Komponenten
Im Folgenden erfahren Sie, wie die Komponenten eines Anwendungsgateways zusammenarbeiten.
Die Front-End-IP-Adresse empfängt die Clientanforderungen.
Eine optionale Web Application Firewall überprüft eingehenden Datenverkehr auf häufige Bedrohungen, bevor die Anforderungen die Listener erreichen.
Mindestens ein Listener empfängt den Datenverkehr und leitet die Anforderungen an den Back-End-Pool weiter.
Routingregeln definieren, wie die Anforderung analysiert wird, um sie an den entsprechenden Back-End-Pool weiterzuleiten.
Ein Back-End-Pool enthält Webserver für Ressourcen wie VMs oder VM-Skalierungsgruppen. Jeder Pool verfügt über einen Lastenausgleich zur Verteilung der Workload auf die Ressourcen.
Integritätstests bestimmen, welche Back-End-Pool-Server für den Lastenausgleich verfügbar sind.
Das folgende Flussdiagramm veranschaulicht, wie die Application Gateway-Komponenten zusammenarbeiten, um Datenverkehrsanforderungen zwischen Front-End- und Back-End-Pool in Ihrer Konfiguration weiterzuleiten.
Front-End-IP-Adresse
Clientanforderungen werden über Ihre Front-End-IP-Adresse empfangen. Ihr Anwendungsgateway kann eine öffentliche oder eine private IP-Adresse oder beides aufweisen. Sie können nur eine öffentliche IP-Adresse und nur eine private IP-Adresse verwenden.
Web Application Firewall (optional)
Sie können Azure Web Application Firewall für Azure Application Gateway aktivieren, um eingehende Anforderungen zu verarbeiten, bevor sie Ihren Listener erreichen. Die Firewall überprüft alle Anforderungen gemäß dem Open Web Application Security Project (OWASP) auf Bedrohungen. Zu den gängigen Bedrohungen zählen die Einschleusung von SQL-Befehlen, Cross-Site Scripting, die Einschleusung von Befehlen, HTTP-Anforderungsschmuggel und HTTP-Antwortaufteilung sowie der Einschluss von Remotedateien. Weitere Bedrohungen können von Bots, Crawlern, Scannern und Verletzungen und Anomalien des HTTP-Protokolls ausgehen.
Im OWASP ist eine Reihe allgemeiner Regeln für die Erkennung von Angriffen definiert. Diese Regeln werden als CRS (Core Rule Set) bezeichnet. Da solche Angriffe immer komplexer werden, werden diese Regeln ständig überprüft. Azure Web Application Firewall unterstützt zwei Regelsätze: CRS 2.2.9 und CRS 3.0. CRS 3.0 ist die Standardeinstellung und der neuere Regelsatz der beiden. Bei Bedarf können Sie auch nur spezifische Regeln eines Regelsatzes auswählen, um gegen bestimmte Bedrohungen vorzugehen. Darüber hinaus können Sie die Firewall anpassen, um festzulegen, welche Elemente in einer Anforderung überprüft werden sollen, und um die Größe von Nachrichten einzuschränken, um die Überlastung Ihrer Server durch große Uploads zu verhindern.
Listener
Listener empfangen den Datenverkehr auf einer festgelegten Kombination aus Protokoll, Port, Host und IP-Adresse. Jeder Listener leitet Anforderungen gemäß Ihren Routingregeln an einen Back-End-Pool von Servern weiter. Es kann sich um einen Basislistener oder einen Listener für mehrere Standorte handeln. Basislistener leiten Anforderungen lediglich anhand des Pfads in der URL weiter. Ein Listener für mehrere Standorte kann Anforderungen auch anhand des Hostnamens in der URL weiterleiten. Listener verarbeiten außerdem TLS-/SSL-Zertifikate zum Schutz Ihrer Anwendung zwischen dem Benutzer und Application Gateway.
Routingregeln
Eine Routingregel bindet Ihre Listener an die Back-End-Pools. Eine Regel legt fest, wie die Elemente für den Hostnamen und den Pfad in der URL einer Anforderung interpretiert werden, und leitet die Anforderung dann an den entsprechenden Back-End-Pool weiter. Routingregeln weisen außerdem zugehörige HTTP-Einstellungen auf. Diese HTTP-Einstellungen geben an, ob (und wie) der Datenverkehr zwischen Application Gateway und den Back-End-Servern verschlüsselt wird. Weitere Konfigurationsinformationen sind Protokoll, Sitzungsbindung, Verbindungsausgleich, Zeitraum für das Anforderungstimeout und Integritätstests.
Back-End-Pools
Ein Back-End-Pool verweist auf eine Sammlung von Webservern. Sie stellen die IP-Adressen der jeweiligen Webserver und den Port bereit, auf dem beim Konfigurieren des Pools auf Anforderungen gelauscht wird. Jeder Pool kann eine feste Gruppe von VMs, eine VM-Skalierungsgruppe, eine von Azure App Services gehostete App oder eine Sammlung lokaler Server festlegen. Jeder Back-End-Pool verfügt über einen zugehörigen Lastenausgleich, der die Last auf den Pool verteilt.
Integritätstests
Integritätstests bestimmen, welche Server in Ihrem Back-End-Pool für den Lastenausgleich verfügbar sind. Application Gateway verwendet einen Integritätstest, um eine Anforderung an einen Server zu senden. Wenn der Server eine HTTP-Antwort mit einem Statuscode zwischen 200 und 399 zurückgibt, wird der Server als fehlerfrei eingestuft. Wenn Sie keinen Integritätstest konfigurieren, erstellt Application Gateway einen Standardtest, der 30 Sekunden lang wartet, bevor ein Server als nicht verfügbar (fehlerhaft) eingestuft wird.