Wie ein Anwendungs-Gateway funktioniert

• 11/16/2019
• 4 Minuten zu lesen
• • a
  • j
  • D
  • s
  • v
  • +2

Dieser Artikel erklärt, wie ein Anwendungs-Gateway eingehende Anfragen annimmt und an das Backend weiterleitet.

Wie ein Anwendungsgateway eine Anforderung annimmt

1. Bevor ein Client eine Anforderung an ein Anwendungsgateway sendet, löst er den Domänennamen des Anwendungsgateways mithilfe eines DNS-Servers (Domain Name System) auf. Azure kontrolliert den DNS-Eintrag, da sich alle Anwendungs-Gateways in der Domäne azure.com befinden.

2. Das Azure-DNS gibt die IP-Adresse an den Client zurück, bei der es sich um die Frontend-IP-Adresse des Anwendungs-Gateways handelt.

3. Das Anwendungs-Gateway nimmt eingehenden Datenverkehr über einen oder mehrere Listener entgegen. Ein Listener ist eine logische Einheit, die auf Verbindungsanfragen prüft. Er wird mit einer Frontend-IP-Adresse, einem Protokoll und einer Portnummer für Verbindungen von Clients zum Anwendungs-Gateway konfiguriert.

4. Wenn eine Web Application Firewall (WAF) verwendet wird, prüft das Anwendungs-Gateway die Header der Anforderung und den Body, falls vorhanden, anhand der WAF-Regeln. Dadurch wird festgestellt, ob die Anfrage gültig ist oder ein Sicherheitsrisiko darstellt. Wenn die Anfrage gültig ist, wird sie an das Backend weitergeleitet. Ist die Anfrage ungültig und befindet sich die WAF im Präventionsmodus, wird sie als Sicherheitsbedrohung blockiert. Im Erkennungsmodus wird die Anforderung bewertet und protokolliert, aber dennoch an den Backend-Server weitergeleitet.

Azure Application Gateway kann als interner Anwendungs-Load-Balancer oder als internetorientierter Anwendungs-Load-Balancer verwendet werden. Ein internetorientiertes Anwendungs-Gateway verwendet öffentliche IP-Adressen. Der DNS-Name eines internetorientierten Anwendungs-Gateways ist öffentlich auf seine öffentliche IP-Adresse auflösbar. Daher können internetorientierte Anwendungs-Gateways Client-Anforderungen aus dem Internet weiterleiten.

Interne Anwendungs-Gateways verwenden nur private IP-Adressen. Wenn Sie eine benutzerdefinierte oder private DNS-Zone verwenden, sollte der Domänenname intern zur privaten IP-Adresse des Anwendungs-Gateways auflösbar sein. Daher können interne Load-Balancer nur Anforderungen von Clients mit Zugriff auf ein virtuelles Netzwerk für das Anwendungs-Gateway weiterleiten.

Wie ein Anwendungs-Gateway eine Anforderung weiterleitet

Wenn eine Anforderung gültig ist und nicht von der WAF blockiert wird, wertet das Anwendungs-Gateway die Anforderungs-Routing-Regel aus, die mit dem Listener verknüpft ist. Diese Aktion bestimmt, an welchen Backend-Pool die Anforderung weitergeleitet werden soll.

Auf der Grundlage der Anforderungs-Routing-Regel bestimmt das Anwendungs-Gateway, ob alle Anforderungen auf dem Listener an einen bestimmten Backend-Pool weitergeleitet werden sollen, ob Anforderungen auf der Grundlage des URL-Pfads an verschiedene Backend-Pools weitergeleitet werden sollen oder ob Anforderungen an einen anderen Port oder eine externe Site umgeleitet werden sollen.

Wenn das Anwendungs-Gateway den Backend-Pool auswählt, sendet es die Anforderung an einen der gesunden Backend-Server im Pool (y.y.y.y). Der Zustand des Servers wird durch eine Zustandsprüfung ermittelt. Wenn der Backend-Pool mehrere Server enthält, verwendet das Anwendungs-Gateway einen Round-Robin-Algorithmus, um die Anforderungen zwischen gesunden Servern weiterzuleiten. Auf diese Weise wird die Last auf den Servern ausgeglichen.

Nachdem das Anwendungs-Gateway den Backend-Server ermittelt hat, öffnet es auf der Grundlage der HTTP-Einstellungen eine neue TCP-Sitzung mit dem Backend-Server. Die HTTP-Einstellungen geben das Protokoll, den Port und andere Routing-bezogene Einstellungen an, die für den Aufbau einer neuen Sitzung mit dem Backend-Server erforderlich sind.

Der Port und das Protokoll, die in den HTTP-Einstellungen verwendet werden, bestimmen, ob der Datenverkehr zwischen dem Anwendungs-Gateway und den Backend-Servern verschlüsselt (und damit End-to-End-TLS erreicht wird) oder unverschlüsselt ist.

Wenn ein Anwendungs-Gateway die ursprüngliche Anforderung an den Backend-Server sendet, beachtet es alle benutzerdefinierten Konfigurationen, die in den HTTP-Einstellungen in Bezug auf das Überschreiben von Hostname, Pfad und Protokoll vorgenommen wurden. Diese Aktion behält die Cookie-basierte Sitzungsaffinität, den Verbindungsabbau, die Auswahl des Hostnamens vom Backend usw. bei.

Änderungen an der Anfrage

Ein Anwendungsgateway fügt vier zusätzliche Header in alle Anfragen ein, bevor es die Anfragen an das Backend weiterleitet. Diese Header sind x-forwarded-for, x-forwarded-proto, x-forwarded-port und x-original-host. Das Format für die Kopfzeile x-forwarded-for ist eine durch Komma getrennte Liste von IP:Port.

Die gültigen Werte für x-forwarded-proto sind HTTP oder HTTPS. X-forwarded-port gibt den Port an, über den die Anfrage das Anwendungs-Gateway erreicht hat. X-original-host-Header enthält den ursprünglichen Host-Header, mit dem die Anfrage angekommen ist. Dieser Header ist bei der Azure-Website-Integration nützlich, bei der der eingehende Host-Header geändert wird, bevor der Datenverkehr an das Backend weitergeleitet wird. Wenn die Sitzungsaffinität als Option aktiviert ist, wird ein vom Gateway verwaltetes Affinitäts-Cookie hinzugefügt.

Sie können das Application Gateway so konfigurieren, dass es die Anfrage- und Antwort-Header und die URL mithilfe von Rewrite HTTP-Header und URL ändert oder den URI-Pfad mithilfe einer Path-Override-Einstellung ändert. Sofern nicht so konfiguriert, werden jedoch alle eingehenden Anfragen an das Backend weitergeleitet.

Erfahren Sie mehr über die Komponenten des Anwendungs-Gateways