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.
Hinweis
Richtlinien für VNET-Dienstendpunkte werden derzeit in einem Application Gateway-Subnetz nicht unterstützt.
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
Wichtig
Obwohl ein /24-Subnetz für die Bereitstellung von Application Gateway v2 SKU nicht erforderlich ist, wird es dringend empfohlen. Ein /24-Subnetz stellt sicher, dass Application Gateway v2 über ausreichend Platz für die automatische Skalierung und Wartungsupgrades verfügt.
Sie sollten sicherstellen, dass das Application Gateway v2-Subnetz über ausreichend Adressraum verfügt, um die Anzahl der Instanzen aufzunehmen, die für die Verarbeitung des maximal zu erwartenden Datenverkehrs erforderlich sind. Wenn Sie die maximale Anzahl von Instanzen angeben, sollte das Subnetz mindestens für so viele Adressen ausgelegt sein. Informationen zur Kapazitätsplanung für die Anzahl von Instanzen finden Sie unter Details zur Anzahl der Instanzen.
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.
Tipp
IP-Adressen werden ab dem Anfang des definierten Subnetzbereichs für Gatewayinstanzen zugeordnet. Da Instanzen aufgrund der Einrichtung von Gateways oder Skalierungsereignissen erstellt und entfernt werden, kann es schwierig werden, die nächste verfügbare Adresse im Subnetz zu ermitteln. Um die nächste Adresse bestimmen zu können, die für ein zukünftiges Gateway verwendet werden soll, und über ein zusammenhängendes Adressierungsdesign für Front-End-IP-Adressen verfügen zu können, sollten Sie die Zuweisung von Front-End-IP-Adressen aus der oberen Hälfte des definierten Teilmengenbereichs in Betracht ziehen.
Wenn der Subnetzadressraum beispielsweise 10.5.5.0/24 ist, erwägen Sie, die private Frontend-IP-Konfiguration Ihrer Gateways ab 10.5.5.254 und dann mit 10.5.5.253, 10.5.5.252, 10.5.5.251 usw. für zukünftige Gateways festzulegen.
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.
Hinweis
Wenn Sie benutzerdefinierte DNS-Server im virtuellen Anwendungsgateway verwenden, muss der DNS-Server in der Lage sein, öffentliche Internetnamen aufzulösen. Für das Anwendungsgateway ist diese Funktion erforderlich.
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.
Hinweis
Möglicherweise müssen Sie nach Änderungen der Rollenzuweisung genügend Zeit für die Aktualisierung des Azure Resource Manager-Caches einplanen.
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
Hinweis
Wir empfehlen die Verwendung der AFEC-Bereitstellung nur als Übergangslösung, bis Sie die richtige Berechtigung erteilen. Sie müssen die Korrektur der Berechtigungen für alle anwendbaren Benutzer (und Dienstprinzipale) priorisieren und dann die Registrierung dieses AFEC-Flags aufheben, um die Berechtigungsüberprüfung in der virtuellen Netzwerkressource wieder einzuführen. Es wird empfohlen, dass Sie nicht dauerhaft von dieser AFEC-Methode abhängen, da sie in Zukunft entfernt wird.
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.
Hinweis
Sicherheitsadministratorregeln von Azure Virtual Network Manager gelten für Application Gateway-Subnetze, die nur Anwendungsgateways enthalten, bei denen die Netzwerkisolation aktiviert ist. Subnetze mit Anwendungsgateways mit deaktivierter Netzwerkisolation verfügen nicht über Sicherheitsadministratorregeln.
Netzwerksicherheitsgruppen
Sie können NSGs für Ihr Anwendungsgateway-Subnetz verwenden, beachten Sie jedoch einige wichtige Punkte und Einschränkungen.
Wichtig
Diese NSG-Einschränkungen werden aufgehoben, wenn Sie die Bereitstellung des privaten Anwendungsgateways (Vorschau) verwenden.
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.
| Quelle | Quellports | Destination | Zielports | Protocol | Zugriff |
|---|---|---|---|---|---|
<as per need> |
Any | <Subnet IP Prefix> |
<listener ports> |
TCP | Allow |
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.
| Quelle | Quellports | Destination | Zielports | Protocol | Zugriff |
|---|---|---|---|---|---|
<as per need> |
Any | <Public and Private<br/>frontend IPs> |
<listener ports> |
TCP | Allow |
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
| Quelle | Quellports | Destination | Zielports | Protocol | Zugriff |
|---|---|---|---|---|---|
| GatewayManager | Any | Any | <as per SKU given above> |
TCP | Allow |
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.
| Quelle | Quellports | Destination | Zielports | Protocol | Zugriff |
|---|---|---|---|---|---|
| AzureLoadBalancer | Any | Any | Any | Any | Allow |
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.
| Quelle | Quellports | Destination | Zielports | Protocol | Zugriff |
|---|---|---|---|---|---|
| Any | Any | Internet | Any | Any | Allow |
Hinweis
Anwendungsgateways, für die keine Netzwerkisolation aktiviert ist, erlauben keinen Datenverkehr zwischen Peer-VNets, wenn Datenverkehr zum virtuellen Remotenetzwerk zulassen deaktiviert ist.
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:
Wichtig
Das Verwenden benutzerdefinierter Routen im Application Gateway-Subnetz kann dazu führen, dass der Integritätsstatus in der Ansicht der Back-End-Integrität als Unbekannt angezeigt wird. Außerdem können bei der Generierung von Application Gateway-Protokollen und -Metriken Fehler auftreten. Wir empfehlen, keine UDRs im Anwendungsgateway-Subnetz zu verwenden, damit Sie den Zustand des Back-Ends, die Protokolle und Metriken einsehen können.
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
Warnung
Eine fehlerhafte Konfiguration der Routingtabelle kann zu asymmetrischer Routenplanung in Application Gateway v2 führen. Stellen Sie sicher, dass der gesamte Datenverkehr der Verwaltungs-/Steuerungsebene direkt an das Internet und nicht über ein virtuelles Gerät gesendet wird. Protokollierung, Metriken und CRL-Überprüfungen können ebenfalls betroffen sein.
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:
- Erstellen Sie eine Routingtabelleressource in Azure.
- Deaktivieren Sie den Parameter Routenverteilung des Gateways für virtuelle Netzwerke.
- 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:
Wechseln Sie zu der von AKS erstellten Ressourcengruppe. Der Name der Ressourcengruppe sollte mit
MC_beginnen.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.
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.