Konfigurieren der Application Gateway-Infrastruktur

Die Azure Application Gateway-Infrastruktur umfasst das virtuelle Netzwerk, Subnetze, Netzwerksicherheitsgruppen (NSGs) und benutzerdefinierte Routen (UDRs).

Virtuelles Netzwerk und dediziertes Subnetz

Ein Application Gateway ist eine dedizierte Bereitstellung in Ihrem virtuellen Netzwerk. Innerhalb Ihres virtuellen Netzwerks ist ein dediziertes Subnetz für das Application Gateway erforderlich. Sie können mehrere Instanzen eines bestimmten Application Gateway einsetzen. Außerdem können Sie weitere Application Gateway-Instanzen im Subnetz bereitstellen. Aber Sie können keine andere Ressource im Application Gateway-Subnetz bereitstellen. Sie können keine v1- und v2-Anwendungsgateway-SKUs im selben Subnetz kombinieren.

Subnetzgröße

Application Gateway nutzt eine private IP-Adresse pro Instanz sowie eine weitere private IP-Adresse, wenn eine private Front-End-IP konfiguriert ist.

Azure reserviert außerdem fünf IP-Adressen in jedem Subnetz für die interne Nutzung. Sie sind die ersten vier Adressen und die letzten IP-Adressen. Stellen Sie sich beispielsweise 15 Application Gateway-Instanzen ohne private Frontend-IP vor. Sie benötigen mindestens 20 IP-Adressen für dieses Subnetz. Sie benötigen 5 für den internen Gebrauch und 15 für die Application Gateway-Instanzen.

Stellen Sie sich ein Subnetz mit 27 Application Gateway-Instanzen und einer privaten Frontend-IP vor. In diesem Fall benötigen Sie 33 IP-Adressen. Sie benötigen 27 Instanzen für das Application Gateway, eine für das private Frontend und 5 für den internen Gebrauch.

Application Gateway (Standard oder WAF SKU) kann bis zu 32 Instanzen unterstützen (32 Instanz-IP-Adressen + 1 private Frontend-IP-Konfiguration + 5 Azure reserviert). Wir empfehlen eine minimale Subnetzgröße von /26.

Die Application Gateway-Instanz (Standard_v2- oder WAF_v2-SKU) kann bis zu 125 Instanzen unterstützen (125 Instanz-IP-Adressen + 1 private Front-End-IP-Konfiguration + 5 für Azure reservierte). Wir empfehlen eine minimale Subnetzgröße von /24.

Um die verfügbare Kapazität eines Subnetzes zu ermitteln, für das bereits Anwendungsgateways bereitgestellt wurden, nehmen Sie die Größe des Subnetzes und ziehen Sie die fünf reservierten IP-Adressen des von der Plattform reservierten Subnetzes ab. Ziehen Sie dann von jedem Gateway die maximale Anzahl der Instanzen ab. Ziehen Sie für jedes Gateway, das eine private Frontend-IP-Konfiguration hat, eine weitere IP-Adresse pro Gateway ab.

Hier erfahren Sie beispielsweise, wie Sie die verfügbare Adressierung für ein Subnetz mit drei Gateways unterschiedlicher Größe berechnen:

• Gateway 1: Maximal 10 Instanzen. Verwendet eine private Frontend-IP-Konfiguration.
• Gateway 2: Maximal 2 Instanzen. Keine private Frontend-IP-Konfiguration.
• Gateway 3: Maximal 15 Instanzen. Verwendet eine private Frontend-IP-Konfiguration.
• Subnetzgröße: /24
  • Subnetzgröße /24 = 256 IP-Adressen – 5 von der Plattform reservierte = 251 verfügbare Adressen
  • 251: Gateway 1 (10) – 1 private Frontend-IP-Konfiguration = 240
  • 240: Gateway 2 (2) = 238
  • 238: Gateway 3 (15) – 1 private Frontend-IP-Konfiguration = 222

Das Subnetz namens GatewaySubnet ist für VPN-Gateways reserviert. Die Anwendungsgateway-v1-Ressourcen, die das GatewaySubnet-Subnetz verwenden, müssen in ein anderes Subnetz verschoben oder vor dem 30. September 2023 auf die v2-SKU migriert werden, um Steuerungsebenenfehler und Plattforminkonsistenzen zu vermeiden. Informationen zum Ändern des Subnetzes einer vorhandenen Anwendungsgateway-Instanz finden Sie unter Häufig gestellte Fragen zum Anwendungsgateway.

Es ist möglich, das Subnetz einer vorhandenen Application Gateway-Instanz innerhalb desselben virtuellen Netzwerks zu ändern. Um diese Änderung vorzunehmen, verwenden Sie Azure PowerShell oder die Azure CLI. Weitere Informationen finden Sie in den häufig gestellten Fragen zu Application Gateway.

DNS-Server zur Namensauflösung

Die virtuelle Netzwerkressource unterstützt die DNS-Server-Konfiguration, mit der Sie zwischen von Azure bereitgestellten Standard- oder benutzerdefinierten DNS-Servern wählen können. Die Instanzen Ihres Anwendungsgateways berücksichtigen diese DNS-Konfiguration auch für jede Namensauflösung. Nachdem Sie diese Einstellung geändert haben, müssen Sie Ihr Anwendungsgateway neu starten (Beenden und Starten), damit diese Änderungen für die Instanzen wirksam werden.

Wenn Ihre Application Gateway-Instanz eine DNS-Abfrage ausgibt, verwendet sie den Wert von dem Server, der zuerst antwortet.

Berechtigung für virtuelle Netzwerke

Die Application Gateway-Ressource wird in einem virtuellen Netzwerk bereitgestellt. Daher wird auch die Berechtigung für die bereitgestellte Ressource des virtuellen Netzwerks überprüft. Diese Überprüfung wird sowohl beim Erstellen als auch bei Verwaltungsvorgängen durchgeführt und gilt auch für die verwalteten Identitäten für den Application Gateway-Eingangscontroller.

Überprüfen Sie Ihre rollenbasierte Zugriffssteuerung in Azure, um sicherzustellen, dass die Benutzer und Dienstprinzipale, die Anwendungsgateways betreiben, ebenfalls mindestens über die folgenden Berechtigungen im virtuellen Netzwerk oder Subnetz verfügen:

• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/read

Sie können die integrierten Rollen verwenden, z. B. Netzwerkmitwirkender, die diese Berechtigungen bereits unterstützen. Wenn eine integrierte Rolle nicht die richtige Berechtigung bereitstellt, können Sie eine benutzerdefinierte Rolle erstellen und zuweisen. Weitere Informationen zum Verwalten von Subnetzberechtigungen.

Identifizieren betroffener Benutzer oder Dienstprinzipale für Ihr Abonnement

Wenn Sie Azure Advisor für Ihr Konto besuchen, können Sie überprüfen, ob Ihr Abonnement über Benutzer oder Dienstprinzipale mit unzureichender Berechtigung verfügt. Die Details dieser Empfehlung sind wie folgt:

Titel: Aktualisieren der VNet-Berechtigung von Anwendungsgatewaybenutzern
Kategorie: Zuverlässigkeits
-Wirkung: Hoch

Vorläufiges Azure Feature Exposure Control (AFEC)-Flag verwenden

Als temporäre Erweiterung haben wir eine Azure Feature Exposure Control (AFEC) auf Abonnementebene eingeführt. Sie können sich für die AFEC registrieren und verwenden, bis Sie die Berechtigungen für alle Ihre Benutzer und Dienstprinzipale korrigieren. Registrieren Sie sich für die angegebene Funktion, indem Sie dieselben Schritte wie für die Registrierung für Previewfunktionen für Ihr Azure-Abonnement ausführen.

Name: Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck
Beschreibung: Deaktivieren der Berechtigungsprüfung für das Anwendungsgateway-Subnetz
ProviderNamespace: Microsoft.Network
EnrollmentType: AutoApprove

Azure Virtual Network Manager

Azure Virtual Network Manager ist ein Verwaltungsdienst, mit dem Sie virtuelle Netzwerke global und abonnementübergreifend gruppieren, konfigurieren, bereitstellen und verwalten können. Mit Virtual Network Manager können Sie Netzwerkgruppen definieren, um Ihre virtuellen Netzwerke zu identifizieren und logisch zu segmentieren. Danach können Sie die gewünschten Konnektivitäts- und Sicherheitskonfigurationen festlegen und sie auf alle ausgewählten virtuellen Netzwerke in Netzwerkgruppen gleichzeitig anwenden.

Mit der Konfiguration der Sicherheitsadministratorregel in Azure Virtual Network Manager können Sie Sicherheitsrichtlinien im großen Maßstab definieren und auf mehrere virtuelle Netzwerke gleichzeitig anwenden.

Netzwerksicherheitsgruppen

Sie können NSGs für Ihr Anwendungsgateway-Subnetz verwenden, beachten Sie jedoch einige wichtige Punkte und Einschränkungen.

Erforderliche Sicherheitsregeln

Um eine NSG mit Ihrem Anwendungsgateway zu verwenden, müssen Sie einige wesentliche Sicherheitsregeln erstellen oder beibehalten. Sie können deren Priorität in derselben Reihenfolge festlegen.

Eingangsregeln

Clientdatenverkehr: Zulassen des eingehenden Datenverkehrs von den erwarteten Clients (als Quell-IP- oder IP-Bereich) und für das Ziel als das gesamte Subnetz-IP-Präfix ihres Anwendungsgateways und eingehender Zugriffsports. Wenn Sie beispielsweise Listener für die Ports 80 und 443 konfiguriert haben, müssen Sie diese Ports zulassen. Sie können diese Regel auch für Any festlegen.

Nachdem Sie aktive öffentliche und private Listener(mit Regeln) mit derselben Portnummer konfiguriert haben, ändert Ihr Anwendungsgateway das Ziel aller eingehenden Flows in die Frontend-IPs Ihres Gateways. Diese Änderung tritt auch bei Listenern auf, die keinen Port freigeben. Sie müssen die öffentlichen und privaten IP-Adressen Ihres Gateways in das Ziel der eingehenden Regel einschließen, wenn Sie dieselbe Portkonfiguration verwenden.

Infrastrukturports: Eingehende Anforderungen von der Quelle als GatewayManager-Diensttag und beliebiges Ziel zulassen. Der Zielportbereich unterscheidet sich je nach SKU und ist für die Kommunikation des Status der Back-End-Integrität erforderlich. Diese Ports werden von Azure-Zertifikaten geschützt/gesperrt. Externe Stellen können keine Änderungen an diesen Endpunkten vornehmen, wenn keine entsprechenden Zertifikate vorhanden sind.

• V2: Ports 65200-65535
• V1: Ports 65503-65534

Azure Load Balancer-Prüfpunkte: Eingehenden Datenverkehr aus der Quelle als AzureLoadBalancer-Diensttag zulassen. Diese Regel wird standardmäßig für NSGs erstellt. Sie dürfen sie nicht mit einer manuellen Verweigerungsregel überschreiben, um einen reibungslosen Betrieb Ihres Anwendungsgateways sicherzustellen.

Sie können alle anderen eingehenden Daten mit einer Alle verweigern-Regel blockieren.

Ausgangsregeln

Ausgehend an das Internet: Ausgehender Datenverkehr ins Internet für alle Ziele zulassen. Diese Regel wird standardmäßig für NSGs erstellt. Sie dürfen sie nicht mit einer manuellen Verweigerungsregel überschreiben, um einen reibungslosen Betrieb Ihres Anwendungsgateways sicherzustellen. Ausgehende NSG-Regeln, die ausgehende Verbindungen verweigern, dürfen nicht erstellt werden.

Unterstützte benutzerdefinierte Routen

Die feinkörnige Kontrolle über das Anwendungsgateway-Subnetz über Routingtabellenregeln ist in der öffentlichen Vorschau möglich. Weitere Informationen finden Sie unter Bereitstellung eines privaten Anwendungsgateways (Vorschau).

Bei der aktuellen Funktionalität gibt es einige Einschränkungen:

• v1: Bei der SKU v1 werden UDRs im Anwendungsgateway-Subnetz unterstützt, wenn sie die End-to-End-Anfrage/Antwort-Kommunikation nicht verändern. Beispielsweise können Sie eine benutzerdefinierte Route im Application Gateway-Subnetz einrichten, um auf eine Firewallappliance für die Paketüberprüfung zu verweisen. Sie müssen jedoch sicherstellen, dass das Paket nach der Überprüfung das vorgesehene Ziel erreichen kann. Ein Unterlassen kann zu einem falschen Integritätstest oder Datenverkehrsrouting-Verhalten führen. Gelernte Routen oder Standard 0.0.0.0/0-Routen, die von Azure ExpressRoute oder VPN-Gateways im virtuellen Netzwerk propagiert werden, sind ebenfalls enthalten.

• v2: Für die SKU v2 gibt es unterstützte und nicht unterstützte Szenarien.

Unterstützte v2-Szenarios

Szenario 1: UDR zur Deaktivierung der Weiterleitung von Border Gateway Protocol (BGP)-Routen an das Anwendungsgateway-Subnetz

Manchmal wird die Standardgatewayroute (0.0.0.0/0) per ExpressRoute oder VPN-Gateways angekündigt, die dem virtuellen Application Gateway-Netzwerk zugeordnet sind. Dieses Verhalten unterbricht den Verkehr auf der Verwaltungsebene, der einen direkten Pfad zum Internet benötigt. In solchen Szenarien können Sie eine UDR verwenden, um die BGP-Routenverteilung zu deaktivieren.

So deaktivieren Sie die BGP-Routenverteilung:

1. Erstellen Sie eine Routingtabelleressource in Azure.
2. Deaktivieren Sie den Parameter Routenverteilung des Gateways für virtuelle Netzwerke.
3. Ordnen Sie die Routingtabelle dem entsprechenden Subnetz zu.

Das Aktivieren der benutzerdefinierten Route für dieses Szenario sollte keine vorhandenen Setups unterbrechen.

Szenario 2: UDR zum Weiterleiten von 0.0.0.0/0 in das Internet

Sie können eine benutzerdefinierte Route erstellen, um Datenverkehr an 0.0.0.0/0 direkt an das Internet zu übermitteln.

Szenario 3: UDR für Azure Kubernetes Service (AKS) mit kubenet

Wenn Sie kubenet mit AKS und Application Gateway-Eingangsdatencontroller verwenden, benötigen Sie eine Routingtabelle, damit der vom Anwendungsgateway an die Pods gesendete Verkehr an den richtigen Knoten weitergeleitet wird. Sie müssen keine Routentabelle verwenden, wenn Sie das Azure Container Networking Interface verwenden.

So verwenden Sie die Routentabelle, um zu ermöglichen, dass Kubenet funktioniert:

1. Wechseln Sie zu der von AKS erstellten Ressourcengruppe. Der Name der Ressourcengruppe sollte mit MC_ beginnen.

2. Suchen Sie von AKS in dieser Ressourcengruppe erstellte Routentabelle. Die Routingtabelle sollte mit den folgenden Informationen aufgefüllt sein:

   • Das Adresspräfix sollte dem IP-Adressbereich der Pods entsprechen, die Sie in AKS erreichen möchten.
   • Der Typ des nächsten Hops sollte „virtuelles Gerät“ sein.
   • Die Adresse des nächsten Hops sollte der IP-Adresse des Knotens entsprechen, der die Pods hostet.

3. Ordnen Sie diese Routingtabelle dem Subnetz des Application Gateways zu.

Nicht unterstützte v2-Szenarios

Szenario 1: UDR für virtuelle Geräte

Jedes Szenario, bei dem 0.0.0.0/0 über ein virtuelles Gerät, ein virtuelles Hub/Spoke-Netzwerk oder lokal (erzwungenes Tunneln) umgeleitet werden muss, wird von v2 nicht unterstützt.

Nächste Schritte

• Erfahren Sie mehr über die Konfiguration der Frontend-IP-Adresse
• Erfahren Sie mehr über die Bereitstellung privater Anwendungsgateways