Delen via

netwerkopties voor Azure Functions

In dit artikel worden de netwerkfuncties beschreven die beschikbaar zijn in de hostingopties voor Azure Functions. De volgende netwerkopties kunnen worden gecategoriseerd als binnenkomende en uitgaande netwerkfuncties. Met binnenkomende functies kunt u de toegang tot uw app beperken, terwijl u met uitgaande functies uw app kunt verbinden met resources die worden beveiligd door een virtueel netwerk en hoe uitgaand verkeer wordt gerouteerd.

De hostingmodellen hebben verschillende niveaus van netwerkisolatie beschikbaar. Als u de juiste optie kiest, kunt u voldoen aan de vereisten voor netwerkisolatie.

Kenmerk Flex Consumption-abonnement Verbruiksabonnement Premium-abonnement Toegewezen abonnement/ASE Container Apps1
Beperkingen voor binnenkomende toegang ✅ ✅ ✅ ✅ ✅ 2
Privé-eindpunten (inkomend) ✅ ❌ ✅ ✅ ❌
Service-eindpunten (inkomend) ✅ ❌ ✅ ✅ ✅
Integratie van virtueel netwerk (uitgaand) ✅ ❌ ✅ ✅ 3 ✅
Hybride verbindingen ❌ ❌ ✅ (alleen Windows) ✅ (alleen Windows) ✅ (alleen Windows)
  1. Zie Networking in Azure Container Apps omgeving voor meer informatie.
  2. Beheerd via de ingress-configuratie van de Container Apps-omgeving.
  3. Het Dedicated/ASE-plan biedt ook ondersteuning voor integratie van virtuele netwerken die vereist is door de gateway.

Snelstartbronnen

Gebruik de volgende resources om snel aan de slag te gaan met Azure Functions netwerkscenario's. In het artikel wordt verwezen naar deze resources.

Beperkingen voor binnenkomende toegang

U kunt toegangsbeperkingen gebruiken om een op prioriteit geordende lijst met IP-adressen te definiëren die toegang tot uw app hebben toegestaan of geweigerd. De lijst kan IPv4- en IPv6-adressen of specifieke subnetten voor virtuele netwerken bevatten met behulp van service-eindpunten. Wanneer er een of meer vermeldingen zijn, bestaat er een impliciete 'alles weigeren' aan het einde van de lijst. IP-beperkingen werken met alle opties voor functiehosting.

Notitie

Met netwerkbeperkingen kunt u alleen implementeren vanuit uw virtuele netwerk of wanneer u het IP-adres van de computer plaatst die u gebruikt voor toegang tot de Azure-portal in de lijst Safe Recipients. U kunt de functie echter wel beheren met behulp van de portal.

Zie Azure App Service statische toegangsbeperkingen voor meer informatie.

Wanneer u in Container Apps werkt, wordt binnenkomende toegang beheerd via de toegangsbeheerobjectconfiguratie van de Container Apps-omgeving in plaats van App Service-toegangsbeperkingen. Zie IP-beperkingen in Azure Container Apps voor meer informatie.

Privé-eindpunten (inkomend)

Azure Privé-eindpunt is een netwerkinterface die u privé en veilig verbindt met een service die wordt mogelijk gemaakt door Azure Private Link. Private Endpoint maakt gebruik van een privé-IP-adres van uw virtuele netwerk, waarbij de service effectief in uw virtuele netwerk wordt geplaatst.

U kunt een privé-eindpunt gebruiken voor uw functies die worden gehost in de abonnementen Flex Consumption, Elastic Premium en Dedicated (App Service ).

Als u privé-eindpunten wilt aanroepen, moet u ervoor zorgen dat uw DNS-zoekopdrachten worden omgezet in het privé-eindpunt. U kunt dit gedrag op een van de volgende manieren afdwingen:

  • Integreer met Azure DNS privézones. Wanneer uw virtuele netwerk geen aangepaste DNS-server heeft, wordt dit automatisch gedaan.
  • Beheer het privé-eindpunt in de DNS-server die door uw app wordt gebruikt. Als u een privé-eindpunt wilt beheren, moet u het eindpuntadres kennen en een A-record gebruiken om te verwijzen naar het eindpunt dat u probeert te bereiken.
  • Configureer uw eigen DNS-server om door te sturen naar Azure DNS privézones.

Zie het gebruik van privé-eindpunten voor webapps voor meer informatie.

Als u andere services wilt aanroepen die een privé-eindpuntverbinding hebben, zoals opslag of servicebus, moet u uw app configureren om uitgaande aanroepen naar privé-eindpunten te maken. Ga voor meer informatie over het gebruik van privé-eindpunten met het opslagaccount voor uw functie-app naar uw opslagaccount beperken tot een virtueel netwerk.

Service-eindpunten (inkomend)

Met behulp van service-eindpunten kunt u veel Azure services beperken tot geselecteerde subnetten van virtuele netwerken om een hoger beveiligingsniveau te bieden. Dankzij regionale integratie van virtuele netwerken kan uw functie-app Azure services bereiken die zijn beveiligd met service-eindpunten. Deze configuratie wordt ondersteund voor alle plannen die ondersteuning bieden voor integratie van virtuele netwerken. Volg deze stappen om toegang te krijgen tot een beveiligd service-eindpunt:

  1. Configureer regionale integratie van virtueel netwerk met uw functie-app om verbinding te maken met een specifiek subnet.
  2. Ga naar de doelservice en configureer service-eindpunten op basis van het integratiesubnet.

Zie Service-eindpunten voor virtuele netwerken voor meer informatie.

Service-eindpunten gebruiken

Als u de toegang tot een specifiek subnet wilt beperken, maakt u een beperkingsregel met een Virtual Networktype. Vervolgens kunt u het abonnement, het virtuele netwerk en het subnet selecteren waartoe u toegang wilt toestaan of weigeren.

Als service-eindpunten nog niet zijn ingeschakeld met Microsoft.Web voor het geselecteerde subnet, worden ze automatisch ingeschakeld, tenzij u het selectievakje 'Ignore ontbrekende Microsoft.Web service-eindpunten' aanvinkt. Het scenario waarin u service-eindpunten voor de app wilt inschakelen, maar niet het subnet, is voornamelijk afhankelijk van of u over de machtigingen beschikt om deze in te schakelen voor het subnet.

Als u iemand anders nodig hebt om service-eindpunten in te schakelen in het subnet, selecteer dan het selectievakje Negeer ontbrekende Microsoft.Web-service-eindpunten. Uw app is geconfigureerd voor service-eindpunten, die u later op het subnet inschakelt.

Schermopname van het deelvenster

U kunt geen service-eindpunten gebruiken om de toegang te beperken tot apps die worden uitgevoerd in een App Service Environment. Wanneer uw app zich in een App Service Environment bevindt, kunt u de toegang tot de app beheren door IP-toegangsregels toe te passen.

Zie Etablish Azure Functions private site access voor meer informatie over het instellen van service-eindpunten.

Integratie van virtueel netwerk (uitgaand)

In deze sectie worden de functies beschreven die door Functions worden ondersteund voor het beheren van gegevens die uitgaand zijn vanuit uw app.

Integratie van virtuele netwerken biedt uw functie-app toegang tot resources in uw virtuele netwerk. Zodra de app is geïntegreerd, routeert uw app uitgaand verkeer via het virtuele netwerk. Hierdoor heeft uw app toegang tot privé-eindpunten of -resources met regels die verkeer toestaan van alleen bepaalde subnetten. Wanneer het doel een IP-adres buiten het virtuele netwerk is, wordt het bron-IP-adres nog steeds verzonden vanaf een van de adressen die worden vermeld in de eigenschappen van uw app, tenzij u een NAT-gateway hebt geconfigureerd.

Azure Functions ondersteunt regionale integratie van virtuele netwerken. Dit is de aanbevolen aanpak. Zie Integratie van virtuele netwerken inschakelen voor meer informatie over het instellen van integratie van virtuele netwerken.

Azure Functions ondersteunt twee soorten integratie van virtuele netwerken:

Zie Integratie van virtuele netwerken inschakelen voor meer informatie over het instellen van integratie van virtuele netwerken.

Regionale integratie van virtueel netwerk (uitgaand)

Door regionale integratie van virtuele netwerken te gebruiken, heeft uw app toegang tot:

  • Resources in hetzelfde virtuele netwerk als uw app.
  • Resources in virtuele netwerken die gekoppeld zijn aan het virtuele netwerk waarin uw app is geïntegreerd.
  • Beveiligde services voor service-eindpunten.
  • Resources voor Azure ExpressRoute verbindingen.
  • Resources voor peer-verbindingen, waaronder Azure ExpressRoute verbindingen.
  • Privé-eindpunten.

Wanneer u regionale integratie van virtuele netwerken gebruikt, kunt u de volgende Azure netwerkfuncties gebruiken:

  • Netwerkbeveiligingsgroepen (NSG's): u kunt uitgaand verkeer blokkeren met een NSG die in uw integratiesubnet wordt geplaatst. De regels voor inkomend verkeer zijn niet van toepassing omdat u geen integratie van virtuele netwerken kunt gebruiken om binnenkomende toegang tot uw app te bieden.
  • Routetabellen (UDR's): u kunt een routetabel in het integratiesubnet plaatsen om uitgaand verkeer naar wens te verzenden.

Notitie

Wanneer u al uw uitgaande verkeer naar uw virtuele netwerk routeert, is dit onderhevig aan de NSG's en UDR's die worden toegepast op uw integratiesubnet. Wanneer het virtuele netwerk is geïntegreerd, wordt het uitgaande verkeer van uw functie-app naar openbare IP-adressen nog steeds verzonden vanaf de adressen die worden vermeld in uw app-eigenschappen, tenzij u routes opgeeft die het verkeer ergens anders omleiden.

Integratie van regionaal virtueel netwerk kan poort 25 niet gebruiken.

Overwegingen voor het Flex Consumption-abonnement:

  • De app en het virtuele netwerk moeten zich in dezelfde regio bevinden.
  • Zorg ervoor dat de Azure-resourceprovider voor uw abonnement is ingeschakeld door deze instructies te volgen. Dit is nodig voor subnetdelegering. De Azure-portal en Azure CLI deze registratie afdwingen wanneer u een Flex Consumption-app maakt, omdat de integratie van virtuele netwerken op elk moment kan worden ingeschakeld nadat uw app is gemaakt.
  • De subnetdelegering die vereist is bij gebruik van een Flex Consumption-abonnement is Microsoft.App/environments. Dit verschilt van de Elastic Premium- en Dedicated-abonnementen (App Service), die een andere overdrachtsvereiste hebben.
  • U kunt plannen dat er maximaal 40 IP-adressen worden gebruikt voor één functie-app, zelfs als de app groter is dan 40. Als u bijvoorbeeld 15 Flex Consumption functie-apps hebt die in hetzelfde subnet geïntegreerd zijn, moet u rekening houden met maximaal 15 x 40 = 600 IP-adressen. Deze limiet is onderhevig aan wijzigingen en wordt niet afgedwongen.
  • Het subnet kan nog niet worden gebruikt voor andere doeleinden (zoals privé- of service-eindpunten, of gedelegeerd aan een ander hostingabonnement of andere service). Hoewel u hetzelfde subnet kunt delen met meerdere Flex Consumption-apps, worden de netwerkresources gedeeld in deze functie-apps, wat kan leiden tot één app die de prestaties van anderen op hetzelfde subnet beïnvloedt.
  • U kunt hetzelfde subnet niet delen tussen een Container Apps-omgeving en een Flex Consumption-app.
  • Het Flex Consumption-abonnement biedt momenteel geen ondersteuning voor subnetten met namen die onderstrepingstekens (_) bevatten.

Overwegingen voor de abonnementen Elastic Premium, Dedicated (App Service) en Container Apps :

  • De functie is beschikbaar voor Elastic Premium en App Service Premium V2 en Premium V3. Het is ook beschikbaar in Standard, maar alleen van nieuwere App Service-implementaties. Als u een oudere implementatie gebruikt, kunt u de functie alleen gebruiken vanuit een Premium V2 App Service-plan. Als u zeker wilt weten dat u de functie in een Standard App Service-plan kunt gebruiken, maakt u uw app in een Premium V3 App Service-plan. Deze plannen worden alleen ondersteund op onze nieuwste implementaties. U kunt indien u dat wilt naar beneden schalen.
  • ** Geïsoleerde plan-apps die zich in een App Service Environment bevinden, kunnen de functie niet gebruiken.
  • De app en het virtuele netwerk moeten zich in dezelfde regio bevinden.
  • Voor de functie is een subnet vereist dat een /28 of groter is in een Azure Resource Manager virtueel netwerk.
  • Meerdere App Service-abonnementen kunnen gebruikmaken van het integratiesubnet.
  • U kunt maximaal twee regionale virtuele netwerkintegraties per App Service-plan hebben. Meerdere apps in hetzelfde App Service-plan kunnen gebruikmaken van hetzelfde integratiesubnet.
  • het subnet dat u kiest, kan nog niet worden gebruikt voor andere doeleinden, zoals met privé-eindpunten of service-eindpunten, of worden gedelegeerd aan een ander hostingabonnement of -service.
  • U kunt hetzelfde subnet delen met meer dan één app in een App Service-plan. Omdat de netwerkresources worden gedeeld in alle apps, kan één functie-app van invloed zijn op de prestaties van anderen in hetzelfde subnet.
  • U kunt een virtueel netwerk met een geïntegreerde app niet verwijderen. Verwijder de integratie voordat u het virtuele netwerk verwijdert.
  • U kunt het abonnement van een app of een plan niet wijzigen terwijl er een app is die gebruikmaakt van regionale integratie van virtuele netwerken.

Integratie van virtuele netwerken inschakelen

  1. Selecteer in de functie-app in de Azure portal, onder Settings, Networking. Selecteer vervolgens onder Virtual Network IntegrationNot configured om toe te voegen.

  2. Selecteer Voeg virtuele netwerkintegratie toe.

    Schermopname van de integratiepagina van het virtuele netwerk, waar u de integratie van virtuele netwerken in uw app kunt inschakelen.

  3. De vervolgkeuzelijst bevat alle Azure Resource Manager virtuele netwerken in uw abonnement in dezelfde regio. Selecteer het virtuele netwerk waarmee u wilt integreren.

    Het VNet selecteren

    • De Flex Consumption- en Elastic Premium-hostingabonnementen bieden alleen ondersteuning voor regionale integratie van virtuele netwerken. Als het virtuele netwerk zich in dezelfde regio bevindt, maakt u een nieuw subnet of selecteert u een leeg, bestaand subnet.

    • Als u een virtueel netwerk in een andere regio wilt selecteren, moet u een gateway voor een virtueel netwerk hebben ingericht met point-to-site ingeschakeld. Integratie van virtuele netwerken over regio's wordt alleen ondersteund voor dedicatede plannen, maar mondiale peerings werken met regionale integratie van virtuele netwerken.

Tijdens de integratie wordt uw app opnieuw opgestart. Wanneer de integratie is voltooid, ziet u details over het virtuele netwerk waarmee u bent geïntegreerd. Route All is standaard ingeschakeld en al het verkeer wordt doorgestuurd naar uw virtuele netwerk.

Als u uw privéverkeer (RFC1918 verkeer) liever alleen wilt laten routeren, volgt u de stappen in dit App Service-artikel.

Subnetten

Integratie van virtuele netwerken is afhankelijk van een toegewezen subnet. Wanneer u een subnet inricht, reserveert Azure de eerste vijf IP-adressen voor intern gebruik. De manier waarop de resterende IP-adressen worden gebruikt, is afhankelijk van uw hostingabonnement. Omdat de grootte van het subnet niet kan worden gewijzigd na de toewijzing, gebruikt u een subnet dat groot genoeg is om te voldoen aan de schaal die uw app kan bereiken.

De volgende tabel bevat een overzicht van de subnetvereisten voor elk hostingabonnement:

Hostingabonnement VNet-integratie Minimale subnetgrootte Aanbevolen subnetgrootte Delegatie van subnet
Flexverbruik Ondersteund /27 /27 (één app), /26 (meerdere apps) Microsoft.App/environments
Elastic Premium (Windows) Ondersteund /28 /24 Microsoft.Web/serverFarms
Elastic Premium (Linux) Ondersteund /28 /26 Microsoft.Web/serverFarms
Toegewijd (App Service) Ondersteund /28 /26 of groter Microsoft.Web/serverFarms
Container-apps Beheerd door omgeving Zie Container Apps netwerk Zie Container Apps networking Microsoft.App/environments
Verbruik Niet ondersteund N/A N/A N/A

Zorg ervoor dat u uw hostingabonnement bovenaan het artikel selecteert voor planspecifieke details.

Bij uitvoering op Azure Container Apps wordt de integratie van virtuele netwerken beheerd via de Container Apps-omgeving. De grootte en configuratie van subnetten worden bepaald door de Container Apps-omgeving, niet door de functie-app rechtstreeks. Zie Networking in Azure Container Apps omgeving voor meer informatie.

In Elastic Premium- en Dedicated-abonnementen (App Service) verbruikt elk actief exemplaar van uw functie-app één IP-adres uit het subnet. Wanneer u omhoog of omlaag schaalt, kan de vereiste adresruimte tijdelijk verdubbelen om de overgang mogelijk te maken. Als meerdere apps hetzelfde subnet delen, is het totale IP-adresgebruik de som van alle exemplaren in deze apps, plus de tijdelijke verdubbeling tijdens het schalen van gebeurtenissen.

Scenario's voor IP-verbruik

Scenario IP-adresverbruik
Eén app, één exemplaar Eén IP-adres
Eén app, vijf exemplaren Vijf IP-adressen
Eén app, schalen van vijf naar tien instanties Maximaal 20 IP-adressen (tijdelijk, tijdens de schaalbewerking)
Drie apps, vijf exemplaren elk 15 IP-adressen

Aanbevelingen voor CIDR-bereik

CIDR-blokgrootte Maximaal beschikbare adressen Maximale horizontale schaal (instanties)1
/28 11 5
/27 27 13
/26 59 29
/25 123 612
/24 251 1253
  1. Hierbij wordt ervan uitgegaan dat u op een bepaald moment omhoog of omlaag moet schalen in grootte of SKU.
  2. Hoewel het aantal IP-adressen 61 exemplaren ondersteunt, hebben afzonderlijke apps in het Dedicated-abonnement een maximum van 30 exemplaren.
  3. Hoewel het aantal IP-adressen 125 exemplaren ondersteunt, hebben afzonderlijke apps in het Elastic Premium-abonnement een maximum van 100 exemplaren.

Aanvullende overwegingen

  • Als u problemen met subnetcapaciteit voor Elastic Premium-abonnementen voor Functions wilt voorkomen, moet u een /24 met 256 adressen gebruiken voor Windows en een /26 met 64 adressen voor Linux. Wanneer u subnetten maakt in Azure portal als onderdeel van de integratie met het virtuele netwerk, is een minimale grootte van respectievelijk /24 en /26 vereist voor Windows en Linux.
  • Elk App Service-plan kan maximaal twee subnetten ondersteunen die kunnen worden gebruikt voor VNet-integratie. Meerdere apps van één App Service-plan kunnen lid worden van hetzelfde subnet, maar apps uit een ander abonnement kunnen hetzelfde subnet niet gebruiken.

In het Flex Consumption-abonnement wordt uitgaand netwerkverkeer van functie-apps gerouteerd via gedeelde gateways die zijn toegewezen voor het subnet. Maximaal 27 gedeelde gateways (27 IP-adressen) worden per subnet gebruikt, ongeacht hoeveel apps zijn geïntegreerd. Wanneer een subnet wordt gebruikt voor te veel exemplaren of voor apps die I/O-intensieve workloads uitvoeren, kunnen netwerkcapaciteitsproblemen, zoals verhoogde latentie en time-outs, optreden. Het uitschalen van apps wordt niet beïnvloed.

Belangrijk

Als u functie-apps van Flex Consumption integreert met een subnetgrootte kleiner dan /27 of meerdere apps integreert met een subnet met een /27-grootte, vermindert u de beschikbare uitgaande netwerkcapaciteit voor deze apps. Als u van plan bent dit te doen, test dan uw apps met workloads op productieniveau om beperkingen in netwerkcapaciteit te vermijden.

Aanbevelingen voor CIDR-bereik

CIDR-blokgrootte Bruikbare adressen Maximum aantal exemplaren Aanbeveling
/27 27 1000 Aanbevolen voor één functie-app
/26 59 1,000+ Aanbevolen voor meerdere apps of bij het schalen van meer dan 1000 exemplaren*

* Neem contact op met de productgroep om een verhoging aan te vragen voor het maximumaantal exemplaren.

Netwerkbeveiligingsgroepen

U kunt netwerkbeveiligingsgroepen gebruiken om verkeer tussen resources in uw virtuele netwerk te beheren. U kunt bijvoorbeeld een beveiligingsregel maken die het uitgaande verkeer van uw app blokkeert om een resource in uw virtuele netwerk te bereiken of het netwerk te verlaten. Deze beveiligingsregels zijn van toepassing op apps die virtuele netwerkintegratie hebben geconfigureerd. Als u verkeer naar openbare adressen wilt blokkeren, moet integratie van virtuele netwerken en Route All zijn ingeschakeld. De regels voor inkomend verkeer in een NSG zijn niet van toepassing op uw app, omdat de integratie van virtuele netwerken alleen van invloed is op uitgaand verkeer van uw app.

Gebruik de functie Toegangsbeperkingen om inkomend verkeer naar uw app te beheren. Een NSG die wordt toegepast op uw integratiesubnet is van kracht, ongeacht de routes die worden toegepast op uw integratiesubnet. Als uw functietoepassing is geïntegreerd met een virtueel netwerk waarin Route All actief is, en u geen routes hebt die invloed hebben op het verkeer van openbare adressen in uw integratiesubnet, dan is al uw uitgaande verkeer nog steeds onderworpen aan netwerkbeveiligingsgroepen (NSG's) die zijn toegewezen aan uw integratiesubnet. Als Route All niet is ingeschakeld, worden NSG's alleen toegepast op RFC1918 verkeer.

Routen

U kunt routetabellen gebruiken om uitgaand verkeer van uw app naar de gewenste locatie te routeren. Routetabellen zijn standaard alleen van invloed op uw RFC1918 doelverkeer. Wanneer Route All is ingeschakeld, worden al uw uitgaande oproepen beïnvloed. Wanneer u Route All uitschakelt, hebben uw routetabellen alleen invloed op privéverkeer (RFC1918). Routes die zijn ingesteld op uw integratiesubnet, hebben geen invloed op antwoorden op binnenkomende app-aanvragen. Algemene bestemmingen kunnen firewallapparaten of gateways bevatten.

Als u al het uitgaande verkeer on-premises wilt routeren, kunt u een routetabel gebruiken om al het uitgaande verkeer naar uw ExpressRoute-gateway te verzenden. Als u verkeer naar een gateway routeert, moet u routes instellen in het externe netwerk om antwoorden terug te sturen.

BGP-routes (Border Gateway Protocol) zijn ook van invloed op uw app-verkeer. Als u BGP-routes hebt van een ExpressRoute-gateway, wordt het uitgaande verkeer van uw app beïnvloed. BGP-routes zijn standaard alleen van invloed op uw RFC1918 doelverkeer. Wanneer uw functie-app is geïntegreerd in een virtueel netwerk met Route All ingeschakeld, kan al het uitgaande verkeer worden beïnvloed door uw BGP-routes.

Uitgaande IP-beperkingen

U kunt uitgaande beperkingen configureren voor het virtuele netwerk waar uw App Service Environment wordt geïmplementeerd.

Wanneer u een functie-app integreert in een Elastic Premium-abonnement of een App Service-plan met een virtueel netwerk, kan de app standaard uitgaande aanroepen naar internet maken. Door uw functie-app te integreren met een virtueel netwerk met Route All ingeschakeld, dwingt u af dat al het uitgaande verkeer wordt verzonden naar uw virtuele netwerk, waarbij regels voor netwerkbeveiligingsgroepen kunnen worden gebruikt om verkeer te beperken. Voor Flex Consumption wordt al het verkeer gerouteerd via het virtuele netwerk en is Route All niet nodig.

Zie Tutorial: Azure Functions uitgaand IP-adres beheren met een NAT-gateway van een Azure virtueel netwerk voor meer informatie over het beheren van het uitgaande IP-adres met behulp van een virtueel netwerk.

Azure DNS privézones

Nadat uw app is geïntegreerd met uw virtuele netwerk, wordt dezelfde DNS-server gebruikt waarmee uw virtuele netwerk is geconfigureerd en werkt deze met de Azure DNS privézones die zijn gekoppeld aan het virtuele netwerk.

Automatisering

Met de volgende API's kunt u programmatisch regionale virtuele netwerkintegraties beheren:

  • Azure CLI: gebruik de opdrachten az functionapp vnet-integration om een regionale virtuele netwerkintegratie toe te voegen, weer te geven of te verwijderen.
  • ARM-sjablonen: Integratie van regionaal virtueel netwerk kan worden ingeschakeld met behulp van een Azure Resource Manager sjabloon. Zie deze QuickStart-sjabloon voor Functions voor een volledig voorbeeld.

Hybride verbindingen

Hybrid Connections is een functie van Azure Relay die u kunt gebruiken voor toegang tot toepassingsbronnen in andere netwerken. Het biedt toegang vanuit uw app tot een toepassingseindpunt. U kunt deze niet gebruiken om toegang te krijgen tot uw toepassing.

Zoals in Azure Functions wordt gebruikt, correleert elke hybride verbinding met één TCP-host en -poortcombinatie. Dit betekent dat het eindpunt van de hybride verbinding zich op elk besturingssysteem en elke toepassing kan bevinden zolang u toegang hebt tot een TCP-luisterpoort. De functie Hybride verbindingen weet of geeft niet aan wat het toepassingsprotocol is of waartoe u toegang hebt. Het biedt alleen netwerktoegang.

Zie de App Service-documentatie voor hybride verbindingen voor meer informatie. Dezelfde configuratiestappen ondersteunen Azure Functions.

Belangrijk

Hybride verbindingen worden alleen ondersteund wanneer uw functie-app wordt uitgevoerd op Windows. Linux-apps worden niet ondersteund.

Verbinding maken met Azure Services via een virtueel netwerk

Dankzij de integratie van een virtueel netwerk heeft uw functie-app toegang tot resources in een virtueel netwerk. In deze sectie vindt u een overzicht van de zaken die u moet overwegen bij het verbinden van uw app met bepaalde services.

Uw opslagaccount beperken tot een virtueel netwerk

Notitie

Als u snel een functie-app wilt implementeren waarvoor privé-eindpunten zijn ingeschakeld in het opslagaccount, raadpleegt u de volgende sjabloon: Function-app met Azure Storage privé-eindpunten.

Wanneer u een functie-app maakt, moet u een algemeen Azure Storage-account maken of koppelen dat blob-, wachtrij- en tableopslag ondersteunt. U kunt dit opslagaccount vervangen door een account dat is beveiligd met service-eindpunten of privé-eindpunten.

Zie Uw opslagaccount beperken tot een virtueel netwerk voor meer informatie over het configureren van uw functie-app met een opslagaccount dat is beveiligd met een virtueel netwerk.

U moet ervoor zorgen dat de routering van privé-gegevensdeling is geconfigureerd. Zie Uw opslagaccount beperken tot een virtueel netwerk voor meer informatie over het configureren van uw functie-app met een opslagaccount dat is beveiligd met een virtueel netwerk.

Zie Uw opslagaccount beperken tot een virtueel netwerk voor meer informatie over het configureren van uw functie-app met een opslagaccount dat is beveiligd met een virtueel netwerk.

Key Vault verwijzingen gebruiken

U kunt Azure Key Vault verwijzingen gebruiken om geheimen uit Azure Key Vault in uw Azure Functions toepassing te gebruiken zonder dat er codewijzigingen nodig zijn. Azure Key Vault is een service die gecentraliseerd geheimenbeheer biedt, met volledige controle over toegangsbeleid en controlegeschiedenis.

Als de integratie van virtuele netwerken is geconfigureerd voor de app, kunnen Key Vault verwijzingen worden gebruikt om geheimen op te halen uit een kluis met netwerkbeperking.

Triggers voor virtuele netwerken (niet-HTTP)

Uw workload vereist mogelijk dat uw app wordt geactiveerd vanuit een gebeurtenisbron die wordt beveiligd door een virtueel netwerk.

Notitie

Wanneer deze wordt uitgevoerd op Azure Container Apps, worden triggers voor virtuele netwerken beheerd via de netwerkconfiguratie van de Container Apps-omgeving. Zie Networking in Azure Container Apps omgeving voor meer informatie.

Het Flex Consumption-abonnement biedt systeemeigen ondersteuning voor triggers voor virtuele netwerken. Uw functie-app kan worden geactiveerd vanuit gebeurtenisbronnen die worden beveiligd door een virtueel netwerk zonder extra configuratie voor bewaking van runtimeschaal.

Met het Elastic Premium-abonnement kunt u functies maken die services activeren die worden beveiligd door een virtueel netwerk. Deze niet-HTTP-triggers worden virtuele netwerktriggers genoemd.

Met het Elastic Premium-abonnement kunt u functies maken die services activeren die worden beveiligd door een virtueel netwerk.

Standaard zorgen virtuele netwerktriggers er niet voor dat uw functie-app wordt geschaald buiten het vooraf opgewarmde aantal exemplaren. Bepaalde extensies ondersteunen echter virtuele netwerktriggers die ervoor zorgen dat uw functie-app dynamisch wordt geschaald. U kunt deze dynamische schaalbewaking inschakelen in uw functie-app voor ondersteunde extensies op een van de volgende manieren:

  1. Navigeer in de Azure-portal naar uw functie-app.

  2. Onder Instellingen selecteert u Configuratie, en vervolgens stelt u op het tabblad Functie-runtime-instellingen de Runtimeschaalbewaking in op Aan.

  3. Selecteer Opslaan om de configuratie van de functie-app bij te werken en start de app opnieuw op.

VNETToggle

Aanbeveling

Het inschakelen van de bewaking van triggers voor virtuele netwerken kan van invloed zijn op de prestaties van uw toepassing, hoewel de impact waarschijnlijk klein is.

Ondersteuning voor dynamische schaalbewaking van triggers voor virtuele netwerken is niet beschikbaar in versie 1.x van de Functions-runtime.

De extensies in deze tabel bieden ondersteuning voor dynamische schaalbewaking van triggers voor virtuele netwerken. Als u de beste schaalprestaties wilt verkrijgen, moet u upgraden naar versies die ook ondersteuning bieden voor schaalaanpassing op basis van doelen.

Extensie (minimale versie) Alleen bewaking van runtimeschaal Met doelgerichte schaling
Microsoft.Azure. WebJobs.Extensions.CosmosDB > 3.0.5 > 4.1.0
Microsoft.Azure. WebJobs.Extensions.DurableTask > 2.0.0 n.v.t.
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*

* Alleen wachtrijopslag.

Belangrijk

Wanneer u bewaking van virtuele netwerktriggers inschakelt, kunnen alleen triggers voor deze extensies ertoe leiden dat uw app dynamisch wordt geschaald. U kunt nog steeds triggers gebruiken van extensies die niet in deze tabel staan, maar ze zullen geen schaalvergroting veroorzaken buiten het aantal vooraf opgewarmde instanties. Zie Triggers en bindingen voor een volledige lijst met alle trigger- en bindingsextensies.

Wanneer uw functie-app wordt uitgevoerd in een App Service-plan of een App Service Environment, kunt u functies schrijven die resources beveiligen door een trigger voor een virtueel netwerk. Om ervoor te zorgen dat uw functies correct worden geactiveerd, moet uw app zijn verbonden met een virtueel netwerk met toegang tot de resource die is gedefinieerd in de triggerverbinding.

Stel dat u Azure Cosmos DB wilt configureren om alleen verkeer van een virtueel netwerk te accepteren. In dit geval moet u uw functie-app implementeren in een App Service-plan dat integratie van virtuele netwerken met dat virtuele netwerk biedt. Dankzij integratie kan Azure Cosmos DB resource een functie activeren.

Privé-eindpunten testen

Wanneer u functies in een functie-app met privé-eindpunten test, moet u uw tests uitvoeren vanuit hetzelfde virtuele netwerk, zoals op een virtuele machine (VM) in dat netwerk. Als u de optie Code + Test in de portal van die VM wilt gebruiken, moet u de volgende CORS-origins toevoegen aan uw functie-app:

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

Wanneer u de toegang tot uw functie-app beperkt met privé-eindpunten of andere toegangsbeperkingen, moet u ook de servicetag AzureCloud toevoegen aan de lijst met toegestane services. De toegestane lijst bijwerken:

  1. Navigeer naar uw functie-app en selecteer Instellingen>netwerken. Selecteer Ingeschakeld zonder toegangsbeperkingen onder >,openbare netwerktoegang.

  2. Zorg ervoor dat openbare netwerktoegang is ingesteld op Ingeschakeld van geselecteerde virtuele netwerken en IP-adressen.

  3. Voeg een regel toe onder Sitetoegang en -regels:

    1. Selecteer Service Tag als het broninstellingstype en AzureCloud als de service-tag.

    2. Zorg ervoor dat de actie Toestaan is en stel de gewenste naam en prioriteit in.

Probleemoplossing

De functie is eenvoudig in te stellen, maar dat betekent niet dat uw ervaring probleemloos is. Als u problemen ondervindt bij het openen van het gewenste eindpunt, zijn er enkele hulpprogramma's die u kunt gebruiken om de connectiviteit vanuit de app-console te testen. Er zijn twee consoles die u kunt gebruiken. De ene is de Kudu-console en de andere is de console in de Azure-portal. Als u de Kudu-console vanuit uw app wilt bereiken, gaat u naar Tools>Kudu. U kunt ook de Kudo-console bereiken op [sitename].scm.azurewebsites.net. Nadat de website is geladen, gaat u naar het tabblad Debugconsole. Ga vanuit uw app naar Hulpprogramma's>Console om de in de Azure-portal gehoste console te openen.

Gereedschappen

In systeemeigen Windows-apps werken de hulpprogramma's ping, nslookup en tracert niet via de console door beveiligingsbeperkingen (ze werken wel in maatwerk Windows-containers). Om de leegte te vullen, worden er twee afzonderlijke hulpmiddelen toegevoegd. Om de DNS-functionaliteit te testen, hebben we een hulpprogramma met de naam nameresolver.exe toegevoegd. De syntaxis is:

nameresolver.exe hostname [optional: DNS Server]

U kunt nameresolver gebruiken om de hostnamen te controleren waarop uw app afhankelijk is. Op deze manier kunt u testen of u iets verkeerd hebt geconfigureerd met uw DNS of mogelijk geen toegang hebt tot uw DNS-server. U kunt de DNS-server zien die uw app in de console gebruikt door de omgevingsvariabelen te bekijken WEBSITE_DNS_SERVER en WEBSITE_DNS_ALT_SERVER.

Notitie

Het hulpprogramma nameresolver.exe werkt momenteel niet in aangepaste Windows containers.

U kunt het volgende hulpprogramma gebruiken om te testen op TCP-connectiviteit met een combinatie van host en poort. Dit hulpprogramma heet tcpping en de syntaxis is:

tcpping.exe hostname [optional: port]

Het tcpping-hulpprogramma geeft aan of u een specifieke host en poort kunt bereiken. Het kan alleen slagen als er een toepassing luistert op de combinatie van de host en poort en er is netwerktoegang van uw app naar de opgegeven host en poort.

Fouten opsporen in toegang tot door een virtueel netwerk gehoste resources

Een aantal dingen kan voorkomen dat uw app een specifieke host en poort bereikt. Meestal is het een van deze dingen:

  • Een firewall blokkeert de weg. Als er een firewall in de weg zit, ondervindt u een TCP-timeout. De TCP-time-out is in dit geval 21 seconden. Gebruik het tcpping-hulpprogramma om de connectiviteit te testen. TCP-time-outs kunnen worden veroorzaakt door veel dingen buiten firewalls, maar begin daar.
  • DNS is niet toegankelijk. De DNS-time-out is 3 seconden per DNS-server. Als u twee DNS-servers hebt, is de time-out 6 seconden. Gebruik nameresolver om te zien of DNS werkt. U kunt nslookup niet gebruiken, omdat hiermee niet de DNS wordt gebruikt waarmee uw virtuele netwerk is geconfigureerd. Als er geen toegang is, kan er een firewall of NSG zijn die de toegang tot DNS blokkeert, of het kan zijn dat DNS niet beschikbaar is.

Als deze items uw problemen niet beantwoorden, zoekt u eerst naar zaken zoals:

Integratie van regionaal virtueel netwerk

  • Is uw bestemming een niet-RFC1918 adres en hebt u Route All niet ingeschakeld?
  • Is er een NSG die uitgaand verkeer van uw integratiesubnet blokkeert?
  • Wordt het verkeer via uw on-premises gateway terug naar Azure gerouteerd als u Azure ExpressRoute of een VPN gebruikt? Als u eindpunten in uw virtuele netwerk kunt bereiken, maar niet on-premises, controleert u uw routes.
  • Hebt u voldoende machtigingen om delegatie in te stellen voor het integratiesubnet? Tijdens de configuratie van regionale virtuele netwerkintegratie wordt uw integratiesubnet gedelegeerd aan Microsoft. Web/serverFarms. De gebruikersinterface voor VNet-integratie delegeert het subnet naar Microsoft. Web/serverFarms automatisch. Als uw account niet over voldoende netwerkmachtigingen beschikt om delegatie in te stellen, hebt u iemand nodig die kenmerken in uw integratiesubnet kan instellen om het subnet te delegeren. Als u het integratiesubnet handmatig wilt delegeren, gaat u naar de gebruikersinterface van het Azure Virtual Network subnet en stelt u de delegatie in voor Microsoft. Web/serverFarms.

Integratie van virtueel netwerk vereist gateway

  • Is het punt-naar-site-adresbereik in de RFC 1918-bereiken (10.0.0.0-10.255.255.255 / 172.16.0.0-172.31.255.255 / 192.168.0.0-192.168.255.255)?
  • Wordt de gateway als actief weergegeven in het portaal? Als uw gateway offline is, zet deze dan weer aan.
  • Worden certificaten gesynchroniseerd of vermoedt u dat de netwerkconfiguratie is gewijzigd? Als uw certificaten niet zijn gesynchroniseerd of als u vermoedt dat er een wijziging is aangebracht in de configuratie van uw virtuele netwerk die niet is gesynchroniseerd met uw ASP's, selecteert u Netwerk synchroniseren.
  • Als u een VPN gebruikt, is de on-premises gateway geconfigureerd om verkeer terug te leiden naar Azure? Als u eindpunten in uw virtuele netwerk kunt bereiken, maar niet on-premises, controleert u uw routes.
  • Probeert u een coexistence-gateway te gebruiken die zowel punt-naar-site als ExpressRoute ondersteunt? Co-existentie-gateways worden niet ondersteund met virtuele netwerkintegratie.

Netwerkproblemen opsporen is een uitdaging omdat u niet kunt zien wat de toegang tot een specifieke combinatie van host:poort blokkeert. Enkele oorzaken zijn:

  • U hebt een firewall op uw host die de toegang tot de toepassingspoort van uw punt-naar-site-IP-bereik voorkomt. Voor het kruisen van subnetten is vaak openbare toegang vereist.
  • Uw doelhost is offline.
  • Uw toepassing is niet beschikbaar.
  • U had het verkeerde IP- of hostnaam.
  • Uw toepassing luistert op een andere poort dan u had verwacht. U kunt uw proces-id vergelijken met de luisterpoort met behulp van 'netstat -aon' op de eindpunthost.
  • Uw netwerkbeveiligingsgroepen worden zodanig geconfigureerd dat ze de toegang tot uw toepassingshost en -poort van uw punt-naar-site-IP-bereik voorkomen.

U weet niet welk adres uw app daadwerkelijk gebruikt. Dit kan elk adres in het integratiesubnet of punt-naar-site-adresbereik zijn, dus u moet toegang vanuit het hele adresbereik toestaan.

Meer stappen voor foutopsporing zijn:

  • Maak verbinding met een virtuele machine in uw virtuele netwerk en probeer uw resourcehost te bereiken: poort vanaf daar. Gebruik de PowerShell-opdracht Test-NetConnection om te testen op TCP-toegang. De syntaxis is:
Test-NetConnection hostname [optional: -Port]
  • Open een toepassing op een VIRTUELE machine en test de toegang tot die host en poort vanuit de console vanuit uw app met behulp van tcpping.

Lokale middelen

Als uw app geen on-premises resource kan bereiken, controleert u of u de resource vanuit uw virtuele netwerk kunt bereiken. Gebruik de PowerShell-opdracht Test-NetConnection om te controleren op TCP-toegang. Als uw VM uw on-premises resource niet kan bereiken, is uw VPN- of ExpressRoute-verbinding mogelijk niet juist geconfigureerd.

Als uw virtuele netwerk-gehoste VM uw on-premises systeem kan bereiken, maar uw app dat niet kan, is de oorzaak waarschijnlijk een van de volgende redenen:

  • Uw routes zijn niet geconfigureerd met uw subnet- of punt-naar-site-adresbereiken in uw on-premises gateway.
  • Uw netwerkbeveiligingsgroepen blokkeren de toegang voor uw punt-naar-site IP-bereik.
  • Uw on-premises firewalls blokkeren verkeer van uw punt-naar-site-IP-bereik.
  • U probeert een niet-RFC 1918-adres te bereiken met behulp van de functie voor regionale integratie van virtuele netwerken.

Het App Service-plan of de web-app verwijderen voordat de verbinding met de VNet-integratie wordt verbroken

Als u de web-app of het App Service-plan hebt verwijderd zonder eerst de VNet-integratie te verbreken, kunt u geen update-/verwijderbewerkingen uitvoeren op het virtuele netwerk of subnet dat is gebruikt voor de integratie met de verwijderde resource. Een subnetdelegering 'Microsoft. Web/serverFarms blijft toegewezen aan uw subnet en voorkomt de update-/verwijderbewerkingen.

Als u het subnet of het virtuele netwerk opnieuw wilt bijwerken/verwijderen, moet u de VNet-integratie opnieuw maken en vervolgens de verbinding verbreken:

  1. Maak het App Service-plan en de web-app opnieuw (het is verplicht om exact dezelfde web-app-naam te gebruiken als voorheen).
  2. Navigeer naar de blade Netwerken in de web-app en configureer de VNet-integratie.
  3. Nadat de VNet-integratie is geconfigureerd, selecteert u de knop Verbinding verbreken.
  4. Verwijder het App Service-plan of de webapp.
  5. Het subnet of het virtuele netwerk bijwerken/verwijderen.

Als u nog steeds problemen ondervindt met de VNet-integratie nadat u de bovenstaande stappen hebt uitgevoerd, neemt u contact op met Microsoft Ondersteuning.

Netwerkprobleemoplosser

U kunt ook de probleemoplosser voor netwerken gebruiken om verbindingsproblemen op te lossen. Als u de probleemoplosser voor netwerken wilt openen, gaat u naar de app in de Azure-portal. Selecteer Diagnostische gegevens en los het probleem op en zoek vervolgens naar de probleemoplosser voor netwerken.

Verbindingsproblemen : hiermee wordt de status van de integratie van het virtuele netwerk gecontroleerd, inclusief het controleren of het privé-IP-adres is toegewezen aan alle exemplaren van het plan en de DNS-instellingen. Als een aangepaste DNS niet is geconfigureerd, wordt standaard Azure DNS toegepast. De probleemoplosser controleert ook op algemene functie-app-afhankelijkheden, waaronder connectiviteit voor Azure Storage en andere bindingsafhankelijkheden.

Schermopname van het uitvoeren van probleemoplosser voor verbindingsproblemen.

Configuratieproblemen : deze probleemoplosser controleert of uw subnet geldig is voor integratie van virtuele netwerken.

Schermopname van het uitvoeren van probleemoplosser voor configuratieproblemen.

Probleem met verwijderen van subnet/VNet: deze probleemoplosser controleert of uw subnet vergrendelingen heeft en of er ongebruikte servicekoppelingen zijn die het verwijderen van het VNet/subnet mogelijk blokkeren.

Meer informatie over netwerken en Azure Functions:

  • Last updated on