Überlegungen zum Netzwerkbetrieb in einer App Service-Umgebung

Wichtig

In diesem Artikel wird die App Service-Umgebung v2 beschrieben, die mit isolierten App Service-Plänen verwendet wird. App Service-Umgebung v2 wird am 31. August 2024 eingestellt. Für die App Service-Umgebung steht eine neue Version zur Verfügung. Diese ist benutzerfreundlicher und basiert auf einer leistungsfähigeren Infrastruktur. Weitere Informationen zu dieser neuen Version finden Sie unter Einführung in die App Service-Umgebung. Wenn Sie derzeit App Service-Umgebung v2 verwenden, führen Sie die Schritte in diesem Artikel aus, um zur neuen Version zu migrieren.

Ab dem 29. Januar 2024 können Sie keine neuen Ressourcen für die App Service-Umgebung v2 mehr mit einer der verfügbaren Methoden erstellen, darunter ARM-/Bicep-Vorlagen, Azure Portal, Azure CLI oder REST-API. Sie müssen vor dem 31. August 2024 zur App Service-Umgebung v3 migrieren, um die Löschung von Ressourcen und Datenverlust zu verhindern.

Die App Service-Umgebung ist eine Bereitstellung von Azure App Service in einem Subnetz in Ihrem virtuellen Azure-Netzwerk. Es gibt zwei Bereitstellungstypen für eine App Service-Umgebung (ASE):

• Externen: Diese Art der Bereitstellung macht die gehosteten Apps über eine IP-Adresse verfügbar, auf die im Internet zugegriffen werden kann. Weitere Informationen finden Sie unter Erstellen einer App Service-Umgebung.
• Interner Lastenausgleich: Diese Art der Bereitstellung macht die gehosteten Apps auf einer IP-Adresse in Ihrem virtuellen Netzwerk verfügbar. Der interne Endpunkt ist ein interner Lastenausgleich. Weitere Informationen finden Sie unter Erstellen und Verwenden einer App Service-Umgebung für internen Lastenausgleich.

Hinweis

In diesem Artikel wird die App Service-Umgebung v2 beschrieben, die mit isolierten App Service-Plänen verwendet wird.

Unabhängig vom Bereitstellungstyp verfügen alle App Service-Umgebungen über eine öffentliche virtuelle IP-Adresse (VIP). Diese VIP wird für eingehenden Verwaltungsdatenverkehr und als Adresse verwendet, wenn Sie Aufrufe von der App Service-Umgebung an das Internet tätigen. Solche Aufrufe verlassen das virtuelle Netzwerk über die VIP, die für die App Service-Umgebung zugewiesen ist.

Wenn die Apps Ressourcen in Ihrem virtuellen Netzwerk oder über ein VPN aufrufen, ist die Quell-IP eine der IPs im Subnetz. Da sich die ASE im virtuellen Netzwerk befindet, hat sie ohne zusätzliche Konfiguration auch Zugriff auf Ressourcen im virtuellen Netzwerk. Wenn das virtuelle Netzwerk mit Ihrem lokalen Netzwerk verbunden ist, verfügen die Apps ohne zusätzliche Konfiguration über Zugriff auf die dort enthaltenen Ressourcen.

 

Wenn Sie über eine App Service-Umgebung mit einer externen Bereitstellung verfügen, ist die öffentliche VIP auch der Endpunkt, in den Ihre Apps für Folgendes aufgelöst werden:

• HTTP/S
• FTP/S
• Webbereitstellung
• Remotedebuggen

Wenn Sie über eine App Service-Umgebung mit einer internen Load Balancer-Bereitstellung verfügen, ist die Adresse der internen Adresse der Endpunkt für HTTP/S, FTP/S, Webbereitstellung und Remotedebuggen.

Subnetzgröße

Nachdem die App Service-Umgebung bereitgestellt wurde, können Sie die Größe des Subnetzes, das zum Hosten verwendet wird, nicht ändern. Die ASE verwendet eine Adresse für jede Infrastrukturrolle sowie für jede Instanz eines isolierten App Service-Plans. Darüber hinaus verwendet das Azure-Netzwerk fünf Adressen für jedes subnetz, das erstellt wird.

Eine ASE ohne App Service-Pläne verwendet 12 Adressen, bevor Sie eine App erstellen. Wenn Sie die interne Load Balancer-Bereitstellung verwenden, werden 13 Adressen verwendet, bevor Sie eine App erstellen. Beachten Sie beim aufskalieren, dass Infrastrukturrollen bei jedem Vielfachen von 15 und 20 Ihrer App Service Planinstanzen hinzugefügt werden.

Wichtig

Nichts anderes kann sich im Subnetz befinden, aber die App Service-Umgebung. Achten Sie darauf, einen Adressbereich auszuwählen, der auf künftiges Wachstum ausgelegt ist. Diese Einstellung kann später nicht geändert werden. Es wird eine Größe von /24 mit 256 Adressen empfohlen.

Wenn Sie hoch- oder herunterskalieren, werden neue Rollen der entsprechenden Größe hinzugefügt und Ihre Workloads werden dann von der aktuellen Größe auf die Zielgröße migriert. Die ursprünglichen VMs werden erst nach der Migration der Workloads entfernt. Wenn Sie z. B. eine App Service-Umgebung mit 100 App Service Planinstanzen hatten, benötigen Sie einen Zeitraum, in dem Sie die doppelte Anzahl von VMs benötigen.

Eingehende und ausgehende Abhängigkeiten

In den folgenden Abschnitten werden Abhängigkeiten behandelt, die für Ihre App Service-Umgebung zu beachten sind. In einem anderen Abschnitt werden DNS-Einstellungen erläutert.

Eingehende Abhängigkeiten

Damit die App Service-Umgebung ausgeführt werden kann, müssen die folgenden Ports geöffnet sein:

Zweck	From	To
Verwaltung	App Service-Verwaltungsadressen	App Service-Umgebungssubnetz: 454, 455
App Service-Umgebung interne Kommunikation	App Service-Umgebungssubnetz: Alle Ports	App Service-Umgebungssubnetz: Alle Ports
Azure Load Balancer eingehend zulassen	Azure Load Balancer	App Service-Umgebungssubnetz: 16001

Die Ports 7564 und 1221 können bei einer Portüberprüfung als geöffnet angezeigt werden. Diese antworten mit einer IP-Adresse und keinen weiteren Informationen. Sie können sie bei Bedarf blockieren.

Zusätzlich zur Systemüberwachung ermöglicht der eingehende Verwaltungsdatenverkehr die Steuerung und Kontrolle der ASE. Die Quelladressen für diesen Datenverkehr sind unterASE-Verwaltungsadressen aufgeführt. Die Netzwerksicherheitskonfiguration muss den Zugriff über die IP-Adressen der Verwaltung für die App Service-Umgebung an den Ports 454 und 455 zulassen. Wenn Sie den Zugriff von diesen Adressen blockieren, wird Ihr ASE fehlerhaft und dann entsprechend ausgesetzt. Der TCP-Datenverkehr, der über die Ports 454 und 455 eintrifft, muss wieder vom gleichen VIP ausgehen, sonst haben Sie ein asymmetrisches Routingproblem.

Viele Ports im Subnetz werden für die Kommunikation zwischen internen Komponenten verwendet, und sie können sich ändern. Deshalb muss auf alle Ports im Subnetz aus dem Subnetz zugegriffen werden können.

Für die Kommunikation zwischen dem Azure Load Balancer und dem ASE-Subnetz müssen mindestens die Ports 454, 455 und 16001 geöffnet sein. Wenn Sie eine interne Load Balancer-Bereitstellung verwenden, können Sie den Datenverkehr auf die Ports 454, 455, 16001 sperren. Wenn Sie eine externe Bereitstellung verwenden, müssen Sie die normalen App-Zugriffsports berücksichtigen. Dies sind insbesondere die folgenden:

Zweck	Ports
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Remotedebuggen in Visual Studio	4020, 4022, 4024
Web Deploy-Dienst	8172

Wenn Sie die Anwendungsports blockieren, könnte zwar Ihre ASE noch funktionieren, aber Ihre App möglicherweise nicht mehr. Wenn Sie von der App zugewiesene IP-Adressen mit einer externen Bereitstellung verwenden, müssen Sie Datenverkehr von den IP-Adressen, die Ihren Apps zugewiesen sind, an das Subnetz zulassen. Wechseln Sie im App Service-Umgebung-Portal zu IP-Adressen,und sehen Sie sich die Ports an, von denen Sie Datenverkehr zulassen müssen.

Ausgehende Abhängigkeiten

Für den ausgehenden Zugriff ist ein App Service-Umgebung von mehreren externen Systemen abhängig. Viele dieser Systemabhängigkeiten werden über DNS-Namen festgelegt und lassen sich keiner festen IP-Adressengruppe zuordnen. Somit erfordert die ASE den ausgehenden Zugriff aus dem Subnetz auf alle externen IP-Adressen über eine Vielzahl von Ports.

Die ASE kommuniziert über folgende Ports mit Adressen, auf die über das Internet zugegriffen werden kann:

Verwendung	Ports
DNS	53
NTP	123
CRL, Windows-Updates, Linux-Abhängigkeiten, Azure-Dienste	80/443
Azure SQL	1433
Überwachung	12000

Die ausgehenden Abhängigkeiten sind unter Sperren eines App Service-Umgebung aufgeführt. Wenn die App Service-Umgebung den Zugriff auf ihre Abhängigkeiten verliert, funktioniert sie nicht mehr. Wenn dies für einen längeren Zeitraum geschieht, wird er angehalten.

Kunden-DNS

Wenn das virtuelle Netzwerk mit einem kundendefinierten DNS-Server konfiguriert ist, wird es von den Workloads des Mandanten verwendet. Der App Service-Umgebung verwendet Azure DNS zu Verwaltungszwecken. Wenn das virtuelle Netzwerk mit einem vom Kunden ausgewählten DNS-Server konfiguriert ist, muss dieser DNS-Server aus dem Subnetz erreichbar sein.

Hinweis

Storage Bereitstellungen oder Pulls von Containerimages in App Service-Umgebung v2 können kein kundendefiniertes DNS im virtuellen Netzwerk oder über die WEBSITE_DNS_SERVER App-Einstellung verwenden.

Sie können die DNS-Auflösung Ihrer Web-App mit dem Konsolenbefehl nameresolver testen. Wechseln Sie zum Debugfenster in Ihrer scm Website für Ihre App oder zur App im Portal, und wählen Sie die Konsole aus. Über die Shell-Eingabeaufforderung können Sie den Befehl nameresolver zusammen mit dem DNS-Namen ausgeben, den Sie suchen möchten. Das Ergebnis, das Sie erhalten, ist identisch mit dem, das Ihre App bei gleicher Suche erhalten würde. Wenn Sie nslookup verwenden, führen Sie stattdessen einen Lookup mithilfe von Azure DNS durch.

Wenn Sie die DNS-Einstellung des virtuellen Netzwerks ändern, in dem sich Ihre ASE befindet, müssen Sie neu starten. Um einen Neustart zu vermeiden, ist es eine gute Idee, Ihre DNS-Einstellungen für Ihr virtuelles Netzwerk zu konfigurieren, bevor Sie Ihre App Service-Umgebung erstellen.

Portalabhängigkeiten

Zusätzlich zu den in den vorherigen Abschnitten beschriebenen Abhängigkeiten sollten Sie einige zusätzliche Aspekte beachten, die sich auf die Portalerfahrung beziehen. Einige der Funktionen im Azure-Portal hängen vom direkten Zugriff auf den Dienststeuerungs-Manager (SCM) ab. Zu jeder App in Azure App Service gibt es zwei URLs. Die erste URL dient dem Zugriff auf Ihre App. Die zweite URL dient dem Zugriff auf den SCM-Standort, der auch als Kudu-Konsole bezeichnet wird. Funktionen, die den SCM-Standort nutzen:

• Webaufträge
• Functions
• Protokollstreaming
• Kudu
• Erweiterungen
• Prozess-Explorer
• Konsole

Bei Verwendung eines internen Lastenausgleichs ist der SCM-Standort von außerhalb des virtuellen Netzwerks nicht zugänglich. Einige Features funktionieren nicht über das App-Portal, weil sie Zugriff auf den SCM-Standort einer App benötigen. Anstatt das Portal zu verwenden, können Sie eine direkte Verbindung mit dem SCM-Standort herstellen.

Wenn Ihr interner Lastenausgleich der Domainname contoso.appserviceenvironment.net ist und Ihr App-Name testapp ist, wird die App unter testapp.contoso.appserviceenvironment.net erreicht. Die SCM-Website, die mit ihr verbunden ist, wird unter testapp.scm.contoso.appserviceenvironment.net erreicht.

IP-Adressen

Ein App Service-Umgebung verfügt über einige IP-Adressen, die Sie beachten sollten. Sie lauten wie folgt:

• Öffentliche eingehende IP-Adresse: Für den App-Datenverkehr in einer externen ASE und für den Verwaltungsdatenverkehr sowohl in externen als auch in internen Bereitstellungen.
• Ausgehende öffentliche IP-Adresse: Wird als "from"-IP für ausgehende Verbindungen verwendet, die das virtuelle Netzwerk verlassen. Diese Verbindungen werden nicht über ein VPN weitergeleitet.
• IP-Adresse des internen Lastenausgleichs: Diese Adresse ist nur in einer internen Bereitstellung vorhanden.
• Von der App zugewiesene IP-basierte TLS/SSL-Adressen: Diese Adressen sind nur bei einer externen Bereitstellung möglich, und wenn die IP-basierte TLS/SSL-Bindung konfiguriert ist.

All diese IP-Adressen sind über die ASE-Benutzeroberfläche im Azure-Portal sichtbar. Wenn Sie über eine interne Bereitstellung verfügen, wird die IP-Adresse für den internen Lastenausgleich aufgelistet.

Hinweis

Diese IP-Adressen ändern sich nicht, solange Ihr App Service-Umgebung ausgeführt wird. Wenn Ihre App Service-Umgebung angehalten und dann wiederhergestellt wird, ändern sich die verwendeten Adressen. Die normale Ursache für eine Unterbrechung ist, wenn Sie den eingehenden Verwaltungszugriff blockieren oder den Zugriff auf eine Abhängigkeit blockieren.

Von der App zugewiesene IP-Adressen

Mit einer externen Bereitstellung können Sie einzelnen Apps IP-Adressen zuweisen. Dies ist mit einer internen Bereitstellung nicht zu erreichen. Weitere Informationen zum Konfigurieren einer eigenen IP-Adresse für Ihre App finden Sie unter Schützen eines benutzerdefinierten DNS-Namens mit einer TLS-Bindung in Azure App Service.

Wenn eine App über eine eigene IP-basierte SSL-Adresse verfügt, reserviert die ASE zwei Ports für die Zuordnung zu dieser IP-Adresse. Ein Port wird für den HTTP-Datenverkehr verwendet, während der andere Port für den HTTPS-Datenverkehr bestimmt ist. Diese Ports sind im Abschnitt IP-Adressen Ihres App Service-Umgebung-Portals aufgeführt. Der Datenverkehr muss in der Lage sein, diese Ports von der VIP zu erreichen. Andernfalls kann nicht auf die Apps zugegriffen werden. Diese Anforderung ist beim Konfigurieren von Netzwerksicherheitsgruppen (NSGs) unbedingt zu berücksichtigen.

Netzwerksicherheitsgruppen

Netzwerksicherheitsgruppen bieten die Möglichkeit, den Netzwerkzugriff innerhalb eines virtuellen Netzwerks zu steuern. Wenn Sie das Portal verwenden, gibt es auf der niedrigsten Prioritätsstufe eine implizite Ablehnungsregel, durch die alles abgelehnt wird. Sie erstellen also Ihre eigenen Zulassungsregeln.

Sie haben keinen Zugriff auf die VMs, die zum Hosten der App Service-Umgebung selbst verwendet werden. Sie sind in einem Abonnement, das von Microsoft verwaltet wird. Wenn Sie den Zugriff auf die Apps beschränken möchten, legen Sie im Subnetz Netzwerksicherheitsgruppen fest. Achten Sie dabei sorgfältig auf die Abhängigkeiten. Wenn Sie Abhängigkeiten blockieren, funktioniert die App Service-Umgebung nicht mehr.

NSGs können Sie über das Azure-Portal und über PowerShell konfiguriert werden. Die folgenden Informationen beziehen sich auf das Azure-Portal. NSGs können Sie unter Netzwerk im Portal als Ressource der obersten Ebene erstellen.

Die erforderlichen Einträge in einer NSG sind, um Datenverkehr zuzulassen:

Eingehend

• TCP aus dem IP-Diensttag AppServiceManagement an Port 454, 455
• TCP aus dem Lastenausgleich an Port 16001
• Vom App Service-Umgebung Subnetz zum App Service-Umgebung Subnetz an allen Ports

Ausgehend

• UDP an alle IPs über Port 53
• UDP an alle IPs an Port 123
• TCP an alle IPs an den Ports 80 und 443
• TCP an das IP-Diensttag Sql an Port 1433
• TCP an alle IPs an Port 12000
• Zum App Service-Umgebung Subnetz an allen Ports

Diese Ports umfassen nicht die Ports, die Ihre Apps zur erfolgreichen Verwendung benötigen. Angenommen, Ihre App muss einen MySQL-Server an Port 3306 aufrufen. Das Network Time Protocol (NTP) an Port 123 ist das vom Betriebssystem verwendete Zeitsynchronisierungsprotokoll. Die NTP-Endpunkte sind nicht spezifisch für App Services, können je nach Betriebssystem variieren und sind nicht in einer klar definierten Liste von Adressen enthalten. Um Zeitsynchronisierungsprobleme zu vermeiden, müssen Sie den UDP-Datenverkehr an alle Adressen an Port 123 zulassen. Der ausgehende TCP-Datenverkehr zu Port 12000 dient der Systemunterstützung und -analyse. Die Endpunkte sind dynamisch und nicht in einem klar definierten Satz von Adressen enthalten.

Die normalen App-Zugriffsports sind:

Zweck	Ports
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Remotedebuggen in Visual Studio	4020, 4022, 4024
Web Deploy-Dienst	8172

Eine Standardregel ermöglicht den IPs im virtuellen Netzwerk die Kommunikation mit dem Subnetz. Eine weitere Standardregel ermöglicht dem Lastenausgleich (auch als öffentliche VIP-Adresse bezeichnet) die Kommunikation mit der ASE. Sie können die Standardregeln anzeigen lassen, indem Sie (neben dem Symbol Hinzufügen) auf Standardregeln klicken.

Wenn Sie eine Regel zum Ablehnen aller anderen Regeln vor die Standardregeln setzen, verhindern Sie Datenverkehr zwischen der VIP und der App Service-Umgebung. Wenn Sie Datenverkehr aus dem virtuellen Netzwerk verhindern möchten, fügen Sie eine eigene Regel zum Zulassen von eingehendem Datenverkehr hinzu. Verwenden Sie eine auf AzureLoadBalancer festgelegte Quelle mit dem Ziel Beliebig und einem Portbereich von *. Da die NSG-Regel auf das Subnetz angewendet wird, müssen Sie kein spezifisches Ziel angeben.

Wenn Sie der App eine IP-Adresse zugewiesen haben, müssen Sie die Ports geöffnet halten. Sie können die Ports anzeigen lassen, indem Sie App Service-Umgebung>IP-Adressen auswählen.  

Nach der Festlegung Ihrer NSGs müssen diese dem Subnetz zugewiesen werden. Wenn Sie das virtuelle Netzwerk oder -Subnetz nicht kennen, können Sie es sich auf dem ASE-Portal anzeigen lassen. Um die NSG Ihrem Subnetz zuzuweisen, öffnen Sie die Benutzeroberfläche des Subnetzes, und wählen Sie die NSG aus.

Routen

Bei der Tunnelerzwappung legen Sie Routen in Ihrem virtuellen Netzwerk fest, sodass der ausgehende Datenverkehr nicht direkt in das Internet übertragen wird. Stattdessen fließt der Datenverkehr an eine andere Stelle, z. B. ein Azure ExpressRoute Gateway oder ein virtuelles Gerät. Wenn Sie Ihre ASE auf diese Weise konfigurieren müssen, finden Sie weitere Informationen unter Konfigurieren Ihrer App Service-Umgebung mit Tunnelerzwingung.

Wenn Sie eine App Service-Umgebung im Portal erstellen, erstellen Sie automatisch eine Reihe von Routingtabellen im Subnetz. Diese Routen weisen einfach an, ausgehenden Datenverkehr direkt an das Internet zu senden.

Führen Sie diese Schritte aus, um die gleichen Routen manuell zu erstellen:

1. Wechseln Sie zum Azure-Portal und wählen Sie Netzwerk>Routentabellen aus.

2. Erstellen Sie eine neue Routentabelle in derselben Region wie Ihr virtuelles Netzwerk.

3. Wählen Sie in der Benutzeroberfläche Ihrer Routentabelle Routen>Hinzufügen.

4. Legen Sie als Typ des nächsten HopsInternet und als Adresspräfix0.0.0.0/0 fest. Wählen Sie Speichern aus.

   Folgendes sollte angezeigt werden:

   

5. Nachdem Sie die neue Routingtabelle erstellt haben, wechseln Sie zum Subnetz. Wählen Sie aus der Liste im Portal Ihre Routentabelle aus. Nachdem Sie die Änderung gespeichert haben, sollten die für Ihr Subnetz vermerkten NSGs und Routen angezeigt werden.

   

Dienstendpunkte

Dienstendpunkte ermöglichen Ihnen das Beschränken des Zugriffs auf mehrinstanzenfähige Dienste auf eine Gruppe von virtuellen Azure-Netzwerken und Subnetzen. Weitere Informationen finden Sie unter Dienstendpunkte im virtuellen Netzwerk.

Wenn Sie die Dienstendpunkte auf einer Ressource aktivieren, werden Routen erstellt, die eine höhere Priorität als alle anderen Routen haben. Wenn Sie Dienstendpunkte für einen Beliebigen Azure-Dienst mit einem App Service-Umgebung mit Tunnel erzwingen verwenden, wird der Datenverkehr zu diesen Diensten nicht getunnelt.

Wenn Dienstendpunkte in einem Subnetz mit einer Azure SQL-Instanz aktiviert werden, müssen für alle Azure SQL-Instanzen, mit denen aus diesem Subnetz Verbindungen hergestellt werden, Dienstendpunkte aktiviert sein. Falls Sie aus demselben Subnetz auf mehrere Azure SQL-Instanzen zugreifen möchten, ist es nicht möglich, dass Sie Dienstendpunkte nur auf einer Azure SQL-Instanz aktivieren, aber nicht auf einer anderen Instanz. In Bezug auf Dienstendpunkte verhält sich kein anderer Azure-Dienst so wie Azure SQL. Wenn Sie Dienstendpunkte mit Azure Storage aktivieren, sperren Sie den Zugriff auf diese Ressource aus Ihrem Subnetz. Sie können jedoch auch dann auf andere Azure Storage Konten zugreifen, wenn für sie keine Dienstendpunkte aktiviert sind.