Funktionsweise von Anwendungsgateways
In diesem Artikel wird erläutert, wie Anwendungsgateways eingehende Anforderungen akzeptieren und an das Back-End weiterleiten.
Akzeptieren einer Anforderung durch ein Anwendungsgateway
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. Der DNS-Eintrag wird von Azure gesteuert, da sich alle Anwendungsgateways in der Domäne azure.com befinden.
Der Azure-DNS gibt die IP-Adresse an den Client zurück. Dabei handelt es sich um die Front-End-IP-Adresse des Anwendungsgateways.
Das Anwendungsgateway akzeptiert eingehenden Datenverkehr an einem oder mehreren Listenern. Ein Listener ist eine logische Entität, die auf eingehende Verbindungsanforderungen prüft. Er wird mit einer Front-End-IP-Adresse, einem Protokoll und einer Portnummer für Verbindungen vom Client mit dem Anwendungsgateway konfiguriert.
Wenn eine Web Application Firewall (WAF) verwendet wird, überprüft das Anwendungsgateway die Anforderungsheader und ggf. den -text anhand von WAF-Regeln. Durch diese Aktion wird ermittelt, ob es sich bei der Anforderung um eine gültige Anforderung oder ein Sicherheitsrisiko handelt. Ist es eine gültige Anforderung, wird sie an das Back-End weitergeleitet. Ist es keine gültige Anforderung, und WAF befindet sich im Präventionsmodus, wird sie als Sicherheitsrisiko blockiert. Wenn sie sich im Erkennungsmodus befindet, wird die Anforderung ausgewertet und protokolliert, aber trotzdem an den Back-End-Server weitergeleitet.
Azure Application Gateway kann als interner Lastenausgleich für Anwendungen oder als ein vom Internet zugänglicher Lastenausgleich für Anwendungen verwendet werden. Ein internetseitiges Anwendungsgateway nutzt eine öffentliche IP-Adresse. Der DNS-Name eines internetseitigen Anwendungsgateways kann öffentlich in seine öffentliche IP-Adresse aufgelöst werden. Daher können internetseitige Anwendungsgateways Clientanforderungen aus dem Internet routen.
Interne Anwendungsgateways nutzen nur private IP-Adressen. Wenn Sie eine benutzerdefinierte oder private DNS-Zone verwenden, sollte sich der Domänenname intern in die private IP-Adresse des Anwendungsgateways auflösen lassen. Daher können interne Lastenausgleichsmodule nur Anforderungen von Clients mit Zugriff auf ein virtuelles Netzwerk für das Anwendungsgateway routen.
Routen einer Anforderung durch ein Anwendungsgateway
Wenn eine Anforderung gültig ist und nicht von WAF blockiert wird, wertet das Anwendungsgateway die Anforderungsroutingregel aus, die mit dem Listener verknüpft ist. Durch diese Aktion wird ermittelt, an welchen Back-End-Pool die Anforderung weitergeleitet werden soll.
Auf der Grundlage der Routingregel für Anforderungen entscheidet das Anwendungsgateway, ob alle Anforderungen am Listener an einen bestimmten Back-End-Pool, basierend auf dem URL-Pfad an verschiedene Back-End-Pools oder an Umleitungsanforderungen zu einem anderen Port oder einer externen Website weitergeleitet werden sollen.
Hinweis
Regeln werden in der Reihenfolge verarbeitet, in der sie im Portal für v1-SKU aufgeführt sind.
Nachdem das Anwendungsgateway einen Back-End-Pool ausgewählt hat, sendet es die Anforderung an einen der fehlerfreien Back-End-Server im Pool (y.y.y.y). Die Integrität des Servers wird mithilfe eines Integritätstests überprüft. Wenn der Back-End-Pool mehrere Server enthält, verwendet das Anwendungsgateway einen Roundrobinalgorithmus zum Routen der Anforderungen an die einzelnen fehlerfreien Server. Dadurch wird ein Lastenausgleich für die Anforderungen auf den Servern gebildet.
Nachdem das Anwendungsgateway einen Back-End-Server festgelegt hat, öffnet es eine neue TCP-Sitzung mit dem Back-End-Server anhand der HTTP-Einstellungen. Die HTTP-Einstellungen geben das Protokoll, den Port und andere routingbezogene Einstellungen an, die zum Herstellen einer neuen Sitzung mit dem Back-End-Server erforderlich sind.
Die Angaben für Port und Protokoll in den HTTP-Einstellungen legen fest, ob der Datenverkehr zwischen dem Anwendungsgateway und den Back-End-Servern verschlüsselt wird (sodass End-to-End-TLS erzielt wird) oder unverschlüsselt bleibt.
Wenn ein Anwendungsgateway die ursprüngliche Anforderung an den Back-End-Server sendet, berücksichtigt es etwaige benutzerdefinierte Konfigurationen in den HTTP-Einstellungen, durch die Hostname, Pfad oder Protokoll überschrieben werden. Durch diese Aktion werden die cookiebasierte Sitzungsaffinität, der Verbindungsausgleich, die Auswahl des Hostnamens über das Back-End usw. beibehalten.
Hinweis
Für den Back-End-Pool gilt Folgendes:
- Wenn er ein öffentlicher Endpunkt ist, verwendet das Anwendungsgateway die öffentliche Front-End-IP-Adresse, um den Server zu erreichen. Wenn keine öffentliche Front-End-IP-Adresse vorliegt, wird für die ausgehende externe Konnektivität eine zugewiesen.
- Wenn er einen intern auflösbaren FQDN oder eine private IP-Adresse enthält, routet das Anwendungsgateway die Anforderung über die privaten Instanz-IP-Adressen des Back-End-Servers an diesen.
- Wenn er einen externen Endpunkt oder einen extern auflösbaren FQDN enthält, routet das Anwendungsgateway die Anforderung über die öffentliche Front-End-IP-Adresse des Back-End-Servers an diesen. Wenn das Subnetz Dienstendpunkte enthält, leitet das Anwendungsgateway die Anforderung über die private IP-Adresse an den Dienst weiter. Die DNS-Auflösung basiert auf einer privaten DNS-Zone oder einem benutzerdefinierten DNS-Server (sofern konfiguriert), oder es wird das von Azure bereitgestellte Standard-DNS verwendet. Wenn keine öffentliche Front-End-IP-Adresse vorliegt, wird für die ausgehende externe Konnektivität eine zugewiesen.
DNS-Auflösung des Back-End-Servers
Wenn der Server eines Back-End-Pools mit einem vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) konfiguriert ist, führt das Anwendungsgateway eine DNS-Suche durch, um die IP-Adresse(n) des Domänennamens abzurufen. Der IP-Wert wird im Cache Ihres Anwendungsgateways gespeichert, damit er die Ziele schneller erreichen kann, wenn eingehende Anforderungen verarbeitet werden.
Das Anwendungs-Gateway bewahrt diese zwischengespeicherten Informationen für den Zeitraum auf, der der TTL (time to live) des DNS-Eintrags entspricht, und führt eine neue DNS-Suche durch, sobald die TTL abläuft. Wenn ein Gateway eine Änderung der IP-Adresse für die nachfolgende DNS-Abfrage erkennt, beginnt es, den Datenverkehr an dieses aktualisierte Ziel weiterzuleiten. Bei Problemen wie dem DNS-Nachschlagevorgang, bei dem keine Antwort empfangen wurde oder der Eintrag nicht mehr vorhanden ist, verwendet das Gateway weiterhin die zuletzt bekannte(n) IP-Adresse(n). Dies gewährleistet minimale Auswirkungen auf den Datenpfad.
Wichtig
- Bei der Verwendung von benutzerdefinierten DNS-Servern mit dem virtuellen Netzwerk von Application Gateway ist es wichtig, dass alle Server konsistent mit denselben DNS-Werten antworten. Wenn Ihre Application Gateway-Instanz eine DNS-Abfrage ausgibt, verwendet sie den Wert von dem Server, der zuerst antwortet.
- Benutzerinnen und Benutzer von lokalen benutzerdefinierten DNS-Servern müssen sicherstellen, dass die Verbindung mit Azure DNS über Azure DNS Private Resolver (empfohlen) oder eine DNS-Weiterleitungs-VM bei Verwendung einer privaten DNS-Zone für private Endpunkte sichergestellt wird.
Änderungen an der Anforderung
Das Anwendungsgateway fügt sechs zusätzliche Header in alle Anforderungen ein, bevor es die Anforderungen an das Back-End weiterleitet. Diese Header sind: x-forwarded-for, x-forwarded-port, x-forwarded-proto, x-original-host, x-original-url und x-appgw-trace-id. Das Format für den x-forwarded-for-Header ist eine durch Trennzeichen getrennte Liste mit IP:Port.
Die gültigen Werte für x-forwarded-proto sind HTTP und HTTPS. „x-forwarded-port“ gibt den Port an, an dem die Anforderung das Anwendungsgateway erreicht hat. Der X-original-host-Header enthält den ursprünglichen Hostheader, mit dem die Anforderung eingetroffen ist. Dieser Header ist nützlich bei der Azure-Websiteintegration, bei der der eingehende Hostheader vor dem Routen des Datenverkehrs zum Back-End geändert wird. Wenn Sitzungsaffinität als Option aktiviert ist, wird ein vom Gateway verwaltetes Affinitätscookie eingefügt.
„x-appgw-trace-id“ ist eine eindeutige GUID, die vom Anwendungsgateway für jede Clientanforderung generiert und in der weitergeleiteten Anforderung an das Back-End-Poolmitglied angegeben wird. Die GUID besteht aus 32 alphanumerischen Zeichen, die ohne Bindestriche dargestellt werden (z. B. ac882cd65a2712a0fe1289ec2bb6aee7). Diese GUID kann verwendet werden, um eine Anforderung zu korrelieren, die vom Anwendungsgateway empfangen und für ein Back-End-Poolmitglied über die transactionId-Eigenschaft in Diagnoseprotokollen initiiert wird.
Sie können das Anwendungsgateway so konfigurieren, dass Anforderungs- und Antwortheader sowie die URL durch das erneute Generieren von HTTP-Headern und URLs geändert werden oder der URI-Pfad mithilfe der Einstellung für die Pfadüberschreibung geändert wird. Sofern dies nicht konfiguriert ist, werden jedoch alle eingehenden Anforderungen per Proxy an das Back-End weitergeleitet.