Häufig gestellte Fragen zu 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.

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.

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.

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

Siehe Application Gateway – Konfigurationsübersicht

Siehe Application Gateway-Komponenten

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.

Application Gateway ist eine dedizierte Bereitstellung in Ihrem virtuellen Netzwerk.

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

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

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.

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.

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

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

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.

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.

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.

Ein Anwendungsgateway unterstützt nur eine öffentliche IP-Adresse.

Siehe Application Gateway – Konfigurationsübersicht

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.

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

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

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.

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 Datenverkehr¹ 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.

¹ 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.

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.

Ja. Details dazu finden Sie unter Migrieren von Azure Application Gateway und Web Application Firewall von v1 zu v2.

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.

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

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 (_).

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.

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.

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.

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

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“.

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

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

Ja.

Ja.

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.

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 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.

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.

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

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>

Siehe Application Gateway – Konfigurationsübersicht

Siehe Application Gateway – Konfigurationsübersicht

Nein. Dienstendpunktrichtlinien für Speicherkonten werden in Application Gateway Subnetz nicht unterstützt, und die Konfiguration blockiert den Azure-Infrastrukturdatenverkehr.

Siehe Einschränkungen für Azure-Abonnements und Dienste, Kontingente und Einschränkungen

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

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

Ja, sofern Datenverkehr zugelassen wird.

Microservice-Architektur wird unterstützt. Um verschiedene Ports zu testen, müssen Sie mehrere Back-End-Einstellungen konfigurieren.

Nein.

Siehe Application Gateway – Konfigurationsübersicht

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>.

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

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.

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.

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.

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:

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

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

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.

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

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.

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.

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

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

Application Gateway unterstützt bis zu 100 Authentifizierungszertifikate.

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

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.

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

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:

• Bug 1649951
• Bug 1650910

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.

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).

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

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.

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.

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

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.

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

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.