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

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

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

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.

Das Keep-Alive-Timeout für HTTP/1.1-Verbindungen beträgt in der Application Gateway v1-SKU und der v2-SKU 120 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.

Um Konflikte und unerwartetes Verhalten zu verhindern, stellen Sie sicher, dass das TCP-Leerlauftimeout mindestens auf das Keep-Alive-Timeout festgelegt ist.

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

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

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.

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.

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

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

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

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

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

Ja. Weitere Informationen 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 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.

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. Wie in RFC 7230 festgelegt, können Antwort-Headernamen beliebige alphanumerischen Zeichen und Sonderzeichen beinhalten.

Ja. Mit dem Chromium-Browser v80-Update wurde ein Mandat eingeführt, das vorsieht, dass HTTP-Cookies ohne SameSite-Attribut als SameSite=Lax behandelt werden. 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.

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.

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 Azure 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 Virtuelles Netzwerk und Subnetz-Anforderungen.

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

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.

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

Siehe Application Gateway – Konfigurationsübersicht

Siehe Application Gateway – Konfigurationsübersicht

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

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. Für das Testen an unterschiedlichen Ports 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. Siehe Zugriff zu bestimmten IPs einschränken.

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.

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.

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.

Hinweis: Im Rahmen der FedRAMP-Compliance ordnet die US-Regierung an, dass Systeme nach August 2024 in einem zulässigen FIPS-Modus ausgeführt werden müssen.

Schritte zum Aktivieren des FIPS-Modus in der V1-SKU:

Schritt 1: Registrieren Sie das Feature AllowApplicationGatewayEnableFIPS, um das Abonnement für die FIPS-Moduskonfiguration zu registrieren.

Für die Registrierung mit Azure PowerShell öffnen Sie eine Cloud Shell-Eingabeaufforderung, und geben Sie Folgendes ein:

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

So führen Sie die Registrierung über das Azure-Portal durch:

• Melden Sie sich beim Azure-Portal an, und suchen Sie nach Previewfunktionen.
• Geben Sie AllowApplicationGatewayEnableFIPS in das Filterfeld ein. Wählen Sie Application Gateway V1 FIPS-Modus zulassen aus, und wählen Sie dann Registrieren aus.

Schritt 2: Setzen Sie die Eigenschaft enableFips auf True. Verwenden Sie dazu PowerShell, eine Azure Resource Manager-Vorlage oder eine REST-API.

# Get the application gateway
$appgw = Get-AzApplicationGateway -Name <ApplicationGatewayName> -ResourceGroupName <ResourceGroupName>
# Set the EnableFips property
$appgw.EnableFips = $true
# Update the application gateway
Set-AzApplicationGateway -ApplicationGateway $appgw

Das Ändern des FIPS-Modus wirkt sich nicht auf die Gesamtverfügbarkeit von Verschlüsselungssammlungen für V1-Gateways aus. Wenn Sie jedoch die Kryptografie für elliptische Kurven für Verschlüsselungsverfahren verwenden, können Sie bei deaktiviertem FIPS-Modus „curve25519“, „NistP256“ und „NistP384“ verwenden, während bei aktiviertem FIPS-Modus nur „NistP256“ und „NistP384“ zulässig sind und „curve25519“ deaktiviert ist. Da „curve25519“ im FIPS-Modus nicht mehr verfügbar ist, stellen Sie sicher, dass Ihre Clients „NistP256“ oder „NistP384“ für die sichere Kommunikation unterstützen, bevor der FIPS aktiviert wird.

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:

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

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

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 Nein, verwenden Sie nur alphanumerische Zeichen in Ihrem PFX-Dateikennwort.

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:

• Bug 1649951
• Bug 1650910

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.

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.

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.

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.

• REST-API
• BEFEHLSZEILENSCHNITTSTELLE (CLI)

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.

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.

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.

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.

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.

Die gleiche TLS/SSL-Richtlinienkonfiguration gilt sowohl für Layer 7 (HTTPS) als auch für Layer 4 (TLS). Sie können jetzt SSL-Profil (für listenerspezifische TLS-Richtlinie und gegenseitige Authentifizierung) für TLS-Listener verwenden. Derzeit kann jedoch nur ein SSL-Profil einem TLS-Listener über CLI, PowerShell oder REST-API zugeordnet werden.

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.

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

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

Nein UDP wird zurzeit nicht unterstützt.

Die gleiche Liste der zulässigen Portbereiche und Ausnahmen gelten auch für den Layer 4-Proxy.

Die Verwendung eines gemeinsamen Ports für TLS/TCP-Listener wird derzeit nicht unterstützt.

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

Die direkte Konfiguration von Application Gateway wird nicht unterstützt.

Wenn die Einstellungen für Application Gateway geändert werden müssen, nehmen Sie die Änderung mithilfe der verfügbar gemachten Konfiguration für den Eingangsdatencontroller oder andere Kubernetes-Objekte vor, z. B. mithilfe unterstützter Anmerkungen. Nachdem ein Application Gateway mit dem Application Gateway Ingress Controller (AGIC) verknüpft wurde, werden nahezu alle Konfigurationen dieses Gateways vom Eingangsdatencontroller synchronisiert und gesteuert. Wenn Sie versuchen, Application Gateway imperativ oder über Infrastructure-as-Code direkt zu konfigurieren, werden diese Änderungen schließlich vom Eingangsdatencontroller überschrieben.

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

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.

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

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.

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

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

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.