Freigeben über

Netzwerkoptionen von Azure Functions

  • Artikel

In diesem Artikel werden die Netzwerkfunktionen beschrieben, die für die Hostingoptionen von Azure Functions zur Verfügung stehen. Die folgenden Netzwerkoptionen können als Netzwerkfunktionen für eingehenden und ausgehenden Datenverkehr kategorisiert werden. Mit Funktionen für eingehenden Datenverkehr können Sie den Zugriff auf Ihre App einschränken, während Funktionen für ausgehenden Datenverkehr es Ihnen ermöglichen, Ihre App mit Ressourcen zu verbinden, die durch ein virtuelles Netzwerk gesichert sind. Darüber hinaus können Sie steuern, wie ausgehender Datenverkehr weitergeleitet wird.

Die Hostingmodelle weisen verschiedene verfügbare Ebenen der Netzwerkisolation auf. Durch Auswahl der jeweils richtigen Ebene lassen sich Ihre Anforderungen an die Netzwerkisolation erfüllen.

Funktion Flex-Verbrauchstarif Verbrauchstarif Premium-Plan Dedizierter Plan/ASE Container-Apps1
IP-Einschränkungen für eingehenden Datenverkehr ✔ ✔ ✔ ✔ ✔
Eingehende private Endpunkte ✔ ✔ ✔
Integration in ein virtuelles Netzwerk ✔ ✔2 ✔3 ✔
IP-Einschränkungen für ausgehenden Datenverkehr ✔ ✔ ✔ ✔
  1. Weitere Informationen finden Sie unter Netzwerk in der Azure Container Apps-Umgebung.
  2. Bei der Arbeit mit virtuellen Netzwerktriggern sind besondere Überlegungen vorzunehmen.
  3. Nur der dedizierte/ASE-Plan unterstützt die durch vom Gateway benötigte Integration des virtuellen Netzwerks.

Schnellstart für Ressourcen

Verwenden Sie die folgenden Ressourcen, um schnell mit den Netzwerkszenarien von Azure Functions beginnen zu können. Auf diese Ressourcen wird im gesamten Artikel verwiesen.

Netzwerkfeatures für Eingang

Mit den folgenden Features können Sie eingehende Anforderungen an Ihre Funktions-App filtern.

Einschränkungen für eingehenden Zugriff

Mit Zugriffseinschränkungen können Sie eine nach Priorität sortierte Liste mit IP-Adressen definieren, über die der Zugriff auf Ihre App zugelassen bzw. abgelehnt wird. Die Liste kann IPv4- und IPv6-Adressen oder bestimmte Subnetze eines virtuellen Netzwerks mit Dienstendpunkten enthalten. Wenn mindestens ein Eintrag vorhanden ist, enthält die Liste am Ende einen impliziten Eintrag vom Typ „Alle ablehnen“. IP-Einschränkungen können für alle Hostingoptionen für Funktionen verwendet werden.

Zugriffseinschränkungen sind für Flex-Verbrauch, Elastic Premium, Verbrauch und App Service verfügbar.

Hinweis

Mit den geltenden Netzwerkbeschränkungen können Sie nur in Ihrem virtuellen Netzwerk bereitstellen, oder wenn Sie die IP-Adresse des Computers, mit dem Sie auf das Azure-Portal zugreifen, der Liste der sicheren Empfänger hinzugefügt haben. Sie können die Funktion jedoch weiterhin über das Portal verwalten.

Weitere Informationen finden Sie unter Azure App Service – statische Zugriffseinschränkungen.

Private Endpunkte

Ein privater Azure-Endpunkt ist eine Netzwerkschnittstelle, die Sie privat und sicher mit einem Dienst verbindet, der von Azure Private Link unterstützt wird. Ein privater Endpunkt verwendet eine private IP-Adresse aus Ihrem virtuellen Netzwerk und macht den Dienst so in Ihrem virtuellen Netzwerk verfügbar.

Sie können einen privaten Endpunkt für ihre Funktionen verwenden, die in den Plänen Flex Consumption, Elastic Premium und Dedicated (App Service) gehostet werden.

Wenn Sie Aufrufe an private Endpunkte durchführen möchten, müssen Sie sicherstellen, dass Ihre DNS-Suchen zu dem privaten Endpunkt aufgelöst werden. Sie können dieses Verhalten auf eine der folgenden Arten erzwingen:

  • Integrieren mit private Azure DNS-Zonen. Wenn Ihr virtuelles Netzwerk nicht über einen benutzerdefinierten DNS-Server verfügt, erfolgt dies automatisch.
  • Verwalten des privaten Endpunkts im DNS-Server, der von Ihrer App verwendet wird. Um einen privaten Endpunkt zu verwalten, müssen Sie die Endpunktadresse kennen und einen A-Datensatz verwenden, um auf den Endpunkt zu verweisen, den Sie erreichen möchten.
  • Konfigurieren Ihres eigenen DNS-Servers zur Weiterleitung an private Azure DNS-Zonen.

Weitere Informationen finden Sie unter Verwenden privater Endpunkte für Web-Apps.

Konfigurieren Sie zum Aufrufen anderer Dienste, die über eine Verbindung mit einem privaten Endpunkt verfügen (z. B. Speicher oder Service Bus), Ihre App so, dass sie ausgehende Aufrufe an private Endpunkte ausführt. Weitere Details zur Verwendung privater Endpunkte mit dem Speicherkonto für Ihre Funktions-App finden Sie unter Einschränken Ihres Speicherkontos auf ein virtuelles Netzwerk.

Dienstendpunkte

Mithilfe von Dienstendpunkten können Sie viele Azure-Dienste auf ausgewählte Subnetze des virtuellen Netzwerks beschränken, um eine höhere Sicherheitsstufe zu gewährleisten. Mit der regionalen Integration virtueller Netzwerke können Ihre Funktions-Apps Azure-Dienste erreichen, die mit Dienstendpunkten geschützt sind. Diese Konfiguration wird für alle Pläne unterstützt, welche die Integration in ein virtuelles Netzwerk unterstützen. Führen Sie die folgenden Schritte aus, um auf einen gesicherten Dienstendpunkt zuzugreifen:

  1. Konfigurieren Sie die regionale Integration des virtuellen Netzwerks in Ihre Funktions-App, um eine Verbindung mit einem bestimmten Subnetz herzustellen.
  2. Wechseln Sie zum Zieldienst, und konfigurieren Sie Dienstendpunkte für das Integrationssubnetz.

Weitere Informationen finden Sie unter VNET-Dienstendpunkte.

Verwenden von Dienstendpunkten

Erstellen Sie zum Einschränken des Zugriffs auf ein bestimmtes Subnetz eine Einschränkungsregel vom Typ Virtual Network. Anschließend können Sie das Abonnement, das virtuelle Netzwerk und das Subnetz auswählen, für das Sie den Zugriff zulassen oder ablehnen möchten.

Falls für das von Ihnen ausgewählte Subnetz nicht bereits Dienstendpunkte mit Microsoft.Web aktiviert sind, wird dies automatisch durchgeführt, sofern Sie nicht das Kontrollkästchen Fehlende Microsoft.Web-Dienstendpunkte ignorieren aktivieren. In einem Szenario, bei dem Sie Dienstendpunkte in der App aktivieren möchten, aber nicht im Subnetz, hängt es vor allem davon ab, ob Sie über die Berechtigungen für die Aktivierung im Subnetz verfügen.

Falls die Dienstendpunkte im Subnetz bei Ihnen von einer anderen Person aktiviert werden müssen, sollten Sie das Kontrollkästchen Fehlende Microsoft.Web-Dienstendpunkte ignorieren aktivieren. Ihre App ist für Dienstendpunkte konfiguriert, die Sie später im Subnetz aktivieren.

Screenshot: Bereich „Add IP Restriction“ (IP-Einschränkung hinzufügen) mit Auswahl des Typs „Virtual Network“

Sie können Dienstendpunkte nicht nutzen, um den Zugriff auf Apps einzuschränken, die in einer App Service-Umgebung ausgeführt werden. Wenn Ihre App in einer App Service-Umgebung enthalten ist, können Sie den Zugriff darauf steuern, indem Sie IP-Zugriffsregeln anwenden.

Informationen zum Einrichten von Dienstendpunkten Sie unter Tutorial: Einrichten von privatem Websitezugriff für Azure Functions.

Netzwerkfunktionen für ausgehenden Datenverkehr

Sie können die Funktionen in diesem Abschnitt verwenden, um ausgehende Verbindungen zu verwalten, die von Ihrer App hergestellt werden.

Integration in ein virtuelles Netzwerk

In diesem Abschnitt werden die Funktionen beschrieben, die Functions unterstützt, um Daten zu steuern. die von Ihrer App ausgehen.

Durch die Integration des virtuellen Netzwerks erhält ihre Funktions-App Zugriff auf Ressourcen in Ihrem virtuellen Netzwerk. Nach der Integration wird der gesamte ausgehende Datenverkehr über das virtuelle Netzwerk weitergeleitet. Auf diese Weise kann Ihre App unter Beachtung von Regeln auf private Endpunkte oder Ressourcen zugreifen, die nur den Datenverkehr ausgewählter Subnetze zulassen. Wenn das Ziel eine IP-Adresse außerhalb des virtuellen Netzwerks ist, wird die Quell-IP weiterhin von der in den Eigenschaften Ihrer App aufgeführten Adressen gesendet, sofern Sie nicht ein NAT-Gateway konfiguriert haben.

Azure Functions unterstützt zwei Arten der Integration virtueller Netzwerke:

Informationen zum Einrichten der Integration virtueller Netzwerke finden Sie unter Aktivieren der Integration virtueller Netzwerke.

Regionale Integration des virtuellen Netzwerks

Die Verwendung der regionalen Integration virtueller Netzwerke ermöglicht der App Zugriff auf Folgendes:

  • Ressourcen im selben virtuellen Netzwerk wie Ihre App.
  • Ressourcen in virtuellen Netzwerken, die per Peering mit dem virtuellen Netzwerk verbunden sind, in das Ihre App integriert ist.
  • Durch Dienstendpunkte geschützte Dienste.
  • Ressourcen über Azure ExpressRoute-Verbindungen.
  • Ressourcen über Verbindungen mit Peering, einschließlich von Azure ExpressRoute-Verbindungen.
  • Private Endpunkte

Wenn Sie die regionale Integration virtueller Netzwerke verwenden, können Sie die folgenden Azure-Netzwerkfunktionen nutzen:

  • Netzwerksicherheitsgruppen (NSGs) : Sie können ausgehenden Datenverkehr mit einer NSG blockieren, die in Ihrem Integrationssubnetz platziert ist. Die Regeln für eingehenden Datenverkehr gelten nicht, da Sie die Integration virtueller Netzwerke nicht verwenden können, um eingehenden Zugriff auf Ihre App bereitzustellen.
  • Routingtabellen (UDRs) : Sie können eine Routingtabelle im Integrationssubnetz platzieren, um ausgehenden Datenverkehr an beliebige gewünschte Ziele zu senden.

Hinweis

Wenn Sie den gesamten ausgehenden Datenverkehr in Ihr virtuelles Netzwerk weiterleiten, unterliegt dieser den NSGs und UDRs, die auf Ihr Integrationssubnetz angewendet werden. Wenn das virtuelle Netzwerk integriert ist, wird der ausgehende Datenverkehr Ihrer Funktions-App an öffentliche IP-Adressen weiterhin von den Adressen gesendet, die in den Eigenschaften Ihrer App aufgeführt sind – es sei denn, Sie geben Routen an, die den Datenverkehr an ein anderes Ziel leiten.

Für die regionale Integration virtueller Netzwerke kann Port 25 nicht verwendet werden.

Überlegungen zum Flex Consumption-Plan:

  • Stellen Sie sicher, dass der Microsoft.App-Azure-Ressourcenanbieter für Ihr Abonnement aktiviert ist, indem Sie die folgenden Anweisungen befolgen. Dies ist für die Subnetzdelegierung erforderlich.
  • Die Subnetzdelegierung, die für die Ausführung in einem „Flex Consumption“-Plan erforderlich ist, lautet Microsoft.App/environments. Dies unterscheidet sich von den Elastic Premium- und App Service-Plänen, für die eine andere Delegierungsanforderung gilt.
  • Sie können planen, dass maximal 40 IP-Adressen für eine Funktions-App verwendet werden, auch wenn die App auf über 40 skaliert wird. Wenn Sie beispielsweise 15 Funktions-Apps mit Flex-Verbrauch haben, die in dasselbe Subnetz integriert werden, müssen Sie 15x40 = 600 IP-Adressen planen, die höchstens verwendet werden. Dieser Grenzwert kann geändert werden und wird nicht erzwungen.
  • Das Subnetz darf nicht bereits für andere Zwecke verwendet werden (z. B. für private Endpunkte oder Dienstendpunkte oder an einen anderen Hostingplan oder Dienst delegiert). Sie können zwar dasselbe Subnetz mit mehreren Flex Consumption-Apps teilen, die Netzwerkressourcen werden jedoch für diese Funktions-Apps gemeinsam verwendet. Dies kann dazu führen, dass eine Funktions-App sich auf die Leistung anderer Apps im selben Subnetz auswirkt.

Überlegungen zum Elastic Premium-, Dedicated (App Service)-und Container-Apps-Plan:

  • Die Funktion ist für „Flex Consumption“, „Elastic Premium“ und“ App Service Premium V2“ sowie „Premium V3“ verfügbar. Es ist außerdem im Tarif „Standard“ verfügbar, jedoch nur in neueren App Service-Bereitstellungen. Wenn Sie eine ältere Bereitstellung nutzen, können Sie das Feature nur in einem App Service-Plan vom Typ „Premium V2“ verwenden. Wenn Sie sicherstellen möchten, dass Sie das Feature in einem „Standard“-App Service-Plan verwenden können, erstellen Sie Ihre App in einem „Premium V3“-App Service-Plan. Diese Pläne werden nur für unsere neuesten Bereitstellungen unterstützt. Sie können anschließend nach Bedarf herunterskalieren.
  • Die Funktion kann nicht für Apps im Plan „App Service (isoliert)“ in einer App Service-Umgebung verwendet werden.
  • Die App und das virtuelle Netzwerk müssen sich in derselben Region befinden.
  • Für das Feature ist ein nicht genutztes Subnetz vom Typ /28 oder größer in einem virtuellen Azure Resource Manager-Netzwerk erforderlich.
  • Das Integrationssubnetz kann nur von einem App Service-Plan verwendet werden.
  • Sie können bis zu zwei regionale Integrationen virtueller Netzwerke pro App Service-Plan verwenden. Ein Integrationssubnetz kann von mehreren Apps innerhalb des gleichen App Service-Plans genutzt werden.
  • Ein virtuelles Netzwerk mit einer integrierten App kann nicht gelöscht werden. Entfernen Sie die Integration, bevor Sie das virtuelle Netzwerk löschen.
  • Sie können das Abonnement einer App oder eines Plans nicht ändern, solange eine App mit regionaler VNet-Integration vorhanden ist.

Aktivieren der Integration virtueller Netzwerke

  1. Wählen Sie in Ihrer Funktions-App im Azure-Portal die Option Netzwerk und anschließend unter VNET-Integration die Option Klicken Sie hier, um die Konfiguration auszuführen aus.

  2. Wählen Sie VNET hinzufügen aus.

    Screenshot der Seite „VNet-Integration“, auf der Sie die Integration virtueller Netzwerke in Ihrer App aktivieren können.

  3. Die Dropdownliste enthält alle virtuellen Azure Resource Manager-Netzwerke in Ihrem Abonnement in derselben Region. Wählen Sie das virtuelle Netzwerk aus, das Sie für die Integration verwenden möchten.

    Auswählen des VNETs

    • Die Hostingpläne „Flex Consumption“ und „Elastic Premium“ unterstützen ausschließlich eine regionale Integration virtueller Netzwerke. Wenn sich das virtuelle Netzwerk in derselben Region befindet, erstellen Sie entweder ein neues Subnetz oder wählen ein leeres, bereits vorhandenes aus.

    • Wenn Sie ein virtuelles Netzwerk in einer anderen Region auswählen möchten, müssen Sie über ein virtuelles Netzwerkgateway verfügen, für das Point-to-Site aktiviert ist. Die regionsübergreifende Integration virtueller Netzwerke wird nur für Dedicated-Pläne unterstützt, globale Peerings funktionieren jedoch mit der regionalen Integration virtueller Netzwerke.

Während der Integration wird Ihre App neu gestartet. Wenn die Integration abgeschlossen ist, werden Details zu dem virtuellen Netzwerk angezeigt, in das Sie integriert sind. Standardmäßig ist „Route All“ (Gesamten Datenverkehr weiterleiten) aktiviert, und der gesamte Datenverkehr wird an Ihr virtuelles Netzwerk geroutet.

Wenn Sie ihren privaten Datenverkehr (RFC1918-Datenverkehr) nur weiterleiten möchten, führen Sie die Schritte in diesem App Service-Artikel aus.

Subnetze

Die Integration virtueller Netzwerke hängt von der Verwendung eines dedizierten Subnetzes ab. Wenn Sie ein Subnetz bereitstellen, verliert das Azure-Subnetz von Anfang an fünf IP-Adressen. Für jede Instanz des Elastic Premium- und App Service-Plans wird eine Adresse aus dem Integrationssubnetz verwendet. Wenn Sie Ihre App auf vier Instanzen skalieren, werden vier Adressen verwendet. Für „Flex Consumption“ gilt dies nicht, und Instanzen verwenden IP-Adressen gemeinsam.

In den Plänen „Elastic Premium“ und „Dedicated (App Service)“ wird der erforderliche Adressraum für einen kurzen Zeitraum verdoppelt, wenn Sie die Größe der Instanz hoch- oder herunterskalieren. Dies wirkt sich auf die tatsächlichen, verfügbaren unterstützten Instanzen für eine bestimmte Subnetzgröße aus. Die folgende Tabelle zeigt sowohl die maximal verfügbaren Adressen pro CIDR-Block als auch die Auswirkungen auf die horizontale Skalierung:

CIDR-Blockgröße Maximal verfügbare Adressen Maximale horizontale Skalierung (Instanzen)*
/28 11 5
/27 27 13
/26 59 29

*Geht davon aus, dass irgendwann ein Hoch- oder Herunterskalieren der Größe oder SKU erforderlich ist.

Da die Subnetzgröße nach der Zuweisung nicht mehr geändert werden kann, verwenden Sie ein Subnetz, das für die Aufnahme jedweder Skalierung Ihrer App groß genug ist. Um Probleme mit der Subnetzkapazität für Functions Elastic Premium-Pläne zu vermeiden, sollten Sie /24 mit 256 Adressen für Windows und /26 mit 64 Adressen für Linux verwenden. Beim Erstellen von Subnetzen im Azure-Portal im Rahmen der Integration in das virtuelle Netzwerk ist eine Mindestgröße von /24 oder /26 für Windows bzw. Linux erforderlich.

Der „Flex Consumption“-Plan ermöglicht es mehrere Apps, die in diesem Plan ausgeführt werden, in dasselbe Subnetz zu integrieren. Dies gilt nicht für die Hostingpläne „Elastic Premium“ und „Dedicated (App Service)“. Mit diesen Plänen können nur zwei virtuelle Netzwerke mit jedem „App Service“-Plan verbunden werden. Mehrere Apps aus einem einzelnen „App Service“-Plan können demselben Subnetz beitreten, Apps aus einem anderen Plan können dieses Subnetz jedoch nicht verwenden.

Das Feature wird für Windows- und Linux-Apps vollständig unterstützt, einschließlich benutzerdefinierten Containern. Das Verhalten ist in Windows- und Linux-Apps gleich.

Netzwerksicherheitsgruppen

Sie können Netzwerksicherheitsgruppen verwenden, um Datenverkehr zwischen Ressourcen in Ihrem virtuellen Netzwerk zu steuern. Sie können beispielsweise eine Sicherheitsregel erstellen, die verhindert, dass der ausgehende Datenverkehr Ihrer App eine Ressource in Ihrem virtuellen Netzwerk erreicht oder das Netzwerk verlässt. Diese Sicherheitsregeln gelten für Apps, die für die Integration des virtuellen Netzwerks konfiguriert wurden. Wenn Datenverkehr an öffentliche Adressen blockiert werden soll, muss die Integration des virtuellen Netzwerks sowie die Option „Gesamten Datenverkehr weiterleiten“ aktiviert sein. Die Regeln für eingehenden Datenverkehr in einer NSG gelten nicht für Ihre App, weil sich die VNet-Integration nur auf ausgehenden Datenverkehr von Ihrer App auswirkt.

Um den eingehenden Datenverkehr für Ihre App zu steuern, verwenden Sie das Feature für Zugriffsbeschränkungen. Eine NSG, die auf Ihr Integrationssubnetz angewendet wird, ist unabhängig von den Routen wirksam, die auf Ihr Integrationssubnetz angewendet werden. Wenn die Integration des virtuellen Netzwerks mit aktivierter Option Gesamten Datenverkehr weiterleiten erfolgt ist und Sie über keine Routen verfügen, die sich auf den Datenverkehr der öffentlichen Adresse in Ihrem Integrationssubnetz auswirken, unterliegt der gesamte ausgehende Datenverkehr den NSGs, die Ihrem Integrationssubnetz zugewiesen sind. Ist „Route All“ (Gesamten Datenverkehr weiterleiten) nicht aktiviert, werden NSGs nur auf RFC1918-Datenverkehr angewendet.

Routen

Sie können mithilfe von Routingtabellen ausgehenden Datenverkehr von Ihrer App an beliebige Ziele weiterleiten. Routingtabellen wirken sich standardmäßig nur auf Datenverkehr mit dem Ziel RFC1918 aus. Wenn Gesamten Datenverkehr weiterleiten aktiviert ist, sind alle ausgehenden Aufrufe betroffen. Wenn Route All (Gesamten Datenverkehr weiterleiten) deaktiviert ist, ist nur privater Datenverkehr (RFC1918) von Ihren Routingtabellen betroffen. Routen, die für Ihr Integrationssubnetz festgelegt werden, wirken sich nicht auf Antworten auf eingehende App-Anforderungen aus. Gängige Ziele können Firewallgeräte oder Gateways beinhalten.

Wenn Sie den gesamten ausgehenden Datenverkehr lokal weiterleiten möchten, können Sie eine Routingtabelle verwenden, um den gesamten ausgehenden Datenverkehr an das ExpressRoute-Gateway zu senden. Wenn Sie Datenverkehr nicht an ein Gateway weiterleiten, müssen Sie unbedingt Routen im externen Netzwerk festlegen, über die Antworten zurückgesendet werden.

BGP-Routen (Border Gateway Protocol) wirken sich ebenfalls auf den App-Datenverkehr aus. Wenn Sie über BGP-Routen von einem ExpressRoute-Gateway verfügen, ist der ausgehende Datenverkehr Ihrer App betroffen. BGP-Routen wirken sich standardmäßig nur auf Datenverkehr mit dem Ziel RFC1918 aus. Wenn Ihre Funktions-App in ein virtuelles Netzwerk mit aktivierter Option „Route All“ (Gesamten Datenverkehr weiterleiten) integriert ist, können sich Ihre BGP-Routen auf den gesamten ausgehenden Datenverkehr auswirken.

IP-Einschränkungen für ausgehenden Datenverkehr

IP-Einschränkungen für ausgehenden Datenverkehr sind in einem Flex-Verbrauch-Plan, Elastic Premium-Plan, einem App Service-Plan oder in einer App Service-Umgebung verfügbar. Sie können ausgehende Einschränkungen für das virtuelle Netzwerk konfigurieren, wo Ihre App Service-Umgebung bereitgestellt wird.

Wenn Sie eine Funktions-App in einen Elastic Premium-Tarif oder einen App Service-Plan mit einem virtuellen Netzwerk integrieren, kann die App standardmäßig weiterhin ausgehende Aufrufe ins Internet vornehmen. Durch die Integration Ihrer Funktions-App in ein virtuelles Netzwerk mit aktivierter Option „Route All“ (Gesamten Datenverkehr weiterleiten) erzwingen Sie, dass der gesamte ausgehende Datenverkehr an Ihr virtuelles Netzwerk gesendet wird, in dem gegebenenfalls Netzwerksicherheitsgruppen-Regeln zum Einschränken des Datenverkehrs angewendet werden. Für „Flex Consumption“ wird der gesamte Datenverkehr bereits über das virtuelle Netzwerk weitergeleitet, sodass die Option „Gesamten Datenverkehr weiterleiten“ nicht erforderlich ist.

Informationen zum Steuern der ausgehenden IP-Adresse mithilfe eines virtuellen Netzwerks finden Sie unter Tutorial: Steuern der ausgehenden IP-Adresse von Azure Functions mit einem Azure Virtual Network-NAT-Gateway.

Azure DNS Private Zones

Nachdem Ihre App in Ihr virtuelles Netzwerk integriert wurde, nutzt sie den gleichen DNS-Server, mit dem Ihr virtuelles Netzwerk konfiguriert ist, und funktioniert mit den privaten Azure DNS-Zonen, die mit dem virtuellen Netzwerk verknüpft sind.

Automation

Die folgenden APIs ermöglichen es Ihnen, regionale Integrationen virtueller Netzwerke programmgesteuert zu verwalten:

  • Azure CLI: Verwenden Sie die Befehle az functionapp vnet-integration, um eine regionale Integration des virtuellen Netzwerks hinzuzufügen, aufzulisten oder zu entfernen.
  • ARM-Vorlagen: Die Integration regionaler virtueller Netzwerke kann mithilfe einer Azure Resource Manager-Vorlage aktiviert werden. Ein vollständiges Beispiel finden Sie in dieser Functions-Schnellstartvorlage.

Hybridverbindungen

Hybrid Connections ist ein Feature von Azure Relay, das Sie zum Zugreifen auf Anwendungsressourcen in anderen Netzwerken verwenden können. Es ermöglicht den Zugriff von Ihrer App auf einen Anwendungsendpunkt. Sie können es nicht verwenden, um auf Ihre Anwendung zuzugreifen. Hybrid Connections steht für Funktionen unter Windows in allen Tarifen (mit Ausnahme des Verbrauchstarifs) zur Verfügung.

Bei der Verwendung in Azure Functions entspricht jede Hybridverbindung einer Kombination aus einem einzelnen TCP-Host und einem Port. Dies bedeutet, dass sich der Hybridverbindungsendpunkt in einem beliebigen Betriebssystem und einer beliebigen Anwendung befinden kann, solange der Zugriff über einen TCP-Überwachungsport erfolgt. Das Feature „Hybrid Connections“ verfügt nicht über Informationen zum Anwendungsprotokoll oder zum abzurufenden Inhalt und benötigt diese Informationen auch nicht. Es ermöglicht lediglich den Netzwerkzugriff.

Weitere Informationen finden Sie in der App Service-Dokumentation zu Hybrid Connections. Diese Konfigurationsschritte unterstützen auch Azure Functions.

Wichtig

Hybridverbindungen werden nur unterstützt, wenn Ihre Funktions-App unter Windows ausgeführt wird. Linux-Apps werden nicht unterstützt.

Herstellen einer Verbindung mit Azure Services über ein virtuelles Netzwerk

Durch die Integration des virtuellen Netzwerks kann Ihre Funktions-App auf Ressourcen in einem virtuellen Netzwerk zugreifen. In diesem Abschnitt werden die Punkte beschrieben, die Sie berücksichtigen sollten, wenn Sie Ihre App mit bestimmten Diensten verbinden möchten.

Einschränken Ihres Speicherkontos auf ein virtuelles Netzwerk

Hinweis

Um schnell eine Funktions-App mit privaten Endpunkten bereitzustellen, die für das Speicherkonto aktiviert sind, verwenden Sie diese Vorlage: Funktions-App mit privaten Azure Storage-Endpunkten.

Beim Erstellen einer Funktions-App müssen Sie ein allgemeines Azure Storage-Konto erstellen oder verknüpfen, das Blob-, Queue- und Table Storage unterstützt. Sie können dieses Speicherkonto durch eines ersetzen, das mit Dienstendpunkten oder privaten Endpunkten geschützt ist.

Sie können ein Speicherkonto mit Netzwerkeinschränkungen mit Funktions-Apps in den Plänen „Flex Consumption“, „Elastic Premium“ und „Dedicated (App Service)“ verwenden. Der „Consumption“-Plan wird nicht unterstützt. Für die Pläne „Elastic Premium“ und „Dedicated“ müssen Sie sicherstellen, dass das private Routing für Inhaltsfreigaben konfiguriert ist. Informationen zum Konfigurieren einer Funktions-App mit einem Speicherkonto, das durch ein virtuelles Netzwerk gesichert ist, finden Sie unter Einschränken Ihres Speicherkontos auf ein virtuelles Netzwerk.

Verwenden von Key Vault-Verweisen

Sie können mithilfe von Azure Key Vault-Verweisen Geheimnisse aus Ihrer Azure Key Vault-Instanz in Ihrer Azure Functions-Anwendung verwenden, ohne dass Codeänderungen erforderlich sind. Azure Key Vault ist ein Dienst, der eine zentralisierte Verwaltung von Geheimnissen mit voller Kontrolle über Zugriffsrichtlinien und Überprüfungsverlauf ermöglicht.

Wenn für die App die VNet-Integration konfiguriert ist, können Key Vault-Verweise zum Abrufen von Geheimnissen aus einem Tresor mit Netzwerkeinschränkung verwendet werden.

Trigger für virtuelle Netzwerke (nicht HTTP)

Ihr Workload erfordert möglicherweise, dass Ihre App von einer Ereignisquelle ausgelöst wird, die durch ein virtuelles Netzwerk geschützt ist. Es gibt zwei Möglichkeiten, wenn Ihre App basierend auf der Anzahl der Ereignisse, die von Nicht-HTTP-Triggerquellen empfangen wurden, dynamisch skaliert werden soll:

  • Führen Sie Ihre Funktions-App mit einem Flex Consumption-Plan aus.
  • Führen Sie Ihre Funktions-App in einem Elastic Premium-Plan aus und aktivieren Sie die Unterstützung für virtuelle Netzwerktrigger.

Funktions-Apps, die mit dem Dedicated (App Service)-Plan ausgeführt werden, skalieren nicht dynamisch basierend auf Ereignissen. Stattdessen wird die das horizontale Skalieren durch von Ihnen definierten Regeln für die Autoskalierung bestimmt.

Elastic Premium-Plan mit Triggern für virtuelle Netzwerke

Mit dem Elastic Premium-Plan können Sie Funktionen erstellen, die von Diensten ausgelöst werden, die durch ein virtuelles Netzwerk gesichert sind. Diese Nicht-HTTP-Trigger werden als virtuelle Netzwerktrigger bezeichnet.

Standardmäßig führen virtuelle Netzwerktrigger nicht dazu, dass sie von Ihrer Funktions-App über die Anzahl ihrer vorab aufgewärmten Instanzen hinaus skaliert werden. Bestimmte Erweiterungen unterstützen jedoch virtuelle Netzwerktrigger, die dazu führen, dass sie von Ihrer Funktions-App dynamisch skaliert werden. Sie können diese Überwachung der dynamischen Skalierung in Ihrer Funktions-App für unterstützte Erweiterungen auf eine der folgenden Arten aktivieren:

  1. Navigieren Sie im Azure-Portal zu Ihrer Funktions-App.

  2. Wählen Sie unter Einstellungen die Option Konfiguration aus, und legen Sie dann auf der Registerkarte Einstellungen der Funktionsruntime Überwachung der Runtimeskalierung auf Ein fest.

  3. Wählen Sie Speichern aus, um die Konfiguration der Funktions-App zu aktualisieren, und starten Sie die App neu.

VNETToggle

Tipp

Das Aktivieren der Überwachung virtueller Netzwerktrigger hat möglicherweise Auswirkungen auf die Leistung Ihrer Anwendung, obwohl diese Auswirkung wahrscheinlich sehr gering ist.

Die Unterstützung für die Überwachung der dynamischen Skalierung virtueller Netzwerktrigger ist in der Version 1.x der Funktionsruntime nicht verfügbar.

Die Erweiterungen in dieser Tabelle unterstützen die Überwachung der dynamischen Skalierung virtueller Netzwerktrigger. Um die beste Skalierungsleistung zu erzielen, sollten Sie ein Upgrade auf Versionen durchführen, die auch die zielbasierte Skalierung unterstützen.

Erweiterung (Mindestversion) Nur Überwachung der Runtimeskalierung Mit zielbasierter Skalierung
Microsoft.Azure.WebJobs.Extensions.CosmosDB > 3.0.5 > 4.1.0
Microsoft.Azure.WebJobs.Extensions.DurableTask > 2.0.0 –
Microsoft.Azure.WebJobs.Extensions.EventHubs > 4.1.0 > 5.2.0
Microsoft.Azure.WebJobs.Extensions.ServiceBus > 3.2.0 > 5.9.0
Microsoft.Azure.WebJobs.Extensions.Storage > 3.0.10 > 5.1.0*

* Nur Warteschlangenspeicher.

Wichtig

Wenn Sie die Überwachung virtueller Netzwerktrigger aktivieren, können nur Trigger für diese Erweiterungen dazu führen, dass Ihre App dynamisch skaliert wird. Sie können zwar weiterhin Trigger aus Erweiterungen verwenden, die sich nicht in dieser Tabelle befinden, aber sie führen nicht dazu, dass sie über die Anzahl ihrer vorab aufgewärmten Instanzen hinaus skaliert werden. Eine vollständige Liste aller Trigger- und Bindungserweiterungen finden Sie unter Trigger und Bindungen.

App Service-Plan und App Service-Umgebung mit Triggern für virtuelle Netzwerke

Wenn Ihre Funktions-App entweder in einem „App Service“-Plan oder in einer App Service-Umgebung ausgeführt wird, können Sie Funktionen schreiben, die durch Ressourcen ausgelöst werden, die durch ein virtuelles Netzwerk gesichert sind. Damit Ihre Funktionen ordnungsgemäß ausgelöst werden, muss ihre App mit einem virtuellen Netzwerk verbunden sein. Außerdem muss auf die in der Triggerverbindung definierte Ressource zugegriffen werden können.

Angenommen, Sie möchten Azure Cosmos DB so konfigurieren, dass nur Datenverkehr aus einem virtuellen Netzwerk akzeptiert wird. In diesem Fall müssen Sie Ihre Funktions-App in einem App Service-Plan bereitstellen, der die VNET-Integration mit diesem virtuellen Netzwerk ermöglicht. Die Integration ermöglicht das Auslösen einer Funktion durch diese Azure Cosmos DB-Ressource.

Testüberlegungen

Wenn Sie Funktionen in einer Funktions-App mit privaten Endpunkten testen, müssen Sie Ihre Tests innerhalb desselben virtuellen Netzwerks durchführen, z. B. auf einem virtuellen Computer (VM) in diesem Netzwerk. Um die Option Code + Test im Portal von dieser VM aus verwenden zu können, müssen Sie Ihrer Funktions-App die folgenden CORS-Ursprünge hinzufügen:

  • https://functions-next.azure.com
  • https://functions-staging.azure.com
  • https://functions.azure.com
  • https://portal.azure.com

Wenn Sie den Zugriff auf Ihre Funktions-App mit privaten Endpunkten oder einer anderen Zugriffseinschränkung eingeschränkt haben, müssen Sie auch das Diensttag AzureCloud zur Positivliste hinzufügen. So aktualisieren Sie die Positivliste:

  1. Navigieren Sie zu Ihrer Funktions-App, und wählen Sie Einstellungen>Netzwerk und dann Konfiguration für eingehenden Zugriff>Öffentlicher Netzwerkzugriff aus.

  2. Vergewissern Sie sich, dass die Einstellung Öffentlicher Netzwerkzugriff auf Aus ausgewählten virtuellen Netzwerken und IP-Adressen aktiviert festgelegt ist.

  3. Wählen Sie unter „Websitezugriff und -regeln“ die Option Regel hinzufügen aus:

    1. Wählen Sie Service Tag als Typ für die Quelleinstellungen und AzureCloud als Diensttag aus.

    2. Stellen Sie sicher, dass die Aktion Zulassen ausgewählt ist, und legen Sie den gewünschten Namen und die gewünschte Priorität fest.

Problembehandlung

Die Funktion ist zwar einfach einzurichten, dies bedeutet jedoch nicht, dass keinerlei Probleme auftreten. Sollten beim Zugreifen auf den gewünschten Endpunkt Probleme auftreten, können Sie einige Hilfsprogramme verwenden, um die Verbindung über die App-Konsole zu testen. Sie können zwei Konsolen verwenden. Eine ist die Kudu-Konsole, und die andere ist die Konsole im Azure-Portal. Greifen Sie in der App auf Tools>Kudu zu, um zur Kudu-Konsole zu gelangen. Sie können auch die Kudo-Konsole unter „[sitename].scmn.azurewebsites.net“ erreichen. Wechseln Sie nach dem Laden der Website zur Registerkarte Debugging-Konsole. Um auf die über das Azure-Portal gehostete Konsole zuzugreifen, navigieren Sie in der App zu Extras>Konsole.

Tools

In nativen Windows-Apps funktionieren die Tools ping, nslookup und tracert funktionieren aufgrund von Sicherheitseinschränkungen nicht über die Konsole (sie funktionieren in benutzerdefinierten Windows-Containern). Es wurden zwei separate Tools hinzugefügt, um diese Lücke zu füllen. Zum Testen der DNS-Funktionalität haben wir ein Tool mit dem Namen nameresolver.exe hinzugefügt. Die Syntax ist:

nameresolver.exe hostname [optional: DNS Server]

Sie können „nameresolver“ verwenden, um die Hostnamen zu überprüfen, von denen Ihre App abhängig ist. So können Sie testen, ob für das DNS etwas falsch konfiguriert ist oder ob ggf. kein Zugriff auf Ihren DNS-Server besteht. Den von Ihrer App verwendeten DNS-Server können Sie in der Konsole in den Umgebungsvariablen WEBSITE_DNS_SERVER und WEBSITE_DNS_ALT_SERVER einsehen.

Hinweis

Das Tool „nameresolver.exe“ funktioniert zurzeit nicht in benutzerdefinierten Windows-Containern.

Mit dem nächsten Tool können Sie die TCP-Verbindung mit einer Host-Port-Kombination testen. Dieses Tool hat den Namen tcpping und die folgende Syntax:

tcpping.exe hostname [optional: port]

Das tcpping-Hilfsprogramm teilt Ihnen mit, ob Sie einen bestimmten Host und Port erreichen können. Es kann nur unter folgenden Bedingungen erfolgreich ausgeführt werden: Eine Anwendung lauscht auf der Host- und Portkombination, und von Ihrer App aus ist Netzwerkzugriff auf den angegebenen Host und Port möglich.

Debuggen des Zugriffs auf im virtuellen Netzwerk gehostete Ressourcen

Es gibt verschiedene Gründe, aus denen Ihre App einen bestimmten Host und Port nicht erreichen kann. In den meisten Fällen liegt eine der drei folgenden Ursachen vor:

  • Eine Firewall. Falls eine Firewall den Zugriff verhindert, wird das TCP-Timeout ausgelöst. Das TCP-Timeout entspricht hier 21 Sekunden. Überprüfen Sie die Verbindung mithilfe des tcpping-Tools. TCP-Timeouts können zwar auch viele andere Ursachen haben, es empfiehlt sich jedoch, bei der Firewall zu beginnen.
  • Kein DNS-Zugriff. Das DNS-Timeout beträgt 3 Sekunden pro DNS-Server. Wenn Sie zwei DNS-Server besitzen, beträgt das Timeout 6 Sekunden. Überprüfen Sie mithilfe des nameresolver-Tools, ob DNS funktioniert. Das nslookup-Tool kann nicht verwendet werden, da es nicht das DNS verwendet, mit dem Ihr virtuelles Netzwerk konfiguriert ist. Dieses Problem kann darauf zurückzuführen sein, dass eine Firewall oder Netzwerksicherheitsgruppe den Zugriff auf das DNS blockiert.

Sollte das Problem weiterhin bestehen, überprüfen Sie zunächst Folgendes:

Regionale Integration des virtuellen Netzwerks

  • Ist Ihr Ziel eine RFC 1918-fremde Adresse und Route All (Gesamten Datenverkehr weiterleiten) nicht aktiviert?
  • Blockiert eine Netzwerksicherheitsgruppe ausgehenden Datenverkehr aus Ihrem Integrationssubnetz?
  • Bei einer Verbindung über Azure ExpressRoute oder ein VPN: Ist Ihr lokales Gateway zum Zurückleiten von Datenverkehr an Azure konfiguriert? Wenn Sie die Endpunkte in Ihrem virtuellen Netzwerk erreichen können, aber nicht lokal, überprüfen Sie Ihre Routen.
  • Verfügen Sie über ausreichende Berechtigungen, um Delegierung für das Integrationssubnetz festzulegen? Während der Konfiguration der Integration des regionalen virtuellen Netzwerks wird Ihr Integrationssubnetz an „Microsoft.Web/serverFarms“ delegiert. Das Subnetz wird von der Benutzeroberfläche der VNET-Integration automatisch an „Microsoft.Web/serverFarms“ delegiert. Wenn Ihr Konto nicht über ausreichende Netzwerkberechtigungen verfügt, um Delegierung festzulegen, benötigen Sie eine Person, die in Ihrem Integrationssubnetz Attribute festlegen kann, um das Subnetz zu delegieren. Wenn Sie das Subnetz für die Integration manuell delegieren möchten, wechseln Sie zur Benutzeroberfläche des Azure Virtual Network-Subnetzes, und legen Sie die Delegierung für „Microsoft.Web/serverFarms“ fest.

Integration des virtuellen Netzwerks mit erforderlichem Gateway

  • Liegt der Point-to-Site-Adressbereich in den RFC 1918-Bereichen (10.0.0.0-10.255.255.255/172.16.0.0-172.31.255.255/192.168.0.0-192.168.255.255)?
  • Wird im Portal angezeigt, dass das Gateway ausgeführt wird? Fahren Sie das Gateway hoch, wenn es heruntergefahren ist.
  • Werden Zertifikate als synchronisiert angezeigt, oder vermuten Sie, dass die Netzwerkkonfiguration geändert wurde? Wenn Ihre Zertifikate nicht synchronisiert sind oder Sie vermuten, dass an Ihrer VNET-Konfiguration eine Änderung vorgenommen wurde, die nicht mit Ihren ASPs synchronisiert wurde, wählen Sie Netzwerk synchronisieren aus.
  • Bei einer Verbindung über ein VPN: Ist Ihr lokales Gateway zum Zurückleiten von Datenverkehr an Azure konfiguriert? Wenn Sie die Endpunkte in Ihrem virtuellen Netzwerk erreichen können, aber nicht lokal, überprüfen Sie Ihre Routen.
  • Versuchen Sie, ein Koexistenzgateway zu verwenden, das sowohl Point-to-Site als auch ExpressRoute unterstützt? Koexistenzgateways werden bei der Integration virtueller Netzwerke nicht unterstützt.

Das Debuggen von Netzwerkproblemen ist eine Herausforderung, da Sie nicht sehen können, was den Zugriff auf eine bestimmte Host:Port-Kombination blockiert. Mögliche Ursachen:

  • Sie verfügen über eine aktivierte Firewall auf Ihrem Host, die den Zugriff auf den Anwendungsport über Ihren Point-to-Site-IP-Adressbereich verhindert Für die Durchquerung von Subnetzen ist häufig öffentlicher Zugriff erforderlich.
  • Zielhost ausgefallen
  • Anwendung nicht verfügbar
  • Falsche IP-Adresse oder falscher Hostname
  • Die Anwendung lauscht über einen anderen Port als erwartet. Sie können Ihre Prozess-ID auf den lauschenden Port festlegen, indem Sie auf dem Endpunkthost „netstat -aon“ verwenden.
  • Netzwerksicherheitsgruppen sind so konfiguriert, dass der Zugriff auf Ihren Anwendungshost und -port aus Ihrem Point-to-Site-IP-Adressbereich verhindert wird.

Ihnen ist nicht bekannt, welche Adresse Ihre App tatsächlich verwendet. Es kann sich um eine beliebige Adresse im Integrationssubnetz oder Point-to-Site-Adressbereich handeln. Sie müssen daher den Zugriff vom gesamten Adressbereich zulassen.

Weitere Debugschritte sind unter anderem:

  • Stellen Sie eine Verbindung mit einer VM im virtuellen Netzwerk her, und versuchen Sie, die Ressource host:port von dort aus zu erreichen. Zum Testen des TCP-Zugriffs verwenden Sie den PowerShell-Befehl Test-NetConnection. Die Syntax ist:
Test-NetConnection hostname [optional: -Port]
  • Rufen Sie eine Anwendung auf einer VM auf, und testen Sie den Zugriff auf den jeweiligen Host und Port über die Konsole der App mit tcpping.

Lokale Ressourcen

Wenn Ihre App eine Ressource lokal nicht erreichen kann, überprüfen Sie, ob Sie die Ressource über Ihr virtuelles Netzwerk erreichen können. Verwenden Sie den PowerShell-Befehl Test-NetConnection, um den TCP-Zugriff zu überprüfen. Wenn Ihre VM die lokale Ressource nicht erreichen kann, ist Ihre VPN- oder ExpressRoute-Verbindung möglicherweise nicht richtig konfiguriert.

Wenn die im virtuellen Netzwerk gehostete VM auf ein lokales System zugreifen kann, die App jedoch nicht, trifft wahrscheinlich einer der folgenden Gründe zu:

  • Die Routen sind in Ihrem lokalen Gateway nicht mit Ihren Subnetz- oder Point-to-Site-Adressbereichen konfiguriert.
  • Die Netzwerksicherheitsgruppen blockieren den Zugriff auf den Point-to-Site-IP-Adressbereich.
  • Die lokalen Firewalls blockieren den Datenverkehr des Point-to-Site-IP-Adressbereichs.
  • Sie versuchen, eine RFC 1918-fremde Adresse mit der Funktion für die Integration regionaler virtueller Netzwerke zu erreichen.

Löschen des App Service-Plans oder der Web-App vor dem Trennen der VNet-Integration

Wenn Sie die Web-App oder den App Service-Plan gelöscht haben, ohne zuvor die VNet-Integration aufzuheben, können Sie keine Aktualisierungs-/Löschvorgänge in dem virtuellen Netzwerk oder Subnetz durchführen, das für die Integration mit der gelöschten Ressource verwendet wurde. Eine Subnetzdelegierung von „Microsoft.Web/serverFarms“ bleibt Ihrem Subnetz zugewiesen und verhindert die Aktualisierungs-/Löschvorgänge.

Um das Subnetz oder virtuelle Netzwerk erneut zu aktualisieren oder zu löschen, müssen Sie die VNet-Integration neu erstellen und dann die Verbindung trennen:

  1. Erstellen Sie den App Service-Plan und die Web-App neu (Sie müssen unbedingt genau denselben Web-App-Namen wie zuvor verwenden).
  2. Navigieren Sie in der Web-App zum Blatt „Netzwerk“, und konfigurieren Sie die VNet-Integration.
  3. Nachdem die VNet-Integration konfiguriert wurde, wählen Sie die Schaltfläche „Trennen“ aus.
  4. Löschen Sie den App Service-Plan oder die Web-App.
  5. Aktualisieren/Löschen Sie das Subnetz oder das virtuelle Netzwerk.

Wenn nach dem Ausführen der obigen Schritte weiterhin Probleme mit der VNet-Integration auftreten, wenden Sie sich an den Microsoft-Support.

Netzwerkproblembehandlung

Sie können auch die Netzwerkproblembehandlung verwenden, um Verbindungsprobleme zu beheben. Rufen Sie die App im Azure-Portal auf, um die Netzwerkproblembehandlung zu öffnen. Wählen Sie Diagnose und Problemlösung aus, und suchen Sie dann nach Netzwerkproblembehandlung.

Verbindungsprobleme: Überprüft den Status der VNet-Integration, einschließlich einer Überprüfung, ob allen Instanzen des Plans und in den DNS-Einstellungen eine private IP-Adresse zugewiesen wurde. Wenn kein benutzerdefiniertes DNS konfiguriert ist, wird das standardmäßige Azure DNS verwendet. Die Problembehandlung prüft außerdem auf gängige Abhängigkeiten von Funktions-Apps, darunter die Konnektivität für Azure Storage und andere Bindungsabhängigkeiten.

Screenshot, der eine laufende Problembehandlung für Verbindungsprobleme zeigt.

Konfigurationsprobleme: Überprüft, ob Ihr Subnetz für die VNet-Integration zulässig ist.

Screenshot, der eine laufende Problembehandlung für Konfigurationsprobleme zeigt.

Problem beim Löschen von Subnetz/VNet: Überprüft, ob für Ihr Subnetz Sperren vorliegen und ob nicht verwendete Dienstzuordnungslinks vorhanden sind, die eine Löschung des VNet/Subnetzes blockieren könnten.

Nächste Schritte

Weitere Informationen zum Netzwerk und zu Azure Functions: