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.

Im Folgenden finden Sie häufig gestellte Fragen zu Azure Application Gateway.

Allgemein

Was ist Application Gateway?

Azure Application Gateway stellt einen Application Deliver Controller (ADC) 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. Es ist auch in Microsoft Azure verfügbar, das von 21Vianet und Azure Government betrieben wird.

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

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 IP- und DNS-Informationen in der öffentlichen IP-Adressressource. Sie können sie auch im 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 verfügen Gateways, die nach dem 1. Mai 2023 erstellt wurden, nicht automatisch über einen DNS-Standardnamen, der der öffentlichen IP-Ressource 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?

Das Keep-Alive-Timeout bestimmt, wie lange der Application Gateway wartet, bis ein Client eine weitere HTTP-Anforderung für eine persistente Verbindung sendet, bevor er wieder verwendet oder geschlossen wird. Tcp-Leerlauftimeout bestimmt, wie lange eine TCP-Verbindung geöffnet bleibt, wenn keine Aktivität vorhanden ist.

Der Keep-Alive-Timeout in der Application Gateway v1-SKU beträgt 120 Sekunden und in der v2-SKU 75 Sekunden. Bei privaten IP-Adressen ist der Wert mit einem TCP-Leerlauftimeout von 5 Minuten nicht konfigurierbar. 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. Sie können den Wert für das TCP-Leerlauftimeout für v1- und v2-Anwendungsgateways zwischen 4 Minuten und 30 Minuten festlegen. Für Application Gateways v1 und v2 müssen Sie zur öffentlichen IP-Adresse des Application Gateway navigieren und das TCP-Leerlauftimeout auf dem Blatt "Konfiguration" der öffentlichen IP 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 auf Application Gateway v2-SKU wird das Leerlauftimeout auf 180 Sekunden festgelegt und kann nicht konfiguriert werden.

Wird die TCP-Verbindung, die mit dem Back-End-Server hergestellt wird, Application Gateway wiederverwendet?

Ja. Application Gateway verwendet die vorhandenen TCP-Verbindungen mit dem Back-End-Server wieder.

Kann ich meine Application Gateway-Ressource umbenennen?

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

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

Nein. Es gibt keine Möglichkeit, eine Application Gateway Ressource oder deren öffentliche IP-Adresse wiederherzustellen, nachdem sie gelöscht wurde. 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. In Application Gateway V2-SKU sind 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.

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 eines Anwendungsgateways? 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. Bei manchen Bereitstellungsarten kann sie jedoch auch mehr Zeit beanspruchen. Bereitstellungen, die sich über mehrere Verfügbarkeitszonen erstrecken und viele Instanzen umfassen, können beispielsweise länger als sechs Minuten dauern.

Wie behandelt Application Gateway routinemäßige Wartungen?

Updates, die für Application Gateway initiiert wurden, werden jeweils eine Updatedomäne angewendet. Während die Instanzen jeder Updatedomäne aktualisiert werden, werden die verbleibenden Instanzen in anderen Updatedomänen weiterhin Datenverkehr1 verarbeiten. 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 Es wird empfohlen, für Application Gateway v1-SKU-Bereitstellungen mindestens eine instance Anzahl von 2 zu konfigurieren, um sicherzustellen, dass mindestens ein instance Datenverkehr verarbeiten kann, während Updates angewendet werden.

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

Application Gateway unterstützt keine E-Mail-Protokolle wie SMTP, IMAP oder POP3. HTTP/HTTPS-Dienste wie OWA-, ActiveSync- und AutoDiscovery-Datenverkehr können durch Anwendungsgateway fließen, bei Verwendung von WAF-SKU können jedoch WAF-Ausschlüsse erforderlich sein.

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

Wird Application Gateway v1-SKU unterstützt?

Ja. Die Application Gateway v1-SKU wird weiterhin unterstützt. Es wird jedoch dringend empfohlen, zu v2 zu wechseln, um die Featureupdates in dieser SKU zu nutzen. Weitere Informationen über die Unterschiede zwischen v1- und v2-Funktionen finden Sie unter Automatische Skalierung und zonenredundantes Application Gateway v2. Sie können SKU-Bereitstellungen von Application Gateway v1 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. Antwortheadernamen können beliebige alphanumerische Zeichen und spezifische Symbole enthalten, die in RFC 7230 definiert sind, mit Ausnahme von Unterstrichen (_).

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, die als SameSite=Lax behandelt werden. Das bedeutet, dass das Affinitätscookie von Application Gateway nicht vom Browser in einem Drittanbieterkontext gesendet wird.

Zur Unterstützung dieses Szenarios fügt Application Gateway zusätzlich zum vorhandenen Cookie ApplicationGatewayAffinity ein weiteres Cookie namens ApplicationGatewayAffinityCORS ein. Diese Cookies sind ähnlich, aber dem Cookie ApplicationGatewayAffinityCORS wurden zwei weitere Attribute hinzugefügt: SameSite=None; Secure. Diese Attribute behalten persistente Sitzungen selbst bei quellenübergreifenden Anforderungen bei. Weitere Informationen finden Sie im Abschnitt zur cookiebasierten Affinität.

Was wird als aktiver Listener gegenüber einem inaktiven Listener betrachtet?

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 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 DR-Szenario?

Verteilen Sie Datenverkehr mithilfe von 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 Application Gateway – Konfigurationsübersicht.

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, sofern eine IP-Verbindung besteht. 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 den FQDN-basierten Back-End-Server aktualisiert?

Wie jeder DNS-Resolver berücksichtigt die Application Gateway-Ressource den TTL-Wert (Time to live) des DNS-Eintrags des Back-End-Servers. Nach Ablauf der Gültigkeitsdauer führt das Gateway eine Suche durch, um diese DNS-Informationen zu aktualisieren. Wenn bei dieser Suche für Ihr Anwendungsgateway ein Problem beim Abrufen einer Antwort auftritt (oder kein DNS-Eintrag gefunden wird), verwendet das Gateway weiterhin den letzten bekannten DNS-Wert, um den Datenverkehr zu verarbeiten. Erfahren Sie mehr.

Warum werden 502-Fehler oder fehlerhafte Back-End-Server angezeigt, 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 neu starten (Beenden und Starten), damit die neuen DNS-Server zugewiesen werden. Bis dahin können FQDN-basierte Namensauflösungen für ausgehende Konnektivität 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 mit V1 mit öffentlichem und privatem Front-End und V2 nur mit öffentlichem Front-End unterstützt. Es ist auch wichtig zu beachten, dass die Application Gateway den Status Beendet aufweisen sollte, um diese Aktion auszuführen. Beachten Sie, dass das Beenden/Starten von V1 die öffentliche IP-Adresse ändert. 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 in Application Gateway Subnetz nicht unterstützt, und die Konfiguration blockiert den Azure-Infrastrukturdatenverkehr.

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 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. Um verschiedene Ports zu testen, 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?

Ja. Weitere Informationen finden Sie unter Application Gateway – Konfigurationsübersicht.

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

Ja, Sie können öffentliche und private Listener mit derselben Portnummer verwenden, um gleichzeitig öffentliche und private Clients zu unterstützen (Feature in der Vorschau). Beachten Sie, dass, wenn eine Netzwerksicherheitsgruppe (Network Security Group, NSG) dem Subnetz Ihres Anwendungsgateways zugeordnet ist, je nach Konfiguration möglicherweise eine bestimmte Eingehende Regel erforderlich ist. Erfahren Sie mehr.

Unterstützt Application Gateway IPv6?

Application Gateway v2 unterstützt IPv6 derzeit nicht. Es kann in einem Dual Stack-VNet betrieben werden, wo nur IPv4 verwendet wird, aber nur in Verbindung mit einem IPv4-Gatewaysubnetz. Application Gateway v1 bietet keine Unterstützung für Dual Stack-VNets.

Unterstützt Application Gateway FIPS?

Application Gateway v1-SKUs können in einem von FIPS 140-2 genehmigten Betriebsmodus ausgeführt werden, der häufig als "FIPS-Modus" bezeichnet wird.  Im FIPS-Modus wird ein FIPS 140-2 validiertes Kryptografiemodul aufgerufen, das FIPS-kompatible Algorithmen für Verschlüsselung, Hashing und Signatur sicherstellt, wenn diese aktiviert ist.  Um sicherzustellen, dass der FIPS-Modus aktiviert ist, muss die FIPSMode-Einstellung über PowerShell, ARM-Vorlage oder REST-API konfiguriert werden, sobald das Abonnement registriert wurde, um die Konfiguration von FIPSmode zu aktivieren.

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

Application Gateway V2 unterstützt derzeit nur die Konfiguration des privaten IP-Front-Ends (keine öffentliche IP-Adresse) über die öffentliche Vorschau. Weitere Informationen finden Sie hier.

Für die aktuelle allgemeine Verfügbarkeitsunterstützung unterstützt Application Gateway V2 die folgenden Kombinationen

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

Um den Datenverkehr nur auf private IP-Adressen mit aktueller Funktionalität zu beschränken, können Sie den folgenden Prozess ausführen:

  1. Erstellen einer 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:

    a. Lassen Sie Datenverkehr von der Quelle als GatewayManager-Diensttag zu, 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.

    b. Lassen Sie Datenverkehr von der Quelle mit dem AzureLoadBalancer-Diensttag und dem Zielport Beliebig zu.

    c. Verweigern Sie sämtlichen eingehenden Datenverkehr von der Quelle mit dem Internet-Diensttag und dem Zielport Beliebig. Weisen Sie dieser Regel die geringste Priorität in den Eingangsregeln zu.

    d. Behalten Sie die Standardregeln wie das Zulassen des eingehenden VirtualNetwork-Datenverkehrs bei, damit der Zugriff auf die private IP-Adresse nicht blockiert wird.

    e. Die ausgehende Internetverbindung kann nicht blockiert sein. Andernfalls treten Probleme mit der Protokollierung, Metriken usw. auf.

Beispiel-NSG-Konfiguration für nur privaten IP-Zugriff: Application Gateway V2 NSG-Konfiguration nur für privaten IP-Zugriff

Wie kann ich das Azure Application Gateway anhalten?

Sie können die Azure PowerShell oder die Azure CLI verwenden, um das Azure Application Gateway zu starten. Wenn Sie die Application Gateway starten, wird die Abrechnung ebenfalls beendet und gestartet. Jeder PUT-Vorgang, der für eine beendete Application Gateway ausgeführt wird (z. B. Hinzufügen von Tag, Integritätstest, Listener usw.) löst einen Start aus. Es wird empfohlen, das Anwendungsgateway zu beenden, sobald die Konfiguration aktualisiert wurde.

# 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 die folgenden 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 die erneute Verschlüsselung des Datenverkehrs zum 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 Back-End-Neuverschlüsselung unterstützt Application Gateway?

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, 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, in denen mehrere von Zertifizierungsstellenanbietern ausgestellte Zertifikate aufgeführt sind, die von unseren Kunden, Microsoft und der größeren Technologiecommunity verwendet werden und nicht den Industriestandards für öffentlich vertrauenswürdige Zertifizierungsstellen entsprechen. Die Berichte zu den nicht konformen Zertifizierungsstellen finden Sie hier:

Gemäß den Complianceanforderungen der Branche haben Ca-Anbieter damit begonnen, nicht konforme Zertifizierungsstellen zu widerrufen und konforme Zertifizierungsstellen auszustellen, was erfordert, dass die Kunden ihre Zertifikate neu ausstellen lassen. Microsoft arbeitet eng mit diesen Anbietern zusammen, um die potenziellen Auswirkungen auf Azure-Dienste zu minimieren. Bei Ihren selbst ausgestellten Zertifikaten oder in „Bring Your Own Certificate“-Szenarien (BYOC-Szenarien) verwendeten Zertifikaten besteht jedoch nach wie vor das Risiko, dass sie unerwartet widerrufen werden.

Um zu überprüfen, ob von Ihrer Anwendung verwendete Zertifikate widerrufen wurden, verweisen Sie auf DigiCerts Ankündigung und den Zertifikatsperrungs-Tracker. Wenn Ihre Zertifikate widerrufen wurden oder widerrufen werden, müssen Sie neue Zertifikate von der Zertifizierungsstelle anfordern, die in Ihren Anwendungen verwendet wird. Um zu vermeiden, dass die Verfügbarkeit Ihrer Anwendung unterbrochen wird, weil Zertifikate unerwartet widerrufen werden, oder um ein zertifikat zu aktualisieren, das widerrufen wurde, lesen Sie unseren Azure-Updates-Beitrag, um Abhilfelinks zu verschiedenen Azure-Diensten zu finden, die BYOC unterstützen: https://azure.microsoft.com/updates/certificateauthorityrevocation/

Application Gateway-spezifische Informationen finden Sie weiter unten.

Wenn Sie ein Zertifikat verwenden, das von einer der widerrufenen ICAs ausgestellt wurde, kann die Verfügbarkeit Ihrer Anwendung unterbrochen werden, und je nach Anwendung erhalten Sie möglicherweise verschiedene Fehlermeldungen, einschließlich, aber nicht beschränkt auf:

  1. Ungültiges Zertifikat/Widerrufenes Zertifikat
  2. Timeout bei Verbindung
  3. HTTP 502

Um eine Unterbrechung Ihrer Anwendung aufgrund dieses Problems zu vermeiden oder eine widerrufene Zertifizierungsstelle erneut ausstellen zu können, 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 Azure Application Gateway/WAF mit der vollständigen Vertrauenskette (untergeordnetes Zertifikat, Zwischenzertifikat, Stammzertifikat). Führen Sie abhängig davon, wo Sie Ihr Zertifikat verwenden, entweder auf dem Listener oder in den HTTP-Einstellungen des Anwendungsgateways die folgenden Schritte aus, um die Zertifikate zu aktualisieren, und nutzen Sie die aufgeführten Dokumentationslinks, um weitere Informationen zu erhalten.
  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. Suchen Sie nach der Dokumentation Ihres Anbieters.

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. Klicken Sie auf "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 Azure Key Vault verweisen, sollten Sie die folgenden Schritte ausführen, um eine schnelle Änderung zu erreichen:

  1. Navigieren Sie im Azure-Portal zu Ihren Azure KeyVault-Einstellungen, die dem Application Gateway zugeordnet sind.
  2. Fügen Sie das neu ausgestellte Zertifikat zu Ihrem Speicher hinzu, oder importieren Sie es. Weitere Informationen zur Vorgehensweise finden Sie in dieser Dokumentation.
  3. Navigieren Sie nach dem Importieren des Zertifikats zu Ihren Application Gateway Listenereinstellungen, und klicken Sie unter "Zertifikat aus Key Vault auswählen" auf das Dropdownmenü "Zertifikat", und wählen Sie das kürzlich hinzugefügte Zertifikat aus.
  4. Klicken Sie auf „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. Klicken Sie auf "Zertifikat hinzufügen", laden Sie das neu ausgestellte Zertifikat hoch, und klicken Sie auf Speichern.
  4. Sie können das alte Zertifikat später entfernen, indem Sie auf das "..." Optionsschaltfläche neben dem alten Zertifikat, wählen Sie Löschen aus, und klicken Sie auf 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 die HTTP-Einstellungen hochladen, da die V2-SKU "vertrauenswürdige Stammzertifikate" verwendet, und hier muss keine Aktion ausgeführt werden.

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 lauscht und die Lastenausgleichsrichtlinien konfiguriert.

Der Application Gateway-Eingangscontroller (AGIC) ermöglicht die Verwendung von Azure 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 Routingtabelle dem Application Gateway Subnetz nicht zuordnen kann, tritt in den AGIC-Protokollen ein Fehler auf, der dies besagt. In diesem Fall müssen Sie die vom AKS-Cluster erstellte Routingtabelle manuell dem Subnetz des Application Gateway 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?

Hier finden Sie die Unterschiede zwischen AGIC, die über Helm bereitgestellt werden, und der Bereitstellung als AKS-Add-On .

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

Die Unterschiede zwischen dem über Helm bereitgestellten AGIC und dem als AKS-Add-On bereitgestellten AGIC finden Sie hier. Beachten Sie dabei insbesondere die Tabellen, in denen beschrieben wird, welche Szenarien unterstützt werden, wenn der AGIC über Helm bereitgestellt wird im Gegensatz zur Bereitstellung als AKS-Add-On. Im Allgemeinen können Sie durch die Bereitstellung über Helm Betafeatures und Releasekandidaten vor einem offiziellen Release testen.

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

Nein, das AGIC-Add-On ist ein verwalteter Dienst, was bedeutet, dass Microsoft das Add-On automatisch auf die neueste stabile Version aktualisiert.

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üblatt 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 Netzwerksicherheitsgruppe (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 NSG im Subnetz Application Gateway v2 (Standard_v2, WAF_v2) verfügen und sie NSG-Flowprotokolle aktiviert haben, wird aufgrund der aktuellen Plattformeinschränkungen ein nicht deterministisches Verhalten angezeigt, und 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

Weitere Informationen zu Application Gateway finden Sie unter Was ist Azure Application Gateway?. Informationen zum TLS-Abschluss sowie zu End-to-End-TLS mit Application Gateway finden Sie unter Aktivieren von End-to-End-TLS in Azure Application Gateway.