Häufig gestellte Fragen zu Application Gateway

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 des Azure Az PowerShell-Moduls. Informationen zum Migrieren zum Az PowerShell-Modul finden Sie unter Migrieren von Azure PowerShell von AzureRM zum Az-Modul.

Nachfolgend sind häufig gestellte Fragen zu Azure Application Gateway.

Allgemein

Was ist Application Gateway?

Azure Application Gateway stellt einen Anwendungsübermittlungscontroller als Dienst bereit. Er bietet verschiedene Layer-7-Lastenausgleichsfunktionen für Ihre Anwendungen. Dieser Dienst ist hoch verfügbar und skalierbar und wird vollständig von Azure verwaltet.

Welche Funktionen werden von Application Gateway unterstützt?

Application Gateway unterstützt automatische Skalierung, TLS-Abladung und End-to-End-TLS, Web Application Firewall (WAF), cookiebasierte Sitzungsaffinität, Routing auf URL-Pfadbasis, Hosting für mehrere Standorte und vieles mehr. Eine vollständige Liste der unterstützten Funktionen finden Sie unter Einführung in Application Gateway.

Was ist der Unterschied zwischen Application Gateway und Azure Load Balancer?

Application Gateway ist ein Layer-7-Lastenausgleich und somit nur für Webdatenverkehr (HTTP/HTTPS/WebSocket und HTTP/2) geeignet. Er unterstützt Funktionen wie TLS-Terminierung, cookiebasierte Sitzungsaffinität und Roundrobin für den Lastenausgleich von Datenverkehr. Load Balancer nimmt einen Lastausgleich des Datenverkehrs auf Schicht 4 (TCP/UDP) vor.

Welche Protokolle werden von Application Gateway unterstützt?

Application Gateway unterstützt HTTP, HTTPS, HTTP/2 und WebSocket.

Wie unterstützt Application Gateway HTTP/2?

Welche Ressourcen werden als Teil eines Back-End-Pools unterstützt?

In welchen Regionen ist Application Gateway verfügbar?

Application Gateway v1 (Standard und WAF) ist in allen Regionen der globalen Azure-Umgebung verfügbar. Verfügbar ist es auch in Microsoft Azure, betrieben von 21Vianet und Azure Government.

Informationen zur Verfügbarkeit von Application Gateway v2 (Standard_v2 und WAF_v2) finden Sie unter Unterstützte Regionen für Application Gateway v2.

Ist diese Bereitstellung für mein Abonnement dediziert, oder wird sie zur gemeinsamen Nutzung für Kunden freigegeben?

Application Gateway ist eine dedizierte Bereitstellung in Ihrem virtuellen Netzwerk.

Unterstützt Application Gateway HTTP-zu-HTTPS-Umleitung?

Die Umleitung wird unterstützt. Weitere Informationen finden Sie unter Übersicht über die Umleitung in Application Gateway.

In welcher Reihenfolge werden Listener verarbeitet?

Informationen hierzu finden Sie unter Application Gateway – Konfigurationsübersicht.

Wo finde ich IP und DNS von Application Gateway?

Wenn Sie eine öffentliche IP-Adresse als Endpunkt verwenden, finden Sie die Informationen zu IP und DNS in der Ressource der öffentlichen IP-Adresse. Sie können sie auch im Azure-Portal auf der Übersichtsseite für das Anwendungsgateway abrufen. Bei Verwendung von internen IP-Adressen finden Sie die Informationen auf der Übersichtsseite. Für die v1-SKU haben Gateways, die nach dem 1. Mai 2023 erstellt wurden, keinen standardmäßigen DNS-Namen, der der öffentlichen IP-Ressource automatisch zugeordnet ist. Öffnen Sie für die v2-SKU die öffentliche IP-Adresse, und klicken Sie auf Konfiguration. Das Feld DNS-Namenbezeichnung (optional) steht zum Konfigurieren des DNS-Namens zur Verfügung.

Welche Einstellungen werden für das Keep-Alive-Timeout und das TCP-Leerlauftimeout verwendet?

Keep-AliveTimeout steuert, wie lange das Application Gateway wartet, bis ein Client eine andere HTTP-Anforderung über eine persistente Verbindung sendet, bevor diese wiederverwendet oder geschlossen wird. TCP-Leerlauftimeout steuert, wie lange eine TCP-Verbindung bei fehlender Aktivität offengehalten wird.

Der Keep-AliveTimeout beträgt in der Application Gateway v1-SKU 120 Sekunden und in der v2-SKU 75 Sekunden. Bei privaten IP-Adressen kann der Wert mit einem TCP-Leerlauftimeout von 5 Minuten nicht konfiguriert werden. Der TCP-Leerlauftimeout beträgt standardmäßig 4 Minuten für die virtuelle IP (VIP) des Front-Ends von Application Gateway sowohl für die v1- als auch die v2-SKU. Den Wert für das TCP-Leerlauftimeout für die v1- und v2-Application Gateway Instanzen können Sie zwischen 4 und 30 Minuten festlegen. Für v1- und v2-Application Gateway Instanzen müssen Sie zur öffentlichen IP-Adresse des Anwendungsgateways navigieren und das TCP-Leerlauftimeout im Bereich Konfiguration der öffentlichen IP-Adresse im Portal ändern. Sie können den Wert für das TCP-Leerlauftimeout der öffentlichen IP-Adresse über PowerShell festlegen, indem Sie folgende Befehle ausführen:

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

Bei HTTP/2-Verbindungen mit der Front-End-IP-Adresse mit der Application Gateway v2-SKU wird das Leerlauftimeout auf 180 Sekunden festgelegt und ist nicht konfigurierbar.

Verwendet das Application Gateway die TCP-Verbindung wieder, die mit einem Back-End-Server eingerichtet wurde?

Ja. Das Application Gateway verwendet die vorhandenen TCP-Verbindungen mit einem Back-End-Server.

Kann ich meine Application Gateway-Ressource umbenennen?

Nein Es gibt keine Möglichkeit zum Umbenennen einer Application Gateway-Ressource. Sie müssen eine neue Ressource mit einem anderen Namen erstellen.

Gibt es eine Möglichkeit zum Wiederherstellen einer Application Gateway Ressource und seiner öffentlichen IP-Adresse, wenn es gelöscht wurde?

Nein Es gibt keine Möglichkeit zum Wiederherstellen einer Application Gateway-Ressource oder ihrer öffentlichen IP-Adresse nach dem Löschen. Sie müssen eine neue Ressource erstellen.

Ändert sich die IP-Adresse oder der DNS-Name während der Lebensdauer des Anwendungsgateways?

In der Application Gateway v1 SKU kann sich die VIP ändern, wenn Sie das Anwendungsgateway beenden und dann erneut starten. Der zugeordnete DNS-Name des Anwendungsgateways ändert sich während der Lebensdauer des Gateways nicht. Daher wird empfohlen, einen CNAME-Alias zu verwenden und damit auf die DNS-Adresse des Anwendungsgateways zu verweisen. Bei der Application Gateway v2 SKU sind die IP-Adressen statisch, sodass sich die IP-Adresse und der DNS-Name während der Lebensdauer des Anwendungsgateways nicht ändern.

Unterstützt Application Gateway statische IP-Adressen?

Ja. Die Application Gateway v2 SKU unterstützt statische öffentliche IP-Adressen sowie statische interne IP-Adressen. Die v1-SKU unterstützt statische interne IP-Adressen.

Unterstützt Application Gateway mehrere öffentliche IP-Adressen auf dem Gateway?

Ein Anwendungsgateway unterstützt nur eine öffentliche IP-Adresse pro IP-Protokoll. Wenn das Anwendungsgateway als DualStack konfiguriert ist, kann es zwei öffentliche IPs unterstützen, eine für IPv4 und eine für IPv6.

Wie groß soll ich mein Subnetz für Application Gateway auslegen?

Kann ich mehrere Application Gateway-Ressourcen in einem einzelnen Subnetz bereitstellen?

Ja. Sie können nicht nur mehrere Instanzen einer bestimmten Application Gateway-Bereitstellung besitzen, sondern auch eine weitere eindeutige Application Gateway-Ressource zu einem vorhandenen Subnetz hinzufügen, das eine andere Application Gateway-Ressource enthält.

Ein einzelnes Subnetz kann nicht gleichzeitig v2- und v1-SKUs für Application Gateway unterstützen.

Unterstützt Application Gateway v2 benutzerdefinierte Routen?

Ja, aber nur für spezifische Szenarios. Weitere Informationen finden Sie unter Konfiguration der Application Gateway-Infrastruktur.

Werden X-Forwarded-For-Header von Application Gateway unterstützt?

Ja. Entsprechende Informationen finden Sie unter Funktionsweise von Application Gateway.

Wie lange dauert das Bereitstellen einer Application Gateway-Instanz? Funktioniert das Anwendungsgateway während einer Aktualisierung?

Die Ausführung neuer Bereitstellungen der Application Gateway v1-SKU kann bis zu 20 Minuten dauern. Beim Vornehmen von Änderungen der Instanzgröße oder -anzahl wird der Betrieb nicht unterbrochen, und das Gateway bleibt währenddessen aktiv.

Die Bereitstellung von Instanzen mit der v2-SKU dauert in der Regel etwa sechs Minuten. Je nach Bereitstellungsart kann sie jedoch mehr Zeit beanspruchen. Bereitstellungen, die sich über mehrere Verfügbarkeitszonen erstrecken und viele Instanzen umfassen, können beispielsweise länger als 6 Minuten dauern.

Wie behandelt Application Gateway routinemäßige Wartungen?

Updates, die fürs Application Gateway eingeleitet werden, werden jeweils auf eine Updatedomäne angewendet. Wenn die Instanzen jeder Updatedomäne aktualisiert werden, dienen die verbleibenden Instanzen in anderen Updatedomänen weiterhin dem Datenverkehr 1 . Aktive Verbindungen werden ordnungsgemäß aus den Instanzen entfernt, die bis zu fünf Minuten lang aktualisiert werden, um die Konnektivität mit Instanzen in einer anderen Updatedomäne herzustellen, bevor das Update beginnt. Während des Updates wird Application Gateway vorübergehend mit reduzierter maximaler Kapazität ausgeführt. Diese wird durch die Anzahl der konfigurierten Instanzen bestimmt. Der Updatevorgang fährt nur dann mit dem nächsten Satz von Instanzen fort, wenn der aktuelle Satz von Instanzen erfolgreich aktualisiert wurde.

1 Wir empfehlen, eine Mindestinstanzenzahl von 2 für SKU-Bereitstellungen des Anwendungsgateways v1 zu konfigurieren, um sicherzustellen, dass während der Updates-Anwendung mindestens eine Instanz den Datenverkehr bedienen kann.

Kann ich Exchange Server als Back-End mit Application Gateway verwenden?

Das Anwendungsgateway unterstützt TLS/TCP-Protokollproxy über seinen Layer 4-Proxy in Vorschau.

Der Layer 7-Proxy des Anwendungsgateways mit HTTP(S)-Protokollen unterstützt keine E-Mail-Protokolle wie SMTP, IMAP und POP3. Für einige unterstützende E-Mail-Dienste wie Outlook Web Access (OWA), ActiveSync und AutoDiscovery-Datenverkehr, der HTTP(S)-Protokolle verwendet, können Sie jedoch Layer 7-Proxy verwenden und deren Datenverkehr sollte ablaufen. (Hinweis: Ausschlüsse in den WAF-Regeln sind möglicherweise erforderlich, wenn sie eine WAF-SKU verwenden).

Gibt es Richtlinien für die Migration von der v1-SKU zur v2-SKU?

Wird das Application Gateway v1 SKU unterstützt?

Ja. Die Application Gateway v1 SKU wird weiterhin unterstützt. Es wird von uns dringend empfohlen, zu v2 zu wechseln, um die Funktionsupdates in dieser SKU zu nutzen. Weitere Informationen über die Unterschiede zwischen v1- und v2-Funktionen finden Sie unter Automatische Skalierung und zonen-redundantes Application Gateway v2. Sie können die Bereitstellungen von Application Gateway v1 SKU manuell zu v2 migrieren, indem Sie unserem v1-v2-Migrationsdokument folgen.

Unterstützt Application Gateway v2 Proxyanforderungen mit NTLM- oder Kerberos-Authentifizierung?

Nein Application Gateway v2 unterstützt keine Proxyanforderungen mit NTLM- oder Kerberos-Authentifizierung.

Warum sind einige Headerwerte nicht vorhanden, wenn Anforderungen an meine Anwendung weitergeleitet werden?

Anforderungsheadernamen können alphanumerische Zeichen und Bindestriche enthalten. Anforderungsheadernamen, die andere Zeichen enthalten, werden verworfen, wenn eine Anforderung an das Back-End-Ziel gesendet wird. Wie in RFC 7230 festgelegt, können Antwort-Headernamen beliebige alphanumerischen Zeichen und Sonderzeichen beinhalten.

Unterstützt das Affinitätscookie von Application Gateway das SameSite-Attribut?

Ja. Mit dem Chromium-Browserv80-Update wurde ein Mandat für HTTP-Cookies ohne SameSite-Attribut eingeführt, das als SameSite=Lax behandelt wird. Das bedeutet, dass das Affinitätscookie von Application Gateway nicht vom Browser in einem Drittanbieterkontext gesendet wird.

Um dieses Szenario zu unterstützen, fügt Application Gateway zusätzlich zum vorhandenen ApplicationGatewayAffinity Cookie ein weiteres Cookie ein, das aufgerufen wird ApplicationGatewayAffinityCORS. Diese Cookies sind ähnlich, aber das ApplicationGatewayAffinityCORS Cookie hat zwei weitere Attribute hinzugefügt: SameSite=None und Secure. Diese Attribute behalten persistente Sitzungen selbst bei quellenübergreifenden Anforderungen bei. Weitere Informationen finden Sie im Abschnitt zur cookiebasierten Affinität.

Was gilt als aktiver und was als inaktiver Listener?

Ein aktiver Listener ist ein Listener, der einer Regel zugeordnet ist und Datenverkehr an einen Back-End-Pool sendet. Jeder Listener, der Datenverkehr nur umleitet, ist kein aktiver Listener. Listener, die Umleitungsregeln zugeordnet sind, werden nicht als aktiv betrachtet. Wenn es sich bei der Umleitungsregel um eine pfadbasierte Regel handelt, müssen alle Pfade in dieser Umleitungsregel den Datenverkehr umleiten, andernfalls gilt der Listener als aktiv. Informationen zu Grenzwertdetails für einzelne Komponenten finden Sie unter Grenzwerte, Kontingente und Einschränkungen für Azure-Abonnements und -Dienste.

Leistung

Wie unterstützt Application Gateway Hochverfügbarkeit und Skalierbarkeit?

Die Application Gateway v1-SKU unterstützt Szenarien mit Hochverfügbarkeit, wenn zwei oder mehr Instanzen bereitgestellt wurden. Azure verteilt diese Instanzen auf Update- und Fehlerdomänen, um sicherzustellen, dass nicht alle Instanzen gleichzeitig ausfallen. Die v1-SKU unterstützt Skalierbarkeit durch Hinzufügen mehrerer Instanzen des gleichen Gateways, um die Last zu teilen.

Die v2-SKU stellt automatisch sicher, dass neue Instanzen über Fehlerdomänen und Updatedomänen hinweg verteilt werden. Haben Sie Zonenredundanz gewählt, werden die neuesten Instanzen darüber hinaus über Verfügbarkeitszonen hinweg verteilt, um Resilienz gegen Zonenausfälle zu erreichen.

Wie erziele ich mit Application Gateway ein rechenzentrumsübergreifendes Szenario der Notfallwiederherstellung?

Verteilen Sie Datenverkehr mithilfe von Azure Traffic Manager auf mehrere Anwendungsgateways in verschiedenen Rechenzentren.

Unterstützt Application Gateway den Verbindungsausgleich?

Ja. Sie können den Verbindungsausgleich einrichten, um die Mitglieder in einem Back-End-Pool ohne Unterbrechung zu ändern. Weitere Informationen finden Sie unter Application Gateway im Abschnitt „Verbindungsausgleich“.

Unterstützt Application Gateway automatische Skalierung?

Ja, die Application Gateway v2-SKU unterstützt automatische Skalierung. Weitere Informationen finden Sie unter Automatische Skalierung und zonenredundantes Application Gateway.

Werden durch das manuelle oder automatische Hoch- oder Herunterskalieren Ausfallzeiten verursacht?

Nein Instanzen sind auf Upgrade- und Fehlerdomänen verteilt.

Kann ich ohne Unterbrechung von der Standard zu WAF SKU wechseln?

Ja.

Kann ich Instanzgröße ohne Unterbrechung von mittel zu groß ändern?

Ja.

Konfiguration

Wird Application Gateway immer in einem virtuellen Netzwerk bereitgestellt?

Ja. Application Gateway wird immer in einem Subnetz des virtuellen Netzwerks bereitgestellt. Dieses Subnetz kann nur Anwendungsgateways enthalten. Weitere Informationen finden Sie unter Virtuelles Netzwerk und Subnetz-Anforderungen.

Kann Application Gateway mit Instanzen außerhalb des eigenen virtuellen Netzwerks oder des eigenen Abonnements kommunizieren?

Application Gateway kann mit Instanzen außerhalb des eigenen virtuellen Netzwerks kommunizieren, wenn Sie eine IP-Verbindung haben. Application Gateway kann auch mit Instanzen außerhalb des eigenen Abonnements kommunizieren. Wenn Sie die Verwendung interner IP-Adressen als Back-End-Pool-Mitglieder planen, ist ein Peering virtueller Netzwerke oder Azure VPN Gateway erforderlich.

Wie wird die IP-Adresse für einen FQDN-basierten Back-End-Server aktualisiert?

Wie jeder DNS-Resolver berücksichtigt die Application Gateway-Ressource den Time to Live (TTL)-Wert des DNS-Eintrags des Back-End-Servers. Nach Ablauf der TTL führt das Gateway einen Nachschlagevorgang durch, um diese DNS-Informationen zu aktualisieren. Tritt während dieses Vorgangs ein Problem beim Abrufen einer Antwort auf (oder wird kein DNS-Eintrag gefunden), verwendet das Gateway weiterhin den zuletzt bekannten guten DNS-Wert, um den Datenverkehr zu bedienen. Weitere Informationen finden Sie unter Funktionsweise von Application Gateway.

Warum sehe ich 502-Fehler oder fehlerhafte Back-End-Server, nachdem ich die DNS-Server für das virtuelle Netzwerk geändert habe?

Die Instanzen Ihres Anwendungsgateways verwenden die DNS-Konfiguration des virtuellen Netzwerks für die Namensauflösung. Nachdem Sie eine DNS-Serverkonfiguration geändert haben, müssen Sie das Anwendungsgateway für die neuen DNS-Server neu starten (Beenden und Starten), damit sie zugewiesen werden. Bis dahin können die FQDN-basierte Namensauflösungen für ausgehende Verbindungen fehlschlagen.

Kann ich im Application Gateway-Subnetz noch etwas anderes bereitstellen?

Nein Aber Sie können weitere Application Gateway-Instanzen im Subnetz bereitstellen.

Kann ich das virtuelle Netzwerk oder das Subnetz für ein vorhandenes Application Gateway ändern?

Sie können ein Application Gateway nur zwischen Subnetzen verschieben, die sich innerhalb desselben virtuellen Netzwerks befinden. Es wird bei v1 mit öffentlichem und privatem Front-End (dynamische Zuteilung) und bei v2 nur mit öffentlichem Front-End unterstützt. Das Anwendungsgateway kann nicht in ein anderes Subnetz verschoben werden, wenn die private Front-End-IP-Konfiguration statisch zugewiesen wird. Um diese Aktion auszuführen, muss das Application Gateway im Zustand Beendet sein. Das Beenden oder Starten von v1 ändert die öffentliche IP. Dieser Vorgang kann nur mit Azure PowerShell und Azure CLI durchgeführt werden, indem Sie die folgenden Befehle ausführen:

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

Weitere Informationen finden Sie unter Set-AzApplicationGatewayIPConfiguration.

Azure-Befehlszeilenschnittstelle

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

Werden Netzwerksicherheitsgruppen im Application Gateway-Subnetz unterstützt?

Unterstützt das Application Gateway-Subnetz benutzerdefinierte Routen?

Werden Dienstendpunktrichtlinien im Application Gateway-Subnetz unterstützt?

Nein Dienstendpunktrichtlinien für Speicherkonten werden im Application Gateway-Subnetz nicht unterstützt, und durch die Konfiguration solcher Richtlinien wird der Azure-Infrastrukturdatenverkehr blockiert.

Was sind die Grenzwerte für Application Gateway? Kann ich diese Grenzwerte erhöhen?

Kann ich Application Gateway gleichzeitig für externen und internen Datenverkehr verwenden?

Ja. Application Gateway unterstützt pro Instanz eine interne und eine externe IP-Adresse.

Unterstützt Application Gateway das Peering virtueller Netzwerke?

Ja. Das Peering virtueller Netzwerke ermöglicht den Lastenausgleich von Datenverkehr in anderen virtuellen Netzwerken.

Kann ich mit lokalen Servern kommunizieren, wenn sie über Azure ExpressRoute- oder VPN-Tunnel verbunden sind?

Ja, sofern Datenverkehr zugelassen wird.

Kann ein Back-End-Pool für das Bereitstellen mehrerer Anwendungen an unterschiedlichen Ports verwendet werden?

Microservice-Architektur wird unterstützt. Für das Testen an unterschiedlichen Ports müssen Sie mehrere Back-End-Einstellungen konfigurieren.

Unterstützen benutzerdefinierte Tests Platzhalter oder reguläre Ausdrücke in Antwortdaten?

Nein

Wie werden Routingregeln in Application Gateway verarbeitet?

Was ist im Feld **Host** für benutzerdefinierte Überprüfungen angegeben?

Wenn Sie mehrere Standorte für Application Gateway konfiguriert haben, wird im Feld Host der Name angegeben, an den der Test gesendet werden soll. Verwenden Sie andernfalls 127.0.0.1. Dieser Wert entspricht nicht dem Hostnamen des virtuellen Computers. Sein Format ist <Protokoll>://<Host>:<Port><Pfad>.

Kann ich nur einigen wenigen Quell-IP-Adressen Zugriff auf Application Gateway gewähren?

Kann ich den gleichen Port sowohl für öffentliche als auch für private Listener verwenden?

Ja, Sie können öffentlich zugängliche und private Listener mit der gleichen Portnummer verwenden, um öffentliche und private Clients gleichzeitig zu unterstützen. Wenn eine Netzwerksicherheitsgruppe (Network Security Group, NSG) dem Subnetz Ihres Anwendungsgateways zugeordnet ist, kann je nach Konfiguration eine bestimmte eingehende Regel erforderlich sein. Weitere Informationen.

Unterstützt Application Gateway IPv6?

Anwendungsgateway v2 unterstützt IPv4- und IPv6-Frontends. Derzeit ist die IPv6-Unterstützung nur für neue Anwendungsgateways verfügbar. Um IPv6 zu unterstützen, sollte das virtuelle Netzwerk ein dualer Stapel sein. Application Gateway v1 unterstützt keine virtuellen Netzwerke mit dualem Stapel.

Unterstützt Application Gateway FIPS?

Anwendungsgateway v1 SKUs können in einem genehmigten FIPS 140-2-Betriebsmodus ausgeführt werden, der häufig als "FIPS-Modus" bezeichnet wird. Der FIPS-Modus ruft ein FIPS 140-2-validiertes kryptografisches Modul auf, das FIPS-kompatible Algorithmen für Verschlüsselung, Hashing und Signierung sicherstellt, wenn diese aktiviert sind. Um sicherzustellen, dass der FIPS-Modus aktiviert ist, muss die FIPSMode Einstellung über PowerShell, Azure Resource Manager-Vorlage oder REST-API konfiguriert werden, nachdem das Abonnement zur Konfigurationsaktivierung registriert wurdeFIPSmode.

Wie verwende ich Application Gateway v2 mit einer rein privaten Front-End-IP-Adresse?

Application Gateway v2 unterstützt derzeit nur private IP-Frontend-Konfiguration (keine öffentliche IP) über die öffentliche Vorschau. Weitere Informationen finden Sie unter Bereitstellung eines privaten Anwendungsgateways (Vorschau).

Für die aktuelle allgemeine Verfügbarkeitsunterstützung unterstützt Application Gateway v2 folgende Kombinationen:

  • Private und öffentliche IP-Adresse
  • Nur öffentliche IP-Adresse

Gehen Sie wie folgt vor, um den Datenverkehr nur auf private IP-Adressen mit aktueller Funktionalität einzuschränken:

  1. Erstellen Sie eine Application Gateway-Instanz sowohl mit öffentlicher als auch privater Front-End-IP-Adresse.

  2. Erstellen Sie keine Listener für die öffentliche Front-End-IP-Adresse. Application Gateway lauscht nicht über die öffentliche IP-Adresse auf Datenverkehr, wenn dafür keine Listener erstellt wurden.

  3. Erstellen Sie für das Application Gateway-Subnetz eine Netzwerksicherheitsgruppe mit der folgenden Konfiguration in der Reihenfolge der Priorität:

    1. Ermöglichen Sie den Datenverkehr von der Quelle als GatewayManager-Diensttag, das Ziel als Beliebig und den Zielport als 65200-65535. Dieser Portbereich ist für die Kommunikation mit der Azure-Infrastruktur erforderlich. Diese Ports werden von der Zertifikatauthentifizierung geschützt (gesperrt). Externe Entitäten einschließlich der Gatewaybenutzeradministratoren können ohne entsprechende Zertifikate keine Änderungen an diesen Endpunkten vornehmen.

    2. Ermöglichen Sie den Datenverkehr von der Quelle als Dienst-Tag AzureLoadBalancer und das Ziel Port als Beliebig.

    3. Lehnen Sie den gesamten eingehenden Datenverkehr von Quelleals Dienst-Tag Internet und das ZielPortals Beliebig . Weisen Sie dieser Regel die geringste Priorität in den Eingangsregeln zu.

    4. Behalten Sie die Standardregeln wie AllowVNetInBound bei, sodass der Zugriff auf eine private IP-Adresse nicht blockiert wird.

    5. Die ausgehende Internetverbindung kann nicht blockiert sein. Andernfalls treten Probleme mit der Protokollierung und Metrik auf.

Beispiel-NSG-Konfiguration für den Zugriff nur auf private IP-Adressen: Application Gateway v2-NSG-Konfiguration für den ausschließlichen Zugriff auf private IP-Adressen

Wie kann ich das Application Gateway anhalten?

Sie können die Azure PowerShell oder die Azure CLI verwenden, um das Application Gateway zu starten. Wenn Sie die Application Gateway starten, wird die Abrechnung ebenfalls beendet und gestartet. Jeder PUT-Vorgang, der auf einem angehaltenen Anwendungsgateway (z. B. Hinzufügen von Tag, Integritätssonde oder Listener) ausgeführt wird, löst einen Start aus. Es wird empfohlen, das Anwendungsgateway nach der Aktualisierung der Konfiguration anzuhalten.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway       
# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway           
# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway
# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

Konfiguration: TLS

Welche Zertifikate werden von Application Gateway unterstützt?

Application Gateway unterstützt selbstsignierte Zertifikate, Zertifizierungsstellenzertifikate (CA), Zertifikate für die erweiterte Validierung (EV), Zertifikate mit mehreren Domänen (SAN) und Platzhalterzertifikate.

Welche Verschlüsselungssammlungen werden von Application Gateway unterstützt?

Application Gateway unterstützt folgende Verschlüsselungssammlungen:

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
  • TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
  • TLS_DHE_DSS_WITH_AES_256_CBC_SHA
  • TLS_DHE_DSS_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA
  • TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Informationen zum Anpassen von TLS-Optionen finden Sie unter Konfigurieren von TLS-Richtlinienversionen und Verschlüsselungssammlungen für Application Gateway.

Unterstützt Application Gateway eine erneute Verschlüsselung des Datenverkehrs an das Back-End?

Ja. Application Gateway unterstützt TLS-Abladung sowie End-to-End-TLS, das den Datenverkehr an das Back-End erneut verschlüsselt.

Kann ich die TLS-Richtlinie konfigurieren, um TLS-Protokollversionen zu steuern?

Ja. Sie können Application Gateway zum Abweisen von TLS1.0, TLS1.1 und TLS1.2 konfigurieren. Standardmäßig sind SSL 2.0 und 3.0 bereits deaktiviert und nicht konfigurierbar.

Kann ich Verschlüsselungssammlungen und die Richtlinienreihenfolge konfigurieren?

Ja. In Application Gateway können Sie Verschlüsselungssammlungen konfigurieren. Aktivieren Sie zum Definieren einer benutzerdefinierten Richtlinie mindestens eine der folgenden Verschlüsselungssammlungen:

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256

Application Gateway verwendet SHA256 für die Back-End-Verwaltung.

Wie viele TLS-/SSL-Zertifikate werden von Application Gateway unterstützt?

Application Gateway unterstützt bis zu 100 TLS-/SSL-Zertifikate.

Unterstützt Application Gateway OCSP und OCSP-Anheftung?

Ja, Application Gateway unterstützt Zertifikate mit OCSP-Erweiterungen und OCSP-Anheftung für Serverzertifikate.

Wie viele Authentifizierungszertifikate für die erneute Back-End-Verschlüsselung werden von Application Gateway unterstützt?

Application Gateway unterstützt bis zu 100 Authentifizierungszertifikate.

Lässt sich Application Gateway nativ in Azure Key Vault integrieren?

Ja, die Application Gateway v2-SKU unterstützt Key Vault. Weitere Informationen finden Sie unter TLS-Terminierung mit Key Vault-Zertifikaten.

Wie konfiguriere ich HTTPS-Listener für Websites vom Typ „.com“ und „.net“?

Für das Routing auf der Grundlage mehrerer Domänen (hostbasiertes Routing) können Sie Listener für mehrere Standorte erstellen, Listener einrichten, die als Protokoll HTTPS verwenden, und die Listener mit den Routingregeln verknüpfen. Weitere Informationen finden Sie unter Anwendungsgateways – Hosten mehrerer Websites.

Darf ich Sonderzeichen im PFX-Dateikennwort verwenden?

Nein Nein, verwenden Sie nur alphanumerische Zeichen in Ihrem PFX-Dateikennwort.

Mein EV-Zertifikat wird von DigiCert ausgestellt, und mein Zwischenzertifikat wurde widerrufen. Wie erneuere ich mein Zertifikat in Application Gateway?

Zertifizierungsstellen-Browsermitglieder haben kürzlich Berichte veröffentlicht, wo mehrere von Zertifizierungsstellenanbietern ausgestellte Zertifikate beschrieben sind, die von unseren Kunden, Microsoft und der größeren Technologiecommunity verwendet werden, aber den Industriestandards für öffentlich vertrauenswürdige Zertifizierungsstellen nicht entsprechen. Die Berichte über die nicht konformen Zertifizierungsstellen (Certification Authorities, CAs) finden Sie unter den folgenden Links:

Gemäß den Complianceanforderungen der Branche haben Zertifizierungsstellenanbieter damit begonnen, nicht konforme Zertifikate zu widerrufen und konforme Zertifikate auszustellen. Dies erfordert, dass die Zertifikate der Kundschaft neu ausgestellt werden. Microsoft arbeitet mit diesen Anbietern eng zusammen, um die potenziellen Auswirkungen auf Azure-Dienste zu minimieren. Allerdings besteht bei Ihren selbst ausgestellten Zertifikaten oder jenen, die in BYOC-Szenarien (Bring Your Own Certificate) verwendet werden, weiterhin das Risiko, dass sie unerwartet widerrufenwerden können.

Wenn Sie überprüfen möchten, ob in Ihrer Anwendung verwendete Zertifikate widerrufen wurden, sehen Sie sich die Ankündigung von DigiCert und den Zertifikatsperrungs-Tracker an. Wurden oder werden Ihre Zertifikate widerrufen, müssen Sie neue Zertifikate von dem für Ihre Anwendungen verwendeten Zertifizierungsstellenanbieter anfordern. Um zu verhindern, dass die Verfügbarkeit Ihrer Anwendung unterbrochen wird, weil Zertifikate unerwartet widerrufen wurden, oder ein widerrufenes Zertifikat zu aktualisieren, siehe Widerruf nicht kompatibler Zertifizierungsstellen und deren potenziellen Auswirkungen auf die Azure-Dienste beim Kunden.

Für das Application Gateway spezifische Informationen:

Wenn Sie ein Zertifikat verwenden, das von einem der widerrufenen ICAs ausgestellt wurde, wird die Verfügbarkeit Ihrer Anwendung möglicherweise unterbrochen. Abhängig von Ihrer Anwendung erhalten Sie möglicherweise verschiedene Fehlermeldungen, einschließlich der folgenden:

  • Ungültiges Zertifikat/Widerrufenes Zertifikat
  • Timeout bei Verbindung
  • HTTP 502

Um Beeinträchtigungen Ihrer Anwendung aufgrund dieses Problems zu vermeiden oder ein von einer Zertifizierungsstelle widerrufenes Zertifikat erneut ausstellen zu lassen, müssen Sie die folgenden Aktionen ausführen:

  1. Wenden Sie sich an Ihren Zertifikatanbieter, damit Ihre Zertifikate erneut ausgestellt werden.
  2. Aktualisieren Sie Ihre erneut ausgestellten Zertifikate in Application Gateway/WAF mit der vollständigen Vertrauenskette (untergeordnetes Zertifikat, Zwischenzertifikat und Stammzertifikat). Je nach Verwendungsort Ihres Zertifikats führen Sie zur Aktualisierung der Zertifikate entweder auf dem Listener oder in den HTTP-Einstellungen des Anwendungsgateways die nachfolgende Schritte aus. Weitere Informationen finden Sie unter den erwähnten Dokumentationslinks.
  3. Aktualisieren Sie Ihre Back-End-Anwendungsserver so, dass sie das erneut ausgestellte Zertifikat verwenden. Die Schritte zum Aktualisieren des Zertifikats können abhängig vom jeweils verwendeten Back-End-Server variieren. Schauen Sie in der Dokumentation Ihres Herstellers nach.

Gehen Sie wie folgt vor, um das Zertifikat in Ihrem Listener zu aktualisieren:

  1. Öffnen Sie im Azure-Portal Ihre Application Gateway-Ressource.
  2. Öffnen Sie die Listenereinstellungen, die Ihrem Zertifikat zugeordnet sind.
  3. Wählen Sie Ausgewähltes Zertifikat erneuern oder bearbeiten.
  4. Laden Sie Ihr neues PFX-Zertifikat mit dem Kennwort hoch, und klicken Sie auf Speichern.
  5. Greifen Sie auf die Website zu, und überprüfen Sie, ob die Website erwartungsgemäß funktioniert. Weitere Informationen finden Sie unter Verlängern von Application Gateway-Zertifikaten.

Wenn Sie in Ihrem Application Gateway-Listener auf Zertifikate aus Key Vault verweisen, empfehlen wir für eine schnelle Änderung wie folgt verfahren:

  1. Wechseln Sie im Azure-Portalzu Ihren Key Vault-Einstellungen, die dem Anwendungsgateway zugeordnet sind.
  2. Fügen Sie das neu ausgestellte Zertifikat zu Ihrem Speicher hinzu oder importieren Sie es. Weitere Informationen finden Sie unter Schnellstart: Erstellen eines Schlüsseltresors mithilfe des Azure-Portals.
  3. Gehen Sie nach dem Importieren des Zertifikats zu Ihren Application Gateway-Listenereinstellungen, und klicken Sie unter Zertifikat aus Key Vault auswählen auf die Dropdownliste Zertifikat, und wählen Sie das zuletzt hinzugefügte Zertifikat aus.
  4. Wählen Sie Speichern. Weitere Informationen zum TLS-Abschluss in Application Gateway mit Key Vault-Zertifikaten finden Sie unter TLS-Abschluss mit Key Vault-Zertifikaten.

Gehen Sie wie folgt vor, um das Zertifikat in Ihren HTTP-Einstellungen zu aktualisieren:

Wenn Sie die v1 SKU des Application Gateway-/WAF-Diensts verwenden, müssen Sie das neue Zertifikat als Back-End-Authentifizierungszertifikat hochladen.

  1. Öffnen Sie im Azure-Portal Ihre Application Gateway-Ressource.
  2. Öffnen Sie die HTTP-Einstellungen, die Ihrem Zertifikat zugeordnet sind.
  3. Wählen Sie Zertifikat hinzufügen, laden Sie das neu ausgegebene Zertifikat hoch, und wählen Sie Speichern aus.
  4. Sie können das alte Zertifikat später entfernen, indem Sie die Schaltfläche mit ...-Optionen neben dem alten Zertifikat auswählen. Wählen Sie Löschen und dann Speichern. Weitere Informationen finden Sie unter Konfigurieren von End-to-End-TLS mit Application Gateway im Azure-Portal.

Wenn Sie die V2-SKU des Application Gateway-/WAF-Diensts verwenden, müssen Sie das neue Zertifikat nicht in den HTTP-Einstellungen hochladen, da die V2-SKU „vertrauenswürdige Stammzertifikate“ verwendet und an dieser Stelle keine Aktion erforderlich ist.

Konfiguration: TLS/TCP-Proxy

Verwenden Layer 7 und Layer 4 von Application Gateway dieselben Front-End-IP-Adressen?

Ja. Sowohl Layer 7- als auch Layer 4-Routing über das Anwendungsgateway verwenden dieselbe Front-End-IP-Konfiguration. Auf diese Weise können Sie alle Ihre Clients an eine einzelne IP-Adresse (öffentlich oder privat) weiterleiten, und die gleiche Gatewayressource leitet sie basierend auf den konfigurierten Listenerprotokollen und Ports weiter.

Kann ich einen TCP- oder TLS-Proxy für HTTP(S)-Datenverkehr verwenden?

Obwohl der HTTP(S)-Datenverkehr auch über L4-Proxyprotokolle bereitgestellt werden kann, empfehlen wir dies nicht. Die L7-Proxylösung von Application Gateway bietet eine bessere Kontrolle und Sicherheit für die HTTP(S)-Protokolle durch erweiterte Features wie Umschreibungen, Sitzungsaffinität, Umleitung, WebSockets, WAF und mehr.

Was sind die Eigenschaftennamen für Layer 4-Proxys?

Die Ressourceneigenschaften für Layer 4-Features unterscheiden sich von den Layer 7-Features. Entsprechend müssen Sie bei Verwendung der REST-API oder CLI die folgenden Eigenschaften verwenden.

Eigenschaft Zweck
listener Für TLS- oder TCP-basierte Listener
routingRule Hiermit ordnen Sie einen Layer 4-Listener einer Back-End-Einstellung in Layer 4 zu
backendSettingsCollection Für TLS- oder TCP-basierte Back-End-Einstellungen

Hinweis

Sie können keine Layer 4-Eigenschaften für HTTP- oder HTTPS-Protokolleinstellungen verwenden.

Kann ich einen TCP/TLS-Protokolllistener einer HTTP(S)-Protokoll-Back-End-Einstellung zuordnen?

Nein Es sind keine Querverbindungen zwischen Layer 4- und Layer 7-Eigenschaften möglich. Daher können Sie mit einer Routingregel nur einen Listener vom Typ „Layer 4“ mit einer Back-End-Einstellung vom Typ „Layer 4“ verknüpfen.

Können L7- und L4-Eigenschaften dieselben Namen haben?

Sie können nicht denselben Namen für L7 (httpListeners) und L4 (listeners) verwenden. Dies gilt auch für andere L4-Eigenschaften wie backendSettingsCollection und routingRules.

Kann ich einen privaten Endpunkt zu einem Back-End-Pool hinzufügen, wenn ich Layer 4 (TCP- oder TLS-Protokoll) verwende?

Absolut. Ähnlich wie beim Layer 7-Proxy können Sie dem Back-End-Pool Ihres Anwendungsgateways einen privaten Endpunkt hinzufügen. Dieser private Endpunkt muss in einem angrenzenden Subnetz desselben virtuellen Netzwerks Ihres Anwendungsgateways bereitgestellt werden.

Verwendet Application Gateway eine Keepalive-Verbindung für Back-End-Server?

Keepalive wird nicht für Back-End-Verbindungen verwendet. Für jede eingehende Anforderung in der Front-End-Listenerverbindung initiiert Application Gateway eine neue Back-End-Verbindung, um diese Anforderung zu erfüllen.

Welche IP-Adresse sieht der Back-End-Server, wenn eine Verbindung mit Application Gateway hergestellt wird?

Der Back-End-Server sieht die IP-Adresse des Anwendungsgateways. Derzeit wird die sogenannte Client-IP-Beibehaltung nicht unterstützt, über die die Back-End-Anwendung über die IP-Adresse des ursprünglichen Clients informiert werden kann.

Wie kann ich die SSL-Richtlinie für TLS-Listener festlegen?

Die gleiche SSL-Richtlinienkonfiguration gilt sowohl für Layer 7 (HTTPS) als auch für Layer 4 (TLS). Derzeit unterstützen wir keine SSL-Profile (listenerspezifische SSL-Richtlinie oder gegenseitige Authentifizierung) für TLS-Listener.

Unterstützt Application Gateway Sitzungsaffinität für das Layer 4-Routing?

Nein Das Weiterleiten eines Clients an denselben Back-End-Server wird derzeit nicht unterstützt. Die Verbindungen werden nach dem Roundrobin-Verfahren an die Server in einem Back-End-Pool verteilt.

Funktioniert das Feature für die automatische Skalierung mit einem Layer 4-Proxy?

Ja, das Feature für die automatische Skalierung funktioniert auch für Spitzen und Reduzierungen des Datenverkehrs für das TLS- oder TCP-Protokoll.

Wird die Web Application Firewall (WAF) für Layer 4-Datenverkehr unterstützt?

Die Funktionen der Web Application Firewall (WAF) können bei der Verwendung mit Layer 4 nicht eingesetzt werden.

Unterstützt der Layer 4-Proxy von Application Gateway das UDP-Protokoll?

Nein UDP wird zurzeit nicht unterstützt.

Konfiguration: Eingangscontroller für AKS

Was ist ein Eingangscontroller?

Kubernetes ermöglicht die Erstellung von deployment- und service-Ressourcen, um eine Gruppe von Pods intern im Cluster bereitzustellen. Um denselben Dienst extern verfügbar zu machen, wird eine Ingress-Ressource definiert, die Lastenausgleich, TLS-Terminierung und namensbasiertes virtuelles Hosting bereitstellt. Um diese Ingress-Ressource zu bedienen, ist ein Eingangscontroller erforderlich, der auf Änderungen an Ingress-Ressourcen wartet und die Lastenausgleichsrichtlinien konfiguriert.

Der Application Gateway-Eingangscontroller (AGIC) ermöglicht die Verwendung von Application Gateway als Eingangsressource für einen Azure Kubernetes Service-Cluster (auch als AKS-Cluster bezeichnet).

Kann eine einzelne Eingangscontrollerinstanz mehrere Application Gateways verwalten?

Derzeit kann eine Instanz des Eingangscontrollers nur einem Application Gateway zugeordnet werden.

Warum funktioniert mein AKS-Cluster mit kubenet nicht mit dem Application Gateway-Eingangscontroller?

Der Application Gateway-Eingangscontroller versucht, die Routingtabellenressource automatisch dem Application Gateway-Subnetz zuzuordnen. Dabei können jedoch aufgrund fehlender Berechtigungen des Application Gateway-Eingangscontrollers Fehler auftreten. Wenn AGIC die Routentabelle nicht dem Application Gateway-Subnetz zuordnen kann, wird in den AGIC-Protokollen ein Fehler angezeigt. In diesem Fall müssen Sie die vom AKS-Cluster erstellte Routentabelle dem Subnetz des Anwendungsgateways manuell zuordnen. Weitere Informationen finden Sie unter Unterstützte benutzerdefinierte Routen.

Kann ich meinen AKS-Cluster und Application Gateway in separaten virtuellen Netzwerken verbinden?

Ja, solange die virtuellen Netzwerke mittels Peering verknüpft sind und keine Adressräume mit Überschneidungen aufweisen. Wenn Sie AKS mit kubenet ausführen, müssen Sie die von AKS generierte Routingtabelle dem Application Gateway-Subnetz zuordnen.

Welche Funktionen werden vom AGIC-Add-On nicht unterstützt?

Der Unterschied zwischen den über Helm und als AKS-Add-On bereitgestellten AGICs sind unter Unterschied zwischen Helm- und AKS-Add-On-Bereitstellung beschrieben.

Wann sollte ich das Add-On anstelle der Bereitstellung über Helm verwenden?

Der Unterschied zwischen den über Helm und als AKS-Add-On bereitgestellten AGICs sind unter Unterschied zwischen Helm- und AKS-Add-On-Bereitstellungbeschrieben. Beachten Sie dabei insbesondere die Tabellen, in denen angegeben wird, welche Szenarien unterstützt werden, wenn der AGIC über Helm bereitgestellt oder als AKS-Add-On bereitgestellt wird. Im Allgemeinen ermöglicht Ihnen die Bereitstellung über Helm eine Testierung der Betafunktionen und Release Candidates vor einem offiziellen Release.

Kann ich steuern, welche AGIC-Version mit dem Add-On bereitgestellt wird?

Nein Das AGIC-Add-On ist ein verwalteter Dienst, d. h., Microsoft aktualisiert das Add-On automatisch auf die neueste stabile Version.

Konfiguration: gegenseitige Authentifizierung

Was ist gegenseitige Authentifizierung?

Die gegenseitige Authentifizierung ist die bidirektionale Authentifizierung zwischen einem Client und einem Server. Die gegenseitige Authentifizierung mit Application Gateway ermöglicht es dem Gateway derzeit, zu überprüfen, ob der Client die Anforderung sendet. Dies ist die Clientauthentifizierung. In der Regel ist der Client der einzige, der die Application Gateway authentifiziert. Da Application Gateway jetzt auch den Client authentifizieren kann, wird er zur gegenseitigen Authentifizierung, bei der sich Application Gateway und der Client gegenseitig authentifizieren.

Ist eine gegenseitige Authentifizierung zwischen Application Gateway und ihren Back-End-Pools verfügbar?

Nein, die gegenseitige Authentifizierung ist zurzeit nur zwischen dem Front-End-Client und dem Application Gateway möglich. Die gegenseitige Backend-Authentifizierung wird derzeit nicht unterstützt.

Diagnose und Protokollierung

Welche Protokolltypen bietet Application Gateway?

In Application Gateway stehen drei Protokolle zur Verfügung:

  • ApplicationGatewayAccessLog: Das Zugriffsprotokoll enthält jede an das Application Gateway-Front-End gesendete Anforderung. Die Daten enthalten die IP des Aufrufers, die angeforderte URL, die Antwortlatenz, den Rückgabecode sowie die ein- und ausgehenden Bytes. Es enthält einen Datensatz pro Anwendungsgateway.
  • ApplicationGatewayPerformanceLog: Das Leistungsprotokoll erfasst Leistungsinformationen für jedes Anwendungsgateway. Zu den Informationen zählen der Durchsatz in Bytes, die Gesamtanzahl übermittelter Anforderungen, Fehler bei der Anzahl der Anforderungen sowie die Anzahl fehlerfreier und fehlerhafter Back-End-Instanzen.
  • ApplicationGatewayFirewallLog: Bei mit WAF konfigurierten Anwendungsgateways enthält das Firewallprotokoll Anforderungen, die entweder über den Erkennungs- oder über den Schutzmodus protokolliert werden.

Alle Protokolle werden alle 60 Sekunden erfasst. Weitere Informationen finden Sie unter Back-End-Integrität, Diagnoseprotokolle und Metriken für Application Gateway.

Wie erkenne ich, dass die Mitglieder meines Back-End-Pools fehlerfrei sind?

Überprüfen Sie die Integrität mithilfe des PowerShell-Cmdlets Get-AzApplicationGatewayBackendHealth oder über das Portal. Weitere Informationen finden Sie unter Application Gateway-Diagnose.

Welche Aufbewahrungsrichtlinie gilt für die Diagnoseprotokolle?

Diagnoseprotokolle werden an das Speicherkonto des Kunden gesendet. Kunden können die Aufbewahrungsrichtlinie je nach Präferenz festlegen. Diagnoseprotokolle können auch an einen Event Hub oder an Azure Monitor-Protokolle gesendet werden. Weitere Informationen finden Sie unter Application Gateway-Diagnose.

Wie erhalte ich die Überwachungsprotokolle für Application Gateway?

Wählen Sie im Portal auf dem Menübereich eines Anwendungsgateways die Option Aktivitätsprotokoll aus, um das Überwachungsprotokoll aufzurufen.

Kann ich mit Application Gateway Warnungen einrichten?

Ja. In Application Gateway werden Warnungen für Metriken konfiguriert. Weitere Informationen finden Sie unter Back-End-Integrität, Diagnoseprotokolle und Metriken für Application Gateway und Überblick über Warnungen in Microsoft Azure.

Wie lassen sich Datenverkehrsstatistiken für Application Gateway analysieren?

Sie haben verschiedene Möglichkeiten zum Anzeigen und Analysieren von Zugriffsprotokollen. Sie können Azure Monitor-Protokolle, Excel, Power BI usw. verwenden.

Sie können auch eine Resource Manager-Vorlage verwenden, die die beliebte GoAccess-Protokollanalyse für Application Gateway-Zugriffsprotokolle installiert und ausführt. GoAccess stellt wertvolle HTTP-Datenverkehrsstatistiken bereit, z. B. eindeutige Besucher, angeforderte Dateien, Hosts, Betriebssysteme, Browser und HTTP-Statuscodes. Weitere Informationen finden Sie auf GitHub in der Infodatei im Resource Manager-Vorlagenordner.

Was kann dazu führen, dass für die Back-End-Integrität ein unbekannter Status angezeigt wird?

In der Regel wird ein unbekannter Status angezeigt, wenn der Zugriff auf das Back-End durch eine NSG, einen benutzerdefinierten DNS oder durch benutzerdefiniertes Routing für das Application Gateway-Subnetz blockiert wird. Weitere Informationen finden Sie unter Back-End-Integrität, Diagnoseprotokolle und Metriken für Application Gateway.

Werden NSG-Datenflussprotokolle in Netzwerksicherheitsgruppen unterstützt, die dem Application Gateway v2-Subnetz zugeordnet sind?

Wenn Sie über eine Netzwerksicherheitsgruppe im Application Gateway v2-Subnetz (Standard_v2, WAF_v2) verfügen, und wenn darin die NSG-Datenflussprotokolle aktiviert sind, kommt es aufgrund aktueller Plattformeinschränkungen zu nicht deterministischem Verhalten. Dieses Szenario wird derzeit nicht unterstützt.

Wo speichert Application Gateway Kundendaten?

Application Gateway verschiebt oder speichert keine Kundendaten außerhalb der Region, in der es bereitgestellt ist.

Nächste Schritte