options de mise en réseau Azure Functions

Cet article décrit les fonctionnalités de mise en réseau disponibles dans les options d’hébergement pour Azure Functions. Les options de mise en réseau suivantes peuvent être catégorisées en tant que fonctionnalités de mise en réseau entrantes et sortantes. Les fonctionnalités entrantes vous permettent de restreindre l’accès à votre application, alors que les fonctionnalités sortantes vous permettent de connecter votre application à des ressources sécurisées par un réseau virtuel, et de contrôler le routage du trafic sortant.

Les modèles d’hébergement offrent différents niveaux d’isolement réseau. Le choix de l’option appropriée vous aide à répondre à vos besoins d’isolement réseau.

Fonctionnalité Plan Consommation Flex Plan Consommation Plan Premium Plan dédié/ASE Container Apps1
Restrictions d’accès entrant ✅ ✅ ✅ ✅ ✅ 2
Points de terminaison privés (entrants) ✅ ❌ ✅ ✅ ❌
Points de terminaison de service (entrants) ✅ ❌ ✅ ✅ ✅
Intégration de réseau virtuel (sortant) ✅ ❌ ✅ ✅ 3 ✅
Connexions hybrides ❌ ❌ ✅ (Windows uniquement) ✅ (Windows uniquement) ✅ (Windows uniquement)
  1. Pour plus d’informations, consultez Mise en réseau dans l'environnement Azure Container Apps.
  2. Géré via la configuration d’entrée de l’environnement Container Apps.
  3. Le plan Dédié/ASE prend également en charge l’intégration au réseau virtuel requise par la passerelle.

Ressources de démarrage rapide

Utilisez les ressources suivantes pour commencer rapidement à utiliser Azure Functions scénarios de mise en réseau. Ces ressources sont référencées dans l’article.

Restrictions d’accès entrant

Vous pouvez utiliser des restrictions d’accès pour définir une liste triée par priorité d’adresses IP autorisées ou refusées d’accès à votre application. La liste peut inclure des adresses IPv4 et IPv6 ou des sous-réseaux spécifiques de réseau virtuel utilisant des points de terminaison de service. Lorsqu’il y a une ou plusieurs entrées, une règle implicite « Tout refuser » se trouve à la fin de la liste. Les restrictions d’adresse IP fonctionnent avec toutes les options d’hébergement de fonction.

Remarque

Avec les restrictions réseau en place, vous pouvez déployer uniquement à partir de votre réseau virtuel, ou lorsque vous placez l'adresse IP de la machine que vous utilisez pour accéder au portail Azure sur la liste des destinataires Safe. Toutefois, vous pouvez toujours gérer la fonction à l’aide du portail.

Pour plus d’informations, consultez Azure App Service restrictions d’accès statique.

Lors de l’exécution sur Container Apps, l’accès entrant est géré par le biais de la configuration d’entrée de l’environnement Container Apps plutôt que des restrictions d’accès App Service. Pour plus d’informations, consultez les restrictions IP dans Azure Container Apps.

Points de terminaison privés (entrants)

Azure Point de terminaison privé est une interface réseau qui vous connecte en privé et en toute sécurité à un service alimenté par Azure Private Link. Le point de terminaison privé utilise une adresse IP privée de votre réseau virtuel pour apporter le service à votre réseau virtuel de façon effective.

Vous pouvez utiliser un point de terminaison privé pour vos fonctions hébergées dans les plans Flex Consumption, Elastic Premium et Dedicated (App Service ).

Si vous souhaitez effectuer des appels vers des points de terminaison privés, vous devez vous assurer que vos recherches DNS seront résolues sur le point de terminaison privé. Vous pouvez appliquer ce comportement de l’une des façons suivantes :

  • Intégrer avec les zones privées d'Azure DNS. Lorsque votre réseau virtuel n’a pas de serveur DNS personnalisé, cette opération est effectuée automatiquement.
  • Gérer le point de terminaison privé dans le serveur DNS utilisé par votre application. Pour gérer un point de terminaison privé, vous devez connaître l’adresse du point de terminaison, et utiliser un enregistrement A pour référencer le point de terminaison que vous tentez d’atteindre.
  • Configurez votre propre serveur DNS pour transférer vers Azure DNS zones privées.

Pour plus d’informations, consultez utilisant des points de terminaison privés pour Web Apps.

Pour appeler d’autres services qui disposent d’une connexion de point de terminaison privé, par exemple Stockage ou Service Bus, veillez à configurer votre application pour effectuer des appels sortants vers des points de terminaison privés. Pour plus d’informations sur l’utilisation de points de terminaison privés avec le compte de stockage de votre application de fonction, consultez restreindre votre compte de stockage à un réseau virtuel.

Points de terminaison de service (entrants)

À l’aide de points de terminaison de service, vous pouvez limiter de nombreux services Azure aux sous-réseaux de réseau virtuel sélectionnés pour fournir un niveau de sécurité plus élevé. L’intégration de réseau virtuel régional permet à votre fonction d'application d’atteindre les services Azure qui sont sécurisés par des points de terminaison de service. Cette configuration est prise en charge sur tous les plans qui prennent en charge l’intégration du réseau virtuel. Suivez ces étapes pour accéder à un point de terminaison de service sécurisé :

  1. Configurez l’intégration de réseau virtuel régional avec votre application de fonction pour vous connecter à un sous-réseau spécifique.
  2. Accédez au service de destination et configurez des points de terminaison de service sur le sous-réseau d’intégration.

Pour plus d’informations, consultez Points de terminaison de service de réseau virtuel.

Utiliser des points de terminaison de service

Pour restreindre l’accès à un sous-réseau spécifique, créez une règle de restriction avec un type Réseau virtuel. Vous pouvez ensuite sélectionner l’abonnement, le réseau virtuel et le sous-réseau auxquels vous souhaitez accorder ou refuser l’accès.

Si les points de terminaison de service ne sont pas déjà activés avec Microsoft.Web pour le sous-réseau que vous avez sélectionné, ils sont automatiquement activés, sauf si vous sélectionnez la case à cocher Ignorer les points de terminaison de service Microsoft.Web manquants. Le scénario dans lequel vous voudriez activer des points de terminaison de service sur l’application, mais pas sur le sous-réseau, dépend principalement du fait que vous disposiez ou non des autorisations pour les activer sur le sous-réseau.

Si vous avez besoin d'une autre personne pour activer les points de terminaison de service sur le sous-réseau, sélectionnez la case à cocher Ignorer les points de terminaison de service Microsoft.Web manquants. Votre application est configurée pour les points de terminaison de service, que vous activez plus tard sur le sous-réseau.

Screenshot du volet « Ajouter une restriction IP » avec le type Réseau virtuel selected.

Vous ne pouvez pas utiliser de points de terminaison de service pour restreindre l'accès aux applications qui s'exécutent dans un App Service Environment. Lorsque votre application se trouve dans un App Service Environment, vous pouvez contrôler l’accès à celle-ci en appliquant des règles d’accès IP.

Pour savoir comment configurer des points de terminaison de service, consultez Établir l'accès privé au site des fonctions Azure.

Intégration de réseau virtuel (sortant)

Cette section détaille les fonctionnalités prises en charge par Functions pour contrôler les données sortantes de votre application.

L’intégration au réseau virtuel permet à votre application de fonction d’accéder aux ressources de votre réseau virtuel. Une fois intégrée, votre application route le trafic sortant via le réseau virtuel. Cela permet à votre application d’accéder à des ressources ou des points de terminaison privés avec des règles autorisant le trafic provenant uniquement de sous-réseaux sélectionnés. Lorsque la destination est une adresse IP en dehors du réseau virtuel, l’adresse IP source est toujours envoyée à partir de l’une des adresses répertoriées dans les propriétés de votre application, sauf si vous avez configuré une passerelle NAT.

Azure Functions prend en charge l’intégration de réseau virtuel régional, qui est l’approche recommandée. Pour savoir comment configurer l’intégration d’un réseau virtuel, consultez Activer l’intégration d’un réseau virtuel.

Azure Functions prend en charge deux types d’intégration de réseau virtuel :

Pour savoir comment configurer l’intégration d’un réseau virtuel, consultez Activer l’intégration d’un réseau virtuel.

Intégration de réseau virtuel régional (sortant)

L’utilisation de l’intégration au réseau virtuel régional permet à votre application d’accéder aux :

  • Ressources dans le même réseau virtuel que votre application.
  • Ressources dans les réseaux virtuels appairés au réseau virtuel auquel votre application est intégrée.
  • Services sécurisés des points de terminaison de service.
  • Ressources sur les connexions Azure ExpressRoute.
  • Ressources sur des connexions appairées, notamment des connexions Azure ExpressRoute.
  • Points de terminaison privés.

Lorsque vous utilisez l’intégration de réseau virtuel régional, vous pouvez utiliser les fonctionnalités de mise en réseau Azure suivantes :

  • Groupes de sécurité réseau (NSG) : vous pouvez bloquer le trafic sortant à l’aide d’un NSG placé sur votre sous-réseau d’intégration. Les règles de trafic entrant ne s’appliquent pas, car vous ne pouvez pas utiliser l’intégration au réseau virtuel pour fournir un accès entrant à votre application.
  • Tables de route (UDR) : vous pouvez placer une table de route sur le sous-réseau d’intégration pour envoyer le trafic sortant à l’emplacement de votre choix.

Remarque

Lorsque vous routez tout le trafic sortant vers votre réseau virtuel, il est soumis aux groupes de sécurité réseau et aux routes définies par l’utilisateur appliqués à votre sous-réseau d’intégration. Lorsque le réseau virtuel est intégré, le trafic sortant de votre application de fonction vers les adresses IP publiques est toujours envoyé à partir des adresses répertoriées dans les propriétés de votre application, sauf si vous fournissez des itinéraires qui dirigent le trafic ailleurs.

L’intégration au réseau virtuel régional ne peut pas utiliser le port 25.

Considérations relatives au plan Flex Consumption :

  • L’application et le réseau virtuel doivent se trouver dans la même région.
  • Vérifiez que le fournisseur de ressources Azure est activé pour votre abonnement en suivant ces instructions. Cela est nécessaire pour la délégation de sous-réseau. Le portail Azure et Azure CLI appliquer cette inscription lorsque vous créez une application Flex Consumption, car l’intégration de réseau virtuel peut être activée à tout moment après la création de votre application.
  • La délégation de sous-réseau requise lors de l’exécution dans un plan Flex Consumption est Microsoft.App/environments. Cela diffère des plans Élastique Premium et Dédié (App Service), qui ont une autre exigence de délégation.
  • Vous pouvez planifier l’utilisation de 40 adresses IP au maximum pour une application de fonction, même si l’application est mise à l’échelle au-delà de 40. Par exemple, si vous avez 15 applications de fonction Consommation flexible intégrées au même sous-réseau, vous devez planifier 15 x 40 = 600 adresses IP utilisées au maximum. Cette limite est sujette à modification et n’est pas appliquée.
  • Le sous-réseau ne peut pas déjà être utilisé à d’autres fins (par exemple, des points de terminaison privés ou de service, ou délégués à tout autre plan ou service d’hébergement). Bien que vous puissiez partager le même sous-réseau avec plusieurs applications Consommation flexible, les ressources réseau sont partagées entre ces applications de fonction, ce qui peut donner lieu à une situation où une application impacte les performances des autres applications sur le même sous-réseau.
  • Vous ne pouvez pas partager le même sous-réseau entre un environnement Container Apps et une application Flex Consumption.
  • Le plan Flex Consumption ne prend actuellement pas en charge les sous-réseaux dont les noms contiennent des caractères de soulignement (_).

Considérations relatives aux plans Élastique Premium, Dédié (App Service) et Container Apps :

  • La fonctionnalité est disponible pour Élastique Premium ainsi que pour App Service Premium V2 et Premium V3. Elle est également disponible au niveau Standard, mais uniquement pour les déploiements App Service les plus récents. Si vous êtes sur un déploiement plus ancien, vous ne pouvez utiliser la fonctionnalité qu’à partir d’un plan App Service Premium V2. Si vous souhaitez vous assurer de pouvoir utiliser la fonctionnalité dans un plan App Service Standard, créez votre application dans un plan App Service Premium v3. Ces plans ne sont pris en charge que sur les déploiements les plus récents. Vous pouvez effectuer un scale-down par la suite si vous le souhaitez.
  • Les applications en plan isolé hébergées dans un App Service Environment ne peuvent pas exploiter cette fonctionnalité.
  • L’application et le réseau virtuel doivent se trouver dans la même région.
  • La fonctionnalité nécessite un sous-réseau qui est un /28 ou plus dans un réseau virtuel Azure Resource Manager.
  • Plusieurs plans App Service peuvent utiliser le sous-réseau d’intégration.
  • Vous pouvez disposer de jusqu’à deux intégrations au réseau virtuel régional par plan App Service. Plusieurs applications d’un même plan App Service peuvent utiliser le même sous-réseau d’intégration.
  • Le sous-réseau que vous choisissez ne peut pas être déjà utilisé à d’autres fins, comme avec des points de terminaison privés ou des points de terminaison de service, ni être délégué à tout autre plan d’hébergement ou service.
  • Vous pouvez partager le même sous-réseau avec plusieurs applications dans un plan App Service. Étant donné que les ressources réseau sont partagées entre toutes les applications, une application de fonction peut affecter les performances des autres sur le même sous-réseau.
  • Vous ne pouvez pas supprimer un réseau virtuel avec une application intégrée. Supprimez l’intégration avant de supprimer le réseau virtuel.
  • Vous ne pouvez pas changer l’abonnement d’une application ou d’un plan quand une application utilise l’intégration au réseau virtuel régional.

Activer l’intégration de réseau virtuel

  1. Dans votre application de fonction dans le portail Azure, sous Settings sélectionnez Networking. Ensuite, sous Réseau virtuel Integration sélectionnez Not configuré à ajouter.

  2. Sélectionnez Ajouter une intégration de réseau virtuel.

    Capture d’écran de la page d’intégration de réseau virtuel dans laquelle vous pouvez activer l’intégration de réseau virtuel dans votre application.

  3. La liste déroulante contient tous les réseaux virtuels Azure Resource Manager dans votre abonnement dans la même région. Sélectionnez le réseau virtuel que vous voulez intégrer.

    Sélectionner le réseau virtuel

    • Les plans d’hébergement Consommation flexible et Élastique Premium prennent uniquement en charge l’intégration au réseau virtuel régional. Si le réseau virtuel se trouve dans la même région, créez un sous-réseau ou sélectionnez un sous-réseau vide et préexistant.

    • Pour sélectionner un réseau virtuel dans une autre région, vous devez disposer d’une passerelle de réseau virtuel provisionnée dont l’option Point à site est activée. L’intégration du réseau virtuel entre les régions est uniquement prise en charge pour les plans dédiés, mais les peerings mondiaux fonctionnent avec l’intégration du réseau virtuel régional.

Lors de l’intégration, votre application est redémarrée. Une fois l’intégration terminée, vous pourrez voir des informations sur le réseau virtuel auquel vous êtes intégré. Par défaut, l’option Tout router est activée, et tout le trafic est routé vers votre réseau virtuel.

Si vous préférez uniquement router votre trafic privé (trafic RFC1918), suivez les étapes décrites dans cet article sur App Service.

Sous-réseaux

L’intégration au réseau virtuel dépend d’un sous-réseau dédié. Lorsque vous approvisionnez un sous-réseau, Azure réserve les cinq premières adresses IP pour une utilisation interne. La façon dont les adresses IP restantes sont consommées dépend de votre plan d’hébergement. Comme la taille du sous-réseau ne peut pas être modifiée après l’affectation, utilisez un sous-réseau suffisamment grand pour s’adapter à l’échelle que votre application est susceptible d’atteindre.

Le tableau suivant récapitule les exigences de sous-réseau pour chaque plan d’hébergement :

Plan d’hébergement Intégration au réseau virtuel Taille minimale du sous-réseau Taille de sous-réseau recommandée Délégation de sous-réseau
Consommation flexible Soutenu /27 /27 (application unique), /26 (plusieurs applications) Microsoft.App/environments
Elastic Premium (Windows) Soutenu /28 /24 Microsoft.Web/serverFarms
Elastic Premium (Linux) Soutenu /28 /26 Microsoft.Web/serverFarms
Dédié (App Service) Soutenu /28 /26 ou plus Microsoft.Web/serverFarms
Container Apps Géré par environnement Consultez le réseau de Container Apps Consultez le réseau de Container Apps Microsoft.App/environments
Consommation Non pris en charge N/A N/A N/A

Veillez à sélectionner votre plan d’hébergement en haut de l’article pour obtenir des détails spécifiques au plan.

Lors de l’exécution sur Azure Container Apps, l’intégration de réseau virtuel est gérée via l’environnement Container Apps. Le dimensionnement et la configuration du sous-réseau sont déterminés par l’environnement Container Apps, et non par l’application de fonction directement. Pour plus d’informations, consultez Mise en réseau dans l'environnement Azure Container Apps.

Dans les plans Elastic Premium et Dedicated (App Service), chaque instance en cours d’exécution de votre application de fonction consomme une adresse IP à partir du sous-réseau. Lorsque vous effectuez une mise à l'échelle vers le haut ou vers le bas, l'espace d'adressage requis peut temporairement doubler afin de prendre en charge la transition. Si plusieurs applications partagent le même sous-réseau, l’utilisation totale de l’adresse IP est la somme de toutes les instances de ces applications, ainsi que le doublement temporaire pendant les événements de mise à l’échelle.

Scénarios de consommation IP

Scénario Consommation d’adresses IP
Une application, une instance Une adresse IP
Une application, cinq instances Cinq adresses IP
Une application, capable de s'adapter de cinq à dix instances Jusqu’à 20 adresses IP (temporaires, pendant l’opération de mise à l’échelle)
Trois applications, cinq instances chacune 15 adresses IP

Recommandations relatives à la plage CIDR

Taille de bloc CIDR Nombre maximal d’adresses disponibles Échelle horizontale maximale (instances)1
/28 11 5
/27 27 13
/26 59 29
/25 123 612
/24 251 1253
  1. Supposez que vous devez effectuer une augmentation ou une réduction de la taille ou de la référence SKU, à un moment donné.
  2. Bien que le nombre d’adresses IP prenne en charge 61 instances, les applications individuelles du plan dédié ont un maximum de 30 instances.
  3. Bien que le nombre d’adresses IP prenne en charge 125 instances, les applications individuelles du plan Elastic Premium ont un maximum de 100 instances.

Considérations supplémentaires

  • Pour éviter tout problème lié à la capacité de sous-réseau pour les plans Functions Elastic Premium, vous devez utiliser un /24 avec 256 adresses pour Windows et un /26 avec 64 adresses pour Linux. Lors de la création de sous-réseaux dans Azure portail dans le cadre de l’intégration au réseau virtuel, une taille minimale de /24 et /26 est requise pour Windows et Linux respectivement.
  • Chaque plan App Service peut prendre en charge jusqu’à deux sous-réseaux qui peuvent être utilisés pour l’intégration au réseau virtuel. Plusieurs applications d’un même plan App Service peuvent rejoindre le même sous-réseau, mais les applications d’un autre plan ne peuvent pas utiliser ce sous-réseau.

Dans le plan Flex Consumption, le trafic réseau sortant à partir d’instances d’application de fonction est routé via des passerelles partagées dédiées au sous-réseau. Au maximum 27 passerelles partagées (27 adresses IP) sont utilisées par sous-réseau, quel que soit le nombre d’applications intégrées. Lorsqu’un sous-réseau est utilisé pour trop d’instances ou pour les applications effectuant des charges de travail nécessitant beaucoup d’E/S, des problèmes de capacité réseau tels que l’augmentation de la latence et les délais d’expiration peuvent se produire. La mise à l’échelle horizontale des applications ne sera pas impactée.

Important

L’intégration d’applications de fonction Flex Consumption avec une taille de sous-réseau inférieure à /27 ou l’intégration de plusieurs applications avec un sous-réseau de taille /27 réduit la capacité réseau sortante disponible pour eux. Si vous envisagez de le faire, testez la charge de vos applications avec des charges de travail à l'échelle de la production pour vous assurer qu'aucune contrainte de capacité réseau n'est constatée.

Recommandations relatives à la plage CIDR

Taille de bloc CIDR Adresses utilisables Instances maximales Recommandation
/27 27 1 000 Recommandé pour une application de fonction unique
/26 59 1,000+ Recommandé pour plusieurs applications ou lors de la mise à l’échelle au-delà de 1 000 instances*

* Contactez le groupe de produits pour demander une augmentation du nombre d’instances maximal.

Groupes de sécurité réseau

Vous pouvez utiliser des groupes de sécurité réseau pour contrôler le trafic entre les ressources de votre réseau virtuel. Par exemple, vous pouvez créer une règle de sécurité qui empêche le trafic sortant de votre application d’atteindre une ressource de votre réseau virtuel, ou de quitter le réseau. Ces règles de sécurité s’appliquent aux applications pour lesquelles l’intégration au réseau virtuel a été configurée. Pour bloquer le trafic vers les adresses publiques, l’intégration au réseau virtuel et l’option Router tout doivent être activées. Les règles de trafic entrant dans un groupe de sécurité réseau ne s’appliquent pas à votre application, car l’intégration au réseau virtuel n’a d’incidence que sur le trafic sortant depuis votre application.

Pour contrôler le trafic entrant vers votre application, utilisez la fonctionnalité Restrictions d’accès. Un groupe de sécurité réseau appliqué à votre sous-réseau d’intégration est actif quelles que soient les routes appliquées à votre sous-réseau d’intégration. Si votre application de fonction est intégrée à un réseau virtuel avec l’option Router tout activée, et si vous n’avez aucune route qui affecte le trafic des adresses publiques sur votre sous-réseau d’intégration, l’ensemble de votre trafic sortant est toujours soumis aux groupes NSG affectés à votre sous-réseau d’intégration. Lorsque l’option Tout router n’est pas activée, les groupes de sécurité réseau sont appliqués uniquement au trafic RFC1918.

Itinéraires

Vous pouvez utiliser des tables de routage pour router le trafic sortant depuis votre application vers où vous voulez. Par défaut, les tables de routage affectent seulement votre trafic de destination RFC1918. Quand l’option Router tout est activée, tous vos appels sortants sont affectés. Lorsque vous désactivez Route All, vos tables de routage affectent uniquement le trafic privé (RFC1918). Les routes définies sur votre sous-réseau d’intégration n’affectent pas les réponses aux requêtes d’application entrantes. Les destinations courantes peuvent inclure des pare-feu ou des passerelles.

Si vous souhaitez router tout le trafic sortant localement, vous pouvez utiliser une table de route pour envoyer l’intégralité du trafic sortant vers votre passerelle ExpressRoute. Si vous choisissez de router le trafic vers une passerelle, veillez à définir des routes dans le réseau externe pour renvoyer des réponses.

Les routes BGP (Border Gateway Protocol) affectent également le trafic de votre application. Si vous avez des routes BGP provenant par exemple d’une passerelle ExpressRoute, le trafic sortant de votre application est affecté. Par défaut, les routes BGP affectent seulement votre trafic de destination RFC1918. Lorsque votre application de fonctions est intégrée à un réseau virtuel avec Route All activé, tout le trafic sortant peut être influencé par vos itinéraires BGP.

Restrictions d’adresse IP sortantes

Vous pouvez configurer des restrictions sortantes pour le réseau virtuel où votre App Service Environment est déployé.

Lorsque vous intégrez une application de fonction à un réseau virtuel dans le cadre d’un plan Premium élastique ou App Service, l’application est toujours en mesure de passer des appels sortants vers Internet par défaut. En intégrant votre application de fonction à un réseau virtuel avec l’option Tout router activée, vous forcez l’envoi de tout le trafic sortant vers votre réseau virtuel, où des règles de groupe de sécurité réseau peuvent être utilisées pour restreindre le trafic. Pour Flex Consumption, tout le trafic est déjà routé par le réseau virtuel et Route All n’est pas nécessaire.

Pour savoir comment contrôler l’adresse IP sortante à l’aide d’un réseau virtuel, consultez Tutorial : Contrôler Azure Functions adresse IP sortante avec une passerelle NAT de réseau virtuel Azure.

zones privées Azure DNS

Une fois que votre application s’intègre à votre réseau virtuel, elle utilise le même serveur DNS que celui avec lequel votre réseau virtuel est configuré et fonctionne avec les zones privées Azure DNS liées au réseau virtuel.

Automatisation

Les API suivantes vous permettent de gérer par programmation les intégrations de réseaux virtuels régionaux :

les connexions hybrides

Hybrid Connections est une fonctionnalité de Azure Relay que vous pouvez utiliser pour accéder aux ressources d’application dans d’autres réseaux. Elles permettent d’accéder depuis votre application à un point de terminaison d’application. Vous ne pouvez pas l’utiliser pour accéder à votre application.

Comme utilisé dans Azure Functions, chaque connexion hybride est corrélée à une seule combinaison d’hôtes ET de ports TCP. Cela signifie que le point de terminaison de connexion hybride peut se trouver sur un quelconque système d’exploitation et toute application tant que vous accédez à un port d’écoute TCP. La fonctionnalité Connexions hybrides ne détecte pas et ne prend pas en compte le protocole d’application ou les ressources auxquels vous accédez. Elle fournit simplement un accès réseau.

Pour plus d’informations, consultez la documentation App Service pour les connexions hybrides. Ces mêmes étapes de configuration prennent en charge Azure Functions.

Important

Les connexions hybrides ne sont prises en charge que lorsque votre application de fonction s’exécute sur Windows. Les applications Linux ne sont pas prises en charge.

Connexion à Azure Services via un réseau virtuel

L’intégration au réseau virtuel permet à votre application de fonction d’accéder aux ressources d’un réseau virtuel. Cette section présente une vue d’ensemble des éléments à prendre en compte quand vous tentez de connecter votre application à certains services.

Restreindre votre compte de stockage à un réseau virtuel

Remarque

Pour déployer rapidement une application de fonction avec des points de terminaison privés activés sur le compte de stockage, reportez-vous au modèle suivant : Application de fonction avec points de terminaison privés stockage Azure.

Lorsque vous créez une application de fonctions, vous devez créer ou lier à un compte de stockage Azure à usage général prenant en charge le stockage Blob, Queue et Table. Vous pouvez remplacer ce compte de stockage par un compte sécurisé avec des points de terminaison de service ou privés.

Pour découvrir comment configurer votre application de fonction avec un compte de stockage sécurisé avec un réseau virtuel, consultez Restreindre votre compte de stockage à un réseau virtuel.

Vous devez vous assurer que le routage du partage de contenu privé est configuré. Pour découvrir comment configurer votre application de fonction avec un compte de stockage sécurisé avec un réseau virtuel, consultez Restreindre votre compte de stockage à un réseau virtuel.

Pour découvrir comment configurer votre application de fonction avec un compte de stockage sécurisé avec un réseau virtuel, consultez Restreindre votre compte de stockage à un réseau virtuel.

Utiliser des références Key Vault

Vous pouvez utiliser Azure Key Vault références pour utiliser des secrets de Azure Key Vault dans votre application Azure Functions sans nécessiter de modifications de code. Azure Key Vault est un service qui fournit une gestion centralisée des secrets, avec un contrôle total sur les stratégies d’accès et l’historique d’audit.

Si l’intégration de réseau virtuel est configurée pour l’application, des références Key Vault peuvent être utilisées pour récupérer des secrets d’un coffre avec restrictions de réseau.

Déclencheurs de réseau virtuel (non HTTP)

Votre charge de travail peut nécessiter que votre application soit déclenchée à partir d’une source d’événement protégée par un réseau virtuel.

Remarque

Lors de l’exécution sur Azure Container Apps, les déclencheurs de réseau virtuel sont gérés via la configuration réseau de l’environnement Container Apps. Pour plus d’informations, consultez Mise en réseau dans l'environnement Azure Container Apps.

Le plan Flex Consumption prend en charge en mode natif les déclencheurs de réseau virtuel. Votre application de fonction peut être déclenchée à partir de sources d’événements protégées par un réseau virtuel sans nécessiter de configuration supplémentaire pour la surveillance de l’échelle du runtime.

Le plan Elastic Premium vous permet de créer des fonctions qui déclenchent des services sécurisés par un réseau virtuel. Ces déclencheurs non HTTP sont appelés déclencheurs de réseau virtuel.

Le plan Elastic Premium vous permet de créer des fonctions qui déclenchent des services sécurisés par un réseau virtuel.

Par défaut, les déclencheurs de réseau virtuel n’entraînent pas de mise à l’échelle de votre application de fonction au-delà de leur nombre d’instances préchauffées. Toutefois, certaines extensions prennent en charge des déclencheurs de réseau virtuel qui entraînent la mise à l’échelle dynamique de votre application de fonction. Vous pouvez activer cette surveillance à l’échelle dynamique dans votre application de fonction pour les extensions prises en charge de l’une des manières suivantes :

  1. Dans le portail Azure, accédez à votre application de fonction.

  2. Sous Paramètres, sélectionnez Configuration, puis dans l’onglet Paramètres d’exécution de la fonction définissez la Supervision de l'échelle de runtime sur Activée.

  3. Sélectionnez Enregistrer pour mettre à jour la configuration de l’application de fonction et redémarrer l’application.

VNETToggle

Conseil

L’activation de l’analyse des déclencheurs de réseau virtuel peut affecter les performances de votre application, bien que l’impact soit probablement petit.

La prise en charge de la surveillance dynamique des déclencheurs de réseau virtuel n’est pas disponible dans la version 1.x du runtime Fonctions.

Les extensions de cette table prennent en charge la surveillance dynamique de l’échelle des déclencheurs de réseau virtuel. Pour obtenir les meilleures performances de mise à l’échelle, vous devez effectuer une mise à niveau vers des versions qui prennent également en charge la mise à l’échelle basée sur des cibles.

Extension (version minimale) Surveillance de l’échelle du runtime uniquement Avec mise à l’échelle basée sur des cibles
Microsoft.Azure. WebJobs.Extensions.CosmosDB > 3.0.5 > 4.1.0
Microsoft.Azure. WebJobs.Extensions.DurableTask > 2.0.0 n/a
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*

* Uniquement avec le stockage de file d'attente.

Important

Lorsque vous activez la surveillance des déclencheurs de réseau virtuel, seuls les déclencheurs pour ces extensions peuvent entraîner la mise à l’échelle dynamique de votre application. Vous pouvez toujours utiliser des déclencheurs provenant d’extensions qui ne figurent pas dans ce tableau, mais ils ne provoqueront pas de mise à l’échelle au-delà de leur nombre d’instances préchauffées. Pour obtenir la liste complète de toutes les extensions de déclencheur et de liaison, consultez Déclencheurs et liaisons.

Lorsque votre application de fonction s’exécute dans un plan App Service ou dans un App Service Environment, vous pouvez développer des fonctions déclenchées par des ressources sécurisées par un réseau virtuel. Pour que vos fonctions se déclenchent correctement, votre application doit être connectée à un réseau virtuel ayant accès à la ressource définie dans la connexion du déclencheur.

Par exemple, supposons que vous souhaitez configurer Azure Cosmos DB pour accepter le trafic uniquement à partir d’un réseau virtuel. Dans ce cas, vous devez déployer votre application de fonction dans un plan App Service fournissant une intégration de réseau virtuel à ce réseau virtuel. L’intégration permet à cette ressource Azure Cosmos DB de déclencher une fonction.

Test des points de terminaison privés

Lorsque vous testez des fonctions dans une application de fonction avec des points de terminaison privés, vous devez effectuer vos tests à partir du même réseau virtuel, par exemple sur une machine virtuelle de ce réseau. Pour utiliser l’option Code + Test dans le portail à partir de cette machine virtuelle, vous devez ajouter les origines CORS suivantes à votre application de fonction :

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

Lorsque vous limitez l’accès à votre application de fonction avec des points de terminaison privés ou toute autre restriction d’accès, vous devez également ajouter la balise AzureCloud de service à la liste autorisée. Pour mettre à jour la liste verte :

  1. Accédez à votre application de fonction et sélectionnez Paramètres>Mise en réseau. Sous Configuration du trafic entrant>Accès réseau public, sélectionnez Activé sans restriction d’accès.

  2. Vérifiez que Accès au réseau public est défini sur Activé à partir de la sélection des réseaux virtuels et des adresses IP.

  3. Ajouter une règle sous Accès au site et règles :

    1. Sélectionnez Service Tag en tant que Typede paramètres source et AzureCloud comme Balise de service.

    2. Vérifiez que l’action est Autoriser, puis définissez le nom et la priorité souhaités.

Dépannage

Cette fonctionnalité est facile à configurer, mais il est possible que vous rencontriez des problèmes. Si vous rencontrez des difficultés pour accéder au point de terminaison souhaité, certains utilitaires vous permettent de tester la connectivité à partir de la console de l’application. Vous pouvez utiliser deux consoles : L’une est la console Kudu, et l’autre est la console dans le portail Azure. Pour accéder à la console Kudu à partir de votre application, accédez à Outils>Kudu. Vous pouvez également accéder à la console Kudo via le site [nom du site].scm.azurewebsites.net. Une fois le site web chargé, accédez à l’onglet Debug console. Pour accéder à la console hébergée sur le portail Azure à partir de votre application, accédez à Tools>Console.

Outils

Dans les applications Windows natives, les outils ping, nslookup et tracert ne fonctionne pas via la console en raison de contraintes de sécurité (elles fonctionnent dans custom Windows conteneurs). Deux outils distincts ont été ajoutés pour les remplacer. Pour tester les fonctionnalités DNS, nous avons ajouté un outil nommé nameresolver.exe. La syntaxe est :

nameresolver.exe hostname [optional: DNS Server]

Vous pouvez utiliser nameresolver pour vérifier les noms d’hôte dont dépend votre application. De cette façon, vous pouvez tester si des éléments de votre serveur DNS sont mal configurés ou si vous n’avez pas accès à votre serveur DNS. Vous pouvez identifier le serveur DNS qu’utilise votre application dans la console en examinant les variables d’environnement WEBSITE_DNS_SERVER et WEBSITE_DNS_ALT_SERVER.

Remarque

L'outil nameresolver.exe ne fonctionne actuellement pas dans des conteneurs Windows personnalisés.

Vous pouvez utiliser l’outil suivant pour tester la connectivité TCP avec une combinaison hôte-port. Il s’agit de l’outil tcpping, dont la syntaxe est la suivante :

tcpping.exe hostname [optional: port]

L’utilitaire tcpping vous indique si vous pouvez atteindre un hôte et un port spécifiques. Il ne peut réussir que si une application écoute au niveau de la combinaison hôte-port et si l’accès réseau de votre application à l’hôte et au port spécifiés est disponible.

Déboguer l’accès aux ressources hébergées sur un réseau virtuel

Plusieurs choses peuvent empêcher votre application d’atteindre un hôte et un port spécifiques. La plupart du temps, il s’agit de l’une des trois raisons suivantes :

  • Un pare-feu se trouve sur le trajet. Si vous avez un pare-feu sur le trajet, vous dépassez le délai d’expiration de TCP. Dans pareil cas, il est de 21 secondes. Utilisez l’outil tcpping pour tester la connectivité. Les dépassements du délai d’expiration de TCP peuvent avoir de nombreuses autres causes, mais commencez par vérifier ce point.
  • DNS n’est pas accessible. Le délai d’expiration de DNS est de 3 secondes par serveur DNS. Si vous avez deux serveurs DNS, le délai d’expiration est de 6 secondes. Utilisez nameresolver pour voir le DNS fonctionne. Vous ne pouvez pas utiliser nslookup, car il n’utilise pas le DNS avec lequel votre réseau virtuel est configuré. S’il n’est pas accessible, il se peut qu’un pare-feu ou un groupe de sécurité réseau (NSG) bloque l’accès au DNS ou que celui-ci ne fonctionne pas.

Si ces éléments ne suffisent pas à résoudre vos problèmes, commencez par vous poser les questions suivantes :

Intégration du réseau virtuel régional

  • Votre destination est-elle une adresse non RFC1918 sans l’Itinéraire activé ?
  • Y a-t-il un groupe de sécurité réseau qui bloque la sortie de votre sous-réseau d’intégration ?
  • Si vous passez par Azure ExpressRoute ou un VPN, votre passerelle locale est-elle configurée pour acheminer le trafic vers Azure ? Si vous pouvez accéder à des points de terminaison dans votre réseau virtuel, mais pas en local, vérifiez vos routes.
  • Disposez-vous d’autorisations suffisantes pour définir la délégation sur le sous-réseau d’intégration ? Pendant la configuration d’intégration de réseau virtuel régional, votre sous-réseau d’intégration est délégué à Microsoft. Web/serverFarms. L’interface utilisateur d’intégration au réseau virtuel délègue le sous-réseau à Microsoft. Web/serverFarms automatiquement. Si votre compte ne dispose pas d’autorisations de mise en réseau suffisantes pour définir la délégation, vous devez demander à une personne autorisée de configurer les attributs de votre sous-réseau d’intégration de manière à déléguer celui-ci. Pour déléguer manuellement le sous-réseau d’intégration, accédez à l’interface utilisateur du sous-réseau Réseau virtuel Azure et définissez la délégation pour Microsoft. Web/serverFarms.

Intégration au réseau virtuel avec passerelle obligatoire

  • La plage d’adresses de point à site se trouve-t-elle dans les plages RFC 1918 (10.0.0.0 à 10.255.255.255, 172.16.0.0 à 172.31.255.255 ou 192.168.0.0 à 192.168.255.255) ?
  • Le portail indique-t-il que la passerelle fonctionne ? Si votre passerelle est en panne, réparez-la.
  • Les certificats apparaissent-ils comme étant synchronisés ou soupçonnez-vous une modification de la configuration réseau ? Si vos certificats ne sont pas synchronisés ou si vous pensez qu’une modification apportée à la configuration de votre réseau virtuel n’a pas été synchronisée avec vos ASP, sélectionnez Synchroniser le réseau.
  • Si vous passez par un VPN, la passerelle locale est-elle configurée pour acheminer le trafic vers Azure ? Si vous pouvez accéder à des points de terminaison dans votre réseau virtuel, mais pas en local, vérifiez vos routes.
  • Essayez-vous d’utiliser une passerelle de coexistence qui prend en charge à la fois la connectivité point à site et la connectivité ExpressRoute ? Les passerelles de coexistence ne sont pas prises en charge avec l’intégration au réseau virtuel.

Le débogage des problèmes réseau est un vrai défi, car vous ne pouvez pas voir ce qui bloque l’accès à une combinaison hôte-port spécifique. Les causes peuvent inclure :

  • Un pare-feu activé sur l’hôte empêche l’accès au port de l’application à partir de votre plage d’adresses IP de point à site. Des sous-réseaux croisés requièrent souvent un accès public.
  • Votre hôte cible ne fonctionne pas.
  • Votre application est arrêtée.
  • L’IP ou le nom d’hôte sont incorrects.
  • Votre application est à l’écoute sur un port autre que celui auquel vous vous attendiez. Vous pouvez faire correspondre votre ID de processus avec le port d’écoute en utilisant « netstat -aon » sur l’hôte du point de terminaison.
  • Vos groupes de sécurité réseau sont configurés de telle sorte qu’ils empêchent l’accès à l’hôte et au port de votre application à partir de votre plage d’adresses IP de point à site.

Vous ne savez pas quelle adresse votre application utilise réellement. Cela peut être n’importe quelle adresse de la plage d’adresses de sous-réseau d’intégration ou de point à site. De ce fait, vous devez autoriser l’accès depuis toutes les adresses de la plage.

Voici d’autres étapes de débogage :

  • Connectez-vous à une machine virtuelle de votre réseau virtuel et essayez d’atteindre la combinaison hôte-port de vos ressources à partir de là. Pour tester l’accès à TCP, utilisez la commande PowerShell Test-NetConnection. La syntaxe est :
Test-NetConnection hostname [optional: -Port]
  • Démarrez une application sur une machine virtuelle, puis testez l’accès à ces hôte et port à partir de la console de votre application en utilisant l’outil tcpping.

Ressources locales

Si votre application ne peut pas accéder à une ressource locale, vérifiez si vous pouvez atteindre la ressource à partir de votre réseau virtuel. Utilisez la commande PowerShell Test-NetConnection pour vérifier l’accès à TCP. Si votre machine virtuelle ne peut pas accéder à votre ressource locale, votre connexion VPN ou ExpressRoute n’est peut-être pas configurée correctement.

Si votre machine virtuelle hébergée sur le réseau virtuel peut atteindre votre système local, mais que votre application ne le peut pas, la raison en est probablement l’une des suivantes :

  • Vos routes ne sont pas configurés avec vos plages d’adresses de sous-réseau ou de point à site dans votre passerelle locale.
  • Vos groupes de sécurité réseau bloquent l’accès de votre plage d’adresses IP de point à site.
  • Vos pare-feu locaux bloquent le trafic provenant de votre plage d’adresses IP point à site.
  • Vous tentez d’atteindre une adresse qui ne figure pas dans la RFC 1918 en utilisant la fonctionnalité d’intégration de réseau virtuel régionale.

Suppression du plan App Service ou de l’application web avant la déconnexion de l’intégration au réseau virtuel

Si vous supprimez l’application web ou le plan App Service sans déconnecter l’intégration au réseau virtuel au préalable, vous ne pourrez pas effectuer d’opérations de mise à jour/suppression sur le réseau virtuel ou le sous-réseau utilisé pour l’intégration avec la ressource supprimée. Une délégation de sous-réseau 'Microsoft.Web/serverFarms' restera affectée à votre sous-réseau et va empêcher les opérations de mise à jour / suppression.

Afin de mettre à jour/supprimer à nouveau le sous-réseau ou le réseau virtuel, vous devez recréer l’intégration au réseau virtuel et la déconnecter :

  1. Recréez le plan App Service et l’application web (il est obligatoire d’utiliser le même nom d’application web que précédemment).
  2. Accédez au panneau « Mise en réseau » de l’application web et configurez l’intégration au réseau virtuel.
  3. Une fois l’intégration au réseau virtuel configurée, sélectionnez le bouton « Déconnexion ».
  4. Supprimez le plan App Service ou l’application web.
  5. Mettez à jour/supprimez le sous-réseau ou le réseau virtuel.

Si vous rencontrez toujours des problèmes avec l’intégration au réseau virtuel après avoir suivi les étapes ci-dessus, contactez Support Microsoft.

Utilitaire de résolution des problèmes réseau

Vous pouvez également utiliser l’utilitaire de résolution des problèmes réseau pour résoudre les problèmes de connexion. Pour ouvrir l’utilitaire de résolution des problèmes réseau, accédez à l’application dans le portail Azure. Sélectionnez Diagnostiquer et résoudre le problème, puis recherchez Utilitaire de résolution des problèmes réseau.

Problèmes de connexion : il vérifie l’état de l’intégration du réseau virtuel, notamment si l’adresse IP privée a été affectée à toutes les instances du plan et les paramètres DNS. Si un DNS personnalisé n'est pas configuré, la Azure DNS par défaut est appliquée. L’utilitaire de résolution des problèmes vérifie également les dépendances courantes de l’application de fonction, notamment la connectivité pour stockage Azure et d’autres dépendances de liaison.

Capture d’écran montrant l’utilitaire de résolution des problèmes au travail sur des problèmes de connexion.

Problèmes de configuration : cet utilitaire de résolution des problèmes vérifie si votre sous-réseau est valide pour l’intégration de réseau virtuel.

Capture d’écran montrant l’utilitaire de résolution des problèmes au travail sur des problèmes de configuration.

Problème de suppression de sous-réseau/réseau virtuel : cet utilitaire de résolution des problèmes vérifie si votre sous-réseau a des verrous et s’il a des liens d’association de service inutilisés qui peuvent bloquer la suppression du réseau virtuel/sous-réseau.

Pour en savoir plus sur la mise en réseau et les Azure Functions :

  • Last updated on