Considérations relatives au réseau pour App Service Environment
Important
Cet article concerne la fonctionnalité App Service Environment v2, qui est utilisée avec les plans App Service isolés. App Service Environment v1 et v2 ont été mis hors service le 31 août 2024. Il existe une nouvelle version d’App Service Environment, plus facile à utiliser et qui s’exécute sur des infrastructures plus puissantes. Pour en savoir plus sur la nouvelle version, commencez par consulter Présentation de l’environnement App Service Environment. Si vous utilisez actuellement App Service Environment v1, suivez les étapes de cet article pour migrer vers la nouvelle version.
À compter du 31 août 2024, le Contrat de niveau de service (SLA) et les crédits de service ne s’appliquent plus aux charges de travail App Service Environment v1 et v2 qui sont toujours en production depuis que ce sont des produits mis hors service. La mise hors service du matériel App Service Environment v1 et v2 a commencé, ce qui risque d’avoir une incidence sur la disponibilité et les performances de vos applications et de vos données.
Vous devez effectuer la migration vers App Service Environment v3 immédiatement, sans quoi vos applications et ressources risquent d’être supprimées. Nous ferons tout notre possible pour migrer automatiquement les charges de travail App Service v1 et v2 restantes à l’aide de la fonctionnalité de migration sur place, mais Microsoft ne garantit nullement ni n’affirme que les applications seront disponibles après la migration automatique. Vous serez peut-être amené à effectuer une configuration manuelle pour finaliser la migration et choisir la référence SKU du plan App Service la mieux adaptée à vos besoins. Si la migration automatique n’est pas possible, vos ressources et les données d’application associées seront supprimées. Nous vous recommandons vivement d’agir dès maintenant pour éviter l’un ou l’autre de ces scénarios extrêmes.
Si vous avez besoin de plus de temps, nous pouvons offrir une seule période de grâce de 30 jours pour vous permettre d’effectuer votre migration. Pour plus d’informations et pour demander cette période de grâce, passez en revue la vue d’ensemble de la période de grâce, puis accédez au portail Azure et au panneau Migration pour chacun de vos environnements App Service.
Pour obtenir les informations les plus à jour sur la mise hors service d’App Service Environment v1/v2, consultez la Mise à jour sur la mise hors service d’App Service Environment v1 et v2.
App Service Environment (ASE) est un déploiement d’Azure App Service dans un sous-réseau d’un réseau virtuel Azure. Il existe deux types de déploiement pour un environnement ASE :
- Externe : ce type de déploiement expose les applications hébergées à l’aide d’une adresse IP accessible sur Internet. Pour plus d’informations, consultez Créer un environnement App Service Environment externe.
- Équilibreur de charge interne : ce type de déploiement expose les applications hébergées sur une adresse IP au sein de votre réseau virtuel. Le point de terminaison interne est un équilibreur de charge interne. Pour plus d’informations, consultez Créer et utiliser un environnement App Service Environment avec équilibreur de charge interne.
Notes
Cet article concerne la fonctionnalité App Service Environment v2, qui est utilisée avec les plans App Service isolés.
Quel que soit le type de déploiement, tous les environnements App Service ont une adresse IP virtuelle publique (VIP). Cette adresse IP virtuelle est utilisée pour le trafic de gestion entrant, et comme adresse lorsque vous effectuez des appels à partir de l’environnement ASE vers Internet. De tels appels quittent le réseau virtuel via l’adresse IP virtuelle attribuée à l’environnement ASE.
Si les applications appellent des ressources sur votre réseau virtuel ou par le biais d’un VPN, l’adresse IP source est l’une des adresses IP du sous-réseau. Comme l’environnement ASE se trouve à l’intérieur du réseau virtuel, il peut également accéder aux ressources de celui-ci sans configuration supplémentaire. Si le réseau virtuel est connecté à votre réseau local, les applications ont également accès aux ressources sans configuration supplémentaire.
Si vous avez un environnement ASE avec un déploiement externe, l’adresse IP virtuelle publique est également le point de terminaison de résolution de vos applications pour ce qui suit :
- HTTP/S
- FTP/S
- Déploiement web
- Débogage à distance
Si vous avez un environnement ASE avec un déploiement à équilibreur de charge interne, l’adresse interne est le point de terminaison pour HTTP/S, FTP/S, déploiement web et débogage distant.
Taille du sous-réseau
Une fois l’environnement ASE déployé, vous ne pouvez pas modifier la taille du sous-réseau utilisé pour l’héberger. App Service Environment utilise une adresse pour chaque rôle d’infrastructure, ainsi que pour chaque instance de plan App Service isolé. En outre, les réseaux Azure utilisent cinq adresses pour chaque sous-réseau créé.
Un environnement ASE sans aucun plan App Service utilisera 12 adresses avant la création d’une application. Si vous utilisez le déploiement à équilibreur de charge interne, il utilisera 13 adresses avant la création d’une application. Lorsque vous effectuez un scale-out de votre environnement ASE, sachez que les rôles d’infrastructure sont ajoutés à chaque multiple de 15 ou 20 de vos instances de plan App Service.
Important
Rien d’autre ne peut figurer dans le sous-réseau hormis l’environnement ASE. Veillez à choisir un espace d’adressage qui permet une croissance future. Vous ne pouvez pas modifier ce paramètre par la suite. Nous vous recommandons une taille de /24 avec 256 adresses.
Lorsque vous effectuez une scale-up ou un scale-down, de nouveaux rôles (de taille appropriée) sont ajoutés, puis vos charges de travail sont migrées de la taille actuelle vers la taille cible. Les machines virtuelles d’origine sont supprimées uniquement une fois que les charges de travail ont été migrées. Par exemple, si vous avez un environnement ASE avec 100 instances de plan App Service, il y a un laps de temps pendant lequel vous avez besoin de deux fois plus de machines virtuelles.
Dépendances entrantes et sortantes
Les sections suivantes traitent des dépendances à connaître pour votre environnement ASE. Une autre section traite des paramètres DNS.
Dépendances entrantes
Pour que l’environnement ASE fonctionne, les ports suivants doivent être ouverts :
| Utilisation | À partir | À |
|---|---|---|
| Gestion | Adresses de gestion App Service | Sous-réseau App Service Environment : 454, 455 |
| Communication interne App Service Environment | Sous-réseau App Service Environment : tous les ports | Sous-réseau App Service Environment : tous les ports |
| Autoriser le trafic entrant provenant d’Azure Load Balancer | Équilibrage de charge Azure | Sous-réseau App Service Environment : 16001 |
Les ports 7564 et 1221 peuvent apparaître comme ouverts lors d’une analyse de port. Ils répondent avec une adresse IP, rien de plus. Vous pouvez les bloquer si vous le souhaitez.
Le trafic de gestion entrant fournit la commande et le contrôle de l’environnement ASE en plus du monitoring système. Les adresses sources pour ce trafic sont listées dans Adresses de gestion App Service Environment. La configuration de la sécurité réseau doit autoriser l’accès des adresses de gestion App Service Environment sur les ports 454 et 455. Si vous bloquez l’accès à partir de ces adresses, vous mettez en péril l’intégrité de votre environnement ASE, qui sera suspendu. Le trafic TCP qui arrive sur les ports 454 et 455 doit repasser par la même adresse IP virtuelle, sans quoi vous rencontrerez un problème de routage asymétrique.
Le sous-réseau comprend de nombreux ports utilisés pour la communication des composants internes, et ces ports peuvent changer. Tous les ports du sous-réseau doivent être accessibles à partir du sous-réseau.
Pour permettre la communication entre l’équilibreur de charge Azure et le sous-réseau App Service Environment, les ports 454, 455 et 16001 (au minimum) doivent être ouverts. Si vous utilisez un déploiement à équilibreur de charge interne, vous pouvez limiter le trafic aux ports 454, 455 et 16001. Si vous utilisez un déploiement externe, vous devez prendre en compte les ports d’accès aux applications normaux. Il s’agit plus précisément des ports suivants :
| Utilisation | Ports |
|---|---|
| HTTP/HTTPS | 80, 443 |
| FTP/FTPS | 21, 990, 10001-10020 |
| Débogage distant de Visual Studio | 4020, 4022, 4024 |
| Service Web Deploy | 8172 |
Si vous bloquez les ports d’applications, votre environnement ASE peut continuer à fonctionner, mais votre application risque de ne plus être fonctionnelle. Si vous utilisez des adresses IP affectées par l’application avec un déploiement externe, vous devez autoriser le trafic entre les adresses IP affectées à vos applications et le sous-réseau. Dans le portail App Service Environment, accédez à Adresses IP et vérifiez les ports à partir desquels vous devez autoriser le trafic.
Dépendances sortantes
Pour l’accès sortant, un environnement ASE dépend de plusieurs systèmes externes. Nombre de ces dépendances système sont définies avec des noms DNS, et ne sont pas mappées à un ensemble fixe d’adresses IP. Par conséquent, l’environnement ASE requiert un accès sortant vers toutes les adresses IP sur divers ports à partir de son sous-réseau.
L’environnement ASE communique avec les adresses Internet accessibles sur les ports suivants :
| Utilisations | Ports |
|---|---|
| DNS | 53 |
| NTP | 123 |
| CRL, mises à jour Windows, dépendances Linux, services Azure | 80/443 |
| Azure SQL | 1433 |
| Surveillance | 12 000 |
Les dépendances sortantes sont listées dans Verrouiller un environnement App Service. Si l’environnement ASE perd l’accès à ses dépendances, il cesse de fonctionner. Quand cela se produit pendant un laps de temps suffisamment long, il est suspendu.
DNS client
Si le réseau virtuel est configuré avec un serveur DNS défini par un client, les charges de travail du client l’utilisent. L’environnement ASE utilise Azure DNS à des fins de gestion. Si le réseau virtuel est configuré avec un serveur DNS sélectionné par le client, le serveur DNS doit être accessible à partir du sous-réseau.
Notes
Les montages de stockage ou les tirages d’images conteneur dans App Service Environment v2 ne peuvent pas utiliser le système DNS défini par le client dans le réseau virtuel ou par le biais du paramètre d’application WEBSITE_DNS_SERVER.
Pour tester la résolution DNS de votre application web, vous pouvez utiliser la commande de console nameresolver. Accédez à la fenêtre de débogage du site scm de votre application, ou accédez à l’application dans le portail et sélectionnez la console. À partir de l’invite de l’interpréteur de commandes, vous pouvez émettre la commande nameresolver, avec le nom DNS que vous souhaitez rechercher. Le résultat que vous obtenez est identique à celui qu’obtiendrait l’application pour la même recherche. Si vous utilisez nslookup, effectuez plutôt une recherche à l’aide d’Azure DNS.
Si vous modifiez le paramètre DNS du réseau virtuel dans lequel figure votre environnement ASE, vous devrez procéder à un redémarrage. Pour éviter le redémarrage, nous vous conseillons de configurer vos paramètres DNS pour votre réseau virtuel avant de créer votre environnement ASE.
Dépendances du portail
Outre les dépendances décrites dans les sections précédentes, vous devez tenir compte de quelques considérations supplémentaires liées à l’expérience du portail. Certaines des fonctionnalités du portail Azure dépendent d’un accès direct au site du Gestionnaire de contrôle des services (SCM). Pour chaque application dans Azure App Service, il existe deux URL. La première URL sert à accéder à votre application. La seconde permet d’accéder au site SCM, également désigné sous le nom de console Kudu. Voici quelques-unes des fonctionnalités qui utilisent le site SCM :
- Tâches web
- Fonctions
- Diffusion de journaux
- Kudu
- Extensions
- Process Explorer
- Console
Lorsque vous utilisez un équilibreur de charge interne, le site SCM n’est pas accessible de l’extérieur du réseau virtuel. Certaines fonctionnalités ne fonctionnent pas dans le portail de l’application, car elles nécessitent un accès au site SCM d’une application. Vous pouvez vous connecter au site SCM directement, au lieu de passer par le portail.
Si votre équilibreur de charge interne est le nom de domaine contoso.appserviceenvironment.net et que le nom de votre application est testapp, l’application est accessible à testapp.contoso.appserviceenvironment.net. Le site SCM qui y est associé est accessible à testapp.scm.contoso.appserviceenvironment.net.
Adresses IP
Un environnement ASE a certaines adresses IP que vous devez connaître. Il s'agit des éléments suivants :
- Adresse IP entrante publique : utilisée pour le trafic d’application dans un déploiement externe, et pour le trafic de gestion dans les déploiements internes et externes.
- Adresse IP publique sortante : utilisée en tant qu’adresse IP source pour les connexions sortantes quittant le réseau virtuel. Ces connexions ne sont pas routées vers un réseau privé virtuel.
- Adresse IP de l’équilibreur de charge interne : cette adresse n’existe que dans un déploiement interne.
- Adresses TLS/SSL basées sur IP attribuées par l’application : ces adresses sont uniquement possibles avec un déploiement externe, et lorsque la liaison TLS/SSL basée sur IP est configurée.
Toutes ces adresses IP sont visibles dans le portail Azure, à partir de l’interface utilisateur App Service Environment. Si vous avez un déploiement interne, l’adresse IP de l’équilibreur de charge interne est indiquée.
Notes
Ces adresses IP ne changent pas tant que votre environnement ASE est en cours d’exécution. Si votre environnement ASE est suspendu et ensuite restauré, les adresses utilisées changeront. La cause normale d’une suspension est le blocage de l’accès à la gestion entrante ou à une dépendance.
Adresses IP attribuées par l’application
Avec un déploiement externe, vous pouvez assigner des adresses IP à des applications individuelles. Vous ne pouvez pas le faire avec un déploiement interne. Pour savoir comment configurer votre application de sorte qu’elle possède sa propre adresse IP, consultez Sécuriser un nom DNS personnalisé avec une liaison TLS/SSL dans Azure App Service.
Lorsqu’une application a sa propre adresse SSL basée sur IP, l’environnement ASE réserve deux ports pour le mappage à cette adresse IP. Un port est destiné au trafic HTTP et l’autre au trafic HTTPS. Ces ports sont listés dans la section Adresses IP de votre portail App service Environment. Le trafic doit pouvoir atteindre ces ports à partir de l’adresse IP virtuelle. Dans le cas contraire, les applications sont inaccessibles. Il est important de ne pas oublier cela lorsque vous configurez des groupes de sécurité réseau (NSG).
Groupes de sécurité réseau
Les NSG permettent de contrôler l’accès réseau au sein d’un réseau virtuel. Lorsque vous utilisez le portail, il existe une règle de refus implicite au niveau de priorité le plus bas qui fait que tout accès est refusé. Ce que vous créez sont vos règles d’autorisation.
Vous n’avez pas accès aux machines virtuelles utilisées pour héberger l’environnement ASE proprement dit. Elles se trouvent dans un abonnement géré par Microsoft. Si vous souhaitez restreindre l’accès aux applications, définissez des NSG sur le sous-réseau. Ce faisant, vous devez prêter une attention particulière aux dépendances. Si vous bloquez des dépendances, l’environnement ASE cesse de fonctionner.
Vous pouvez configurer des NSG à l’aide du portail Azure ou de PowerShell. Seul le portail Azure est illustré ici. Les groupes de sécurité réseau sont créés et gérés en tant que ressources de niveau supérieur dans la section Mise en réseau du portail.
Les entrées requises dans un NSG permettent d’autoriser le trafic :
Entrant
- Protocole TCP de l’étiquette de service IP
AppServiceManagementsur les ports 454, 455 - Protocole TCP depuis l’équilibreur de charge sur le port 16001
- Du sous-réseau App Service Environment vers le sous-réseau App Service Environment sur tous les ports
Sortante
- UDP vers toutes les adresses IP sur le port 53
- UDP vers toutes les adresses IP sur le port 123
- Protocole TCP vers toutes les adresses IP sur les ports 80 et 443
- Protocole TCP vers l’étiquette de service IP
Sqlsur le port 1433 - Protocole TCP vers toutes les adresses IP sur le port 12000
- Vers le sous-réseau App Service Environment sur tous les ports
Ces ports n’incluent pas ceux dont vos applications ont besoin pour fonctionner correctement. Par exemple, supposez que votre application doit appeler un serveur MySQL sur le port 3306. Le protocole Network Time Protocol (NTP) sur le port 123 est le protocole de synchronisation date/heure utilisé par le système d'exploitation. Les points de terminaison NTP ne sont pas propres à App Service ; ils peuvent varier avec le système d’exploitation et ne figurent pas dans une liste d’adresses bien définie. Pour éviter les problèmes de synchronisation date/heure, vous devez autoriser le trafic UDP vers toutes les adresses sur le port 123. Le trafic TCP sortant du port 12000 est destiné à la prise en charge et à l’analyse du système. Les points de terminaison sont dynamiques et ne figurent pas dans un ensemble bien défini d’adresses.
Les ports d’accès normaux pour les applications sont les suivants :
| Utilisation | Ports |
|---|---|
| HTTP/HTTPS | 80, 443 |
| FTP/FTPS | 21, 990, 10001-10020 |
| Débogage distant de Visual Studio | 4020, 4022, 4024 |
| Service Web Deploy | 8172 |
Une règle par défaut autorise les adresses IP dans le réseau virtuel à communiquer avec le sous-réseau. Une autre règle par défaut autorise la communication entre l’équilibreur de charge, également appelé l’adresse IP virtuelle publique, et l’environnement ASE. Pour afficher les règles par défaut, sélectionnez Règles par défaut (en regard de l’icône Ajouter).
Si vous placez une règle de refus pour toute autre communication avant les règles par défaut, vous bloquez le trafic entre l’adresse IP virtuelle et l’environnement ASE. Pour éviter le trafic provenant de l’intérieur du réseau virtuel, ajoutez votre propre règle pour autoriser le trafic entrant. Utilisez une source égale à AzureLoadBalancer, avec une destination Tout et une plage de ports *. La règle NSG étant appliquée au sous-réseau, vous n’avez pas besoin de définir une destination spécifique.
Si vous avez attribué une adresse IP à votre application, assurez-vous que vous conservez les ports ouverts. Vous pouvez consulter les ports utilisés en sélectionnant App Service Environment>Adresses IP.
Une fois vos groupes de sécurité réseau définis, vous devez les attribuer au sous-réseau. Si vous ne connaissez pas le réseau virtuel ou le sous-réseau, vous pouvez l’afficher dans le portail App Service Environment. Pour assigner le groupe de sécurité réseau à votre sous-réseau, accédez à l’interface utilisateur du sous-réseau et sélectionnez le groupe de sécurité réseau.
Itinéraires
Le tunneling forcé consiste à définir des routes dans votre réseau virtuel de sorte que le trafic sortant n’accède pas directement à Internet. Au lieu de cela, le trafic est dirigé ailleurs, par exemple vers une passerelle Azure ExpressRoute ou une appliance virtuelle. Si vous devez configurer ainsi votre environnement ASE, consultez Configurer votre environnement App Service avec le tunneling forcé.
Lorsque vous créez un environnement ASE dans le portail, vous créez automatiquement un ensemble de tables de routage sur le sous-réseau. Ces itinéraires donnent simplement l’instruction d’envoyer directement le trafic sortant sur Internet.
Pour créer les mêmes itinéraires manuellement, procédez ainsi :
Accédez au portail Azure et sélectionnez Réseau>Tables d’itinéraires.
Créez une nouvelle table d’itinéraires dans la même région que votre réseau virtuel.
À partir de l’interface utilisateur de votre table d’itinéraires, sélectionnez Itinéraires>Ajouter.
Définissez le Type de tronçon suivant sur Internet et Préfixe de l’adresse sur 0.0.0.0/0. Sélectionnez Enregistrer.
Le résultat suivant s’affiche :
Une fois que vous avez créé la nouvelle table de routage, accédez au sous-réseau. Dans la liste du portail, sélectionnez votre table d’itinéraires. Une fois la modification enregistrée, les groupes de sécurité réseau et les itinéraires s’affichent dans les informations de votre sous-réseau.
Points de terminaison de service
Les points de terminaison de service vous permettent de restreindre l’accès aux services multilocataires à un ensemble de sous-réseaux et de réseaux virtuels Azure. Pour plus d’informations, consultez Points de terminaison de service de réseau virtuel.
Lorsque vous activez les points de terminaison de service sur une ressource, certaines routes sont créées avec une priorité plus élevée que d’autres. Si vous utilisez des points de terminaison de service sur un service Azure, avec un environnement ASE à tunneling forcé, le trafic vers ces services n’est pas tunnelé de force.
Lorsque des points de terminaison de service sont activés sur un sous-réseau avec une instance d’Azure SQL, toutes les instances d’Azure SQL sollicitées à partir de ce sous-réseau doivent avoir des points de terminaison de service activés. Si vous voulez accéder à plusieurs instances d’Azure SQL à partir du même sous-réseau, vous ne pouvez pas activer les points de terminaison de service sur une instance d’Azure SQL et pas sur une autre. Aucun autre service Azure ne se comporte comme Azure SQL en ce qui concerne les points de terminaison de service. Lorsque vous activez les points de terminaison de service avec Stockage Azure, vous verrouillez l’accès à cette ressource à partir de votre sous-réseau. Toutefois, vous pouvez toujours accéder à d’autres comptes Stockage Azure, même s’ils n’ont pas de points de terminaison de service activés.
