Configuration de l’infrastructure Application Gateway
L’infrastructure Azure Application Gateway inclut le réseau virtuel, les sous-réseaux, les groupes de sécurité réseau (NSG) et les itinéraires définis par l’utilisateur (UDR).
Réseau virtuel et sous-réseau dédié
Une passerelle d’application est un déploiement dédié dans votre réseau virtuel. Au sein de votre réseau virtuel, un sous-réseau dédié est nécessaire pour la passerelle d’application. Vous pouvez avoir plusieurs instances d’un déploiement Application Gateway spécifique dans un sous-réseau. Vous pouvez aussi déployer d’autres passerelles d’application dans le sous-réseau. Toutefois, vous ne pouvez pas déployer d’autres ressources dans le sous-réseau Application Gateway. Vous ne pouvez pas combiner les références SKU v1 et v2 Application Gateway sur le même sous-réseau.
Remarque
Les stratégies de points de terminaison de service de réseau virtuel ne sont pas prises en charge dans un sous-réseau Application Gateway.
Taille du sous-réseau
Application Gateway utilise une adresse IP privée par instance ainsi qu’une autre adresse IP privée si une adresse IP front-end privée est configurée.
Azure réserve également cinq adresses IP dans chaque sous-réseau pour une utilisation interne. Il s’agit des quatre premières adresses et des dernières adresses IP. Par exemple, considérez 15 instances Application Gateway sans adresse IP frontale privée. Vous avez besoin d’au moins 20 adresses IP pour ce sous-réseau. Vous avez besoin de 5 pour une utilisation interne et 15 pour les instances Application Gateway.
Considérez un sous-réseau qui a 27 instances Application Gateway et une adresse IP pour une adresse IP frontale privée. Dans ce cas, vous avez besoin de 33 adresses IP. Vous avez besoin de 27 pour les instances Application Gateway, une pour le front-end privé et 5 pour une utilisation interne.
Application Gateway (référence SKU Standard ou WAF) peut prendre en charge jusqu’à 32 instances (32 adresses IP d’instance + 1 configuration IP frontale privée + 5 azure réservé). Nous recommandons une taille minimale de sous-réseau de /26.
Application Gateway (référence SKU Standard_v2 ou WAF_v2) peut prendre en charge jusqu’à 125 instances (125 adresses IP d’instance + 1 configuration IP front-end privée + 5 réservées pour Azure). Nous recommandons une taille minimale de sous-réseau de /24.
Pour déterminer la capacité disponible d’un sous-réseau disposant de passerelles d’application existantes approvisionnées, prenez la taille du sous-réseau et soustrait les cinq adresses IP réservées du sous-réseau réservé par la plateforme. Ensuite, prenez chaque passerelle et soustrait le nombre maximal d’instances. Pour chaque passerelle disposant d’une configuration IP frontale privée, soustrait une adresse IP supplémentaire par passerelle.
Par exemple, voici comment calculer l’adressage disponible pour un sous-réseau avec trois passerelles de tailles différentes :
- Passerelle 1: maximum de 10 instances. Utilise une configuration IP frontale privée.
- Passerelle 2: maximum de 2 instances. Aucune configuration IP frontale privée.
- Passerelle 3: maximum de 15 instances. Utilise une configuration IP frontale privée.
- Taille du sous-réseau: /24
- Taille du sous-réseau /24 – 256 adresses IP – 5 réservés à partir de la plateforme = 251 adresses disponibles
- 251: passerelle 1 (10) – 1 configuration IP frontale privée = 240
- 240: Passerelle 2 (2) – 238
- 238: Passerelle 3 (15) – 1 configuration IP frontale privée – 222
Important
Bien qu’un sous-réseau /24 n’est pas requis par déploiement de référence SKU Application Gateway v2, nous vous recommandons vivement. Un sous-réseau /24 garantit qu’Application Gateway v2 dispose d’un espace suffisant pour l’expansion de la mise à l’échelle automatique et les mises à niveau de maintenance.
Vous devez vous assurer que le sous-réseau Application Gateway v2 dispose d’un espace d’adressage suffisant pour accueillir le nombre d’instances nécessaires pour traiter le trafic maximal attendu. Si vous spécifiez le nombre maximal d’instances, le sous-réseau doit avoir la capacité d’au moins autant d’adresses. Pour la planification de la capacité autour du nombre d’instances, consultez détails du nombre d’instances.
Le sous-réseau nommé GatewaySubnet est réservé aux passerelles VPN. Les ressources Application Gateway v1 utilisant le sous-réseau GatewaySubnet doivent être déplacées vers un autre sous-réseau ou migrées vers la référence SKU v2 avant le 30 septembre 2023, pour éviter les défaillances du plan de contrôle et les incohérences de plateforme. Pour plus d’informations sur la modification du sous-réseau d’une instance Application Gateway existante, consultez Forum aux questions sur Application Gateway.
Conseil
Les adresses IP sont allouées au début de l’espace de sous-réseau défini pour les instances de passerelle. À mesure que les instances sont créées et supprimées en raison de la création de passerelles ou d’événements de mise à l’échelle, il peut devenir difficile de comprendre l’adresse disponible suivante dans le sous-réseau. Si vous devez déterminer l’adresse suivante à utiliser pour une future passerelle et avoir un thème d’adressage contigu pour les adresses IP front-end, vous pouvez attribuer des adresses IP front-end à partir de la moitié supérieure de l’espace de sous-ensemble défini.
Par exemple, si l’espace d’adressage du sous-réseau est 10.5.5.0/24, envisagez de définir la configuration IP frontale privée de vos passerelles à partir de 10.5.5.254, puis de suivre avec 10.5.5.253, 10.5.5.252, 10.5.5.251, etc. pour les passerelles futures.
Il est possible de modifier le sous-réseau d’une instance Application Gateway existante au sein du même réseau virtuel. Pour apporter cette modification, utilisez Azure PowerShell ou Azure CLI. Pour plus d'informations, consultez Forum Aux Questions sur le App Gateway.
Serveurs DNS pour la résolution de noms
La ressource de réseau virtuel prend en charge configuration du serveur DNS , ce qui vous permet de choisir entre les serveurs DNS par défaut fournis par Azure ou personnalisés. Les instances de votre passerelle d’application respectent également cette configuration DNS pour toute résolution de noms. Après avoir modifié ce paramètre, vous devez redémarrer (Arrêter et Démarrer) votre passerelle d’application pour que ces modifications prennent effet sur les instances.
Remarque
Si vous utilisez des serveurs DNS personnalisés dans le réseau virtuel Application Gateway, le serveur DNS doit être en mesure de résoudre les noms Internet publics. Application Gateway nécessite cette fonctionnalité.
Autorisation de réseau virtuel
La ressource Application Gateway est déployée à l’intérieur d’un réseau virtuel. Nous effectuons donc également une vérification pour vérifier l’autorisation sur la ressource de réseau virtuel fournie. Cette validation est effectuée lors des opérations de création et de gestion.
Vérifiez votre contrôle d’accès en fonction du rôle Azure pour vérifier que les utilisateurs (et les principaux de service) qui exploitent des passerelles d’application ont également au moins Microsoft.Network/virtualNetworks/subnets/join/action autorisation sur le réseau virtuel ou le sous-réseau. Cette validation s’applique également aux identités managées pour le contrôleur d’entrée Application Gateway.
Vous pouvez utiliser les rôles intégrés, tels que contributeur réseau, qui prennent déjà en charge cette autorisation. Si un rôle intégré ne fournit pas l’autorisation appropriée, vous pouvez créer et attribuer un rôle personnalisé. En savoir plus sur la gestion des autorisations de sous-réseau.
Remarque
Vous devrez peut-être laisser suffisamment de temps pour actualisation du cache Azure Resource Manager après les modifications de l’attribution de rôle.
Identifier les utilisateurs ou les principaux de service affectés pour votre abonnement
En visitant Azure Advisor pour votre compte, vous pouvez vérifier si votre abonnement dispose d’utilisateurs ou de principaux de service disposant d’autorisations insuffisantes. Les détails de cette recommandation sont les suivants :
Titre: Mettre à jour l’autorisation de réseau virtuel des utilisateurs d’Application Gateway Catégorie: Fiabilité Impact: High
Utiliser l’indicateur AFEC (Feature Exposure Control) temporaire
En tant qu’extension temporaire, nous avons introduit un azure Feature Exposure Control (AFEC) au niveau de l’abonnement. Vous pouvez vous inscrire à l’AFEC et l’utiliser jusqu’à ce que vous corrigez les autorisations pour tous vos utilisateurs et principaux de service. Inscrivez-vous à la fonctionnalité d’évaluation en suivant les mêmes étapes qu’une d’inscription de fonctionnalités en préversion pour votre abonnement Azure.
Nom : Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck Description: Désactiver la vérification des autorisations du sous-réseau Application Gateway ProviderNamespace: Microsoft.Network EnrollmentType: AutoApprove
Remarque
Nous vous suggérons d’utiliser l’approvisionnement AFEC uniquement comme atténuation intermédiaire jusqu’à ce que vous affectiez l’autorisation correcte. Vous devez hiérarchiser la résolution des autorisations pour tous les utilisateurs applicables (et principaux de service), puis annuler l’inscription de cet indicateur AFEC pour réintroduire la vérification des autorisations sur la ressource de réseau virtuel. Nous vous recommandons de ne pas dépendre définitivement de cette méthode AFEC, car elle sera supprimée à l’avenir.
Azure Virtual Network Manager
Azure Virtual Network Manager est un service de gestion qui vous permet de regrouper, de configurer, de déployer et de gérer des réseaux virtuels globalement dans les abonnements. Avec Virtual Network Manager, vous pouvez définir des groupes réseau pour identifier et segmenter de manière logique vos réseaux virtuels. Après cela, vous pouvez déterminer les configurations de connectivité et de sécurité souhaitées et les appliquer sur tous les réseaux virtuels sélectionnés dans des groupes de réseaux à la fois.
La configuration des règles d’administration de sécurité dans Azure Virtual Network Manager vous permet de définir des stratégies de sécurité à grande échelle et de les appliquer à plusieurs réseaux virtuels à la fois.
Remarque
Les règles d’administration de la sécurité d’Azure Virtual Network Manager s’appliquent seulement aux sous-réseaux Application Gateway qui contiennent des passerelles d’application avec l’isolation réseau activée. Les sous-réseaux avec des passerelles d’application avec l’isolation réseau déactivée n’ont pas de règles d’administration de la sécurité.
Groupes de sécurité réseau
Vous pouvez utiliser des groupes de sécurité réseau pour votre sous-réseau Application Gateway, mais tenez compte de certains points clés et restrictions.
Important
Ces limitations de groupe de sécurité réseau sont assouplies lorsque vous utilisez déploiement d’Application Gateway privé (préversion).
Règles de sécurité requises
Pour utiliser un groupe de sécurité réseau avec votre passerelle Application Gateway, vous devez créer ou conserver certaines règles de sécurité essentielles. Vous pouvez définir leur priorité dans le même ordre.
Règles de trafic entrant
Le trafic client: autorisez le trafic entrant à partir des clients attendus (en tant qu’adresse IP source ou plage d’adresses IP) et pour la destination en tant que préfixe IP de sous-réseau entier de votre passerelle d’application et ports d’accès entrant. Par exemple, si vous avez configuré des écouteurs pour les ports 80 et 443, vous devez autoriser ces ports. Vous pouvez également définir cette règle sur Any.
| Source | Ports source | Destination | Ports de destination | Protocole | Accès |
|---|---|---|---|---|---|
<as per need> |
Quelconque | <Subnet IP Prefix> |
<listener ports> |
TCP | Autoriser |
Après avoir configuré écouteurs publics et privés actifs (avec des règles) avec le même numéro de port, votre passerelle d’application modifie l' destination de tous les flux entrants vers les adresses IP frontales de votre passerelle. Cette modification se produit même pour les écouteurs qui ne partagent aucun port. Vous devez inclure les adresses IP publiques et privées de votre passerelle dans la Destination de la règle de trafic entrant lorsque vous utilisez la même configuration de port.
| Source | Ports source | Destination | Ports de destination | Protocole | Accès |
|---|---|---|---|---|---|
<as per need> |
Quelconque | <Public and Private<br/>frontend IPs> |
<listener ports> |
TCP | Autoriser |
Ports d’infrastructure : autorisez les requêtes entrantes à partir de la source comme balise de service GatewayManager et toute destination de . La plage de ports de destination diffère en fonction de la référence SKU et est nécessaire pour communiquer l’état de l’intégrité du back-end. Ces ports sont protégés/verrouillés par des certificats Azure. Les entités externes ne peuvent pas initier de modifications sur ces points de terminaison sans certificats appropriés en place.
- V2 : Ports 65200-65535
- V1 : Ports 65503-65534
| Source | Ports source | Destination | Ports de destination | Protocole | Accès |
|---|---|---|---|---|---|
| GatewayManager | Quelconque | Quelconque | <as per SKU given above> |
TCP | Autoriser |
Sondes Azure Load Balancer : autoriser le trafic entrant à partir de la source en tant que balise de service AzureLoadBalancer . Cette règle est créée par défaut pour groupes de sécurité réseau. Vous ne devez pas la remplacer par une règle manuelle Refuser pour garantir des opérations lisses de votre passerelle Application Gateway.
| Source | Ports source | Destination | Ports de destination | Protocole | Accès |
|---|---|---|---|---|---|
| AzureLoadBalancer | Quelconque | Quelconque | Quelconque | Quelconque | Allow |
Vous pouvez bloquer tout autre trafic entrant à l’aide d’une règle de Refuser tout .
Règles de trafic sortant
Sortant vers internet: autoriser le trafic sortant vers Internet pour toutes les destinations. Cette règle est créée par défaut pour groupes de sécurité réseau. Vous ne devez pas la remplacer par une règle manuelle Refuser pour garantir des opérations lisses de votre passerelle Application Gateway. Les règles de groupe de sécurité réseau sortant qui refusent toute connectivité sortante ne doivent pas être créées.
| Source | Ports source | Destination | Ports de destination | Protocole | Accès |
|---|---|---|---|---|---|
| Quelconque | Quelconque | Internet | Quelconque | Quelconque | Autoriser |
Remarque
Les passerelles Application Gateway qui n’ont pas l’isolation réseau activée n’autorisent pas l’envoi du trafic entre les réseaux virtuels appairés quand Autoriser le trafic vers le réseau virtuel distant est désactivé.
Itinéraires définis par l’utilisateur pris en charge
Le contrôle précis sur le sous-réseau Application Gateway via des règles de table de routage est possible en préversion publique. Pour plus d’informations, consultez déploiement d’Application Gateway privé (préversion).
Avec les fonctionnalités actuelles, certaines restrictions s’appliquent :
Important
L’utilisation de routes définies par l’utilisateur sur le sous-réseau Application Gateway est susceptible d’entraîner l’indication de l’état d’intégrité Inconnu dans l’affichage de l’intégrité du back-end. Elle peut également entraîner l’échec de la génération des journaux et métriques Application Gateway. Nous vous recommandons de ne pas utiliser d’UDR sur le sous-réseau Application Gateway afin de pouvoir afficher l’intégrité du back-end, les journaux et les métriques.
v1 : pour la référence SKU v1, les UDR sont pris en charge sur le sous-réseau Application Gateway s’ils ne modifient pas la communication de requête/réponse de bout en bout. Par exemple, vous pouvez configurer une route définie par l’utilisateur dans le sous-réseau Application Gateway pour pointer vers une appliance de pare-feu afin d’inspecter un paquet. Mais vous devez vérifier que le paquet peut atteindre sa destination prévue après l’inspection. S’il n’y parvient pas, cela peut entraîner un comportement incorrect de la sonde d’intégrité ou du routage du trafic. Les itinéraires appris ou les itinéraires 0.0.0.0/0 par défaut qui sont propagés par Azure ExpressRoute ou les passerelles VPN dans le réseau virtuel sont également inclus.
v2 : pour la référence SKU v2, il existe des scénarios pris en charge et non pris en charge.
Scénarios pris en charge par la v2
Avertissement
Une configuration incorrecte de la table de routage peut entraîner un routage asymétrique dans Application Gateway v2. Vérifiez que tout le trafic du plan de gestion/contrôle est envoyé directement à Internet et non via une appliance virtuelle. La journalisation, les métriques et les vérifications des listes de révocation des certificats peuvent également être concernées.
Scénario 1 : UDR pour désactiver la propagation de l’itinéraire BGP (Border Gateway Protocol) vers le sous-réseau Application Gateway
Parfois, l’itinéraire de la passerelle par défaut (0.0.0.0/0) est publié via les passerelles VPN ou ExpressRoute associées au réseau virtuel Application Gateway. Ce comportement interrompt le trafic du plan de gestion, ce qui nécessite un chemin direct vers Internet. Dans de tels scénarios, vous pouvez utiliser un UDR pour désactiver la propagation de routage BGP.
Pour désactiver la propagation de routage BGP :
- Créez une ressource de table de routage dans Azure.
- Désactivez le paramètre Propagation de la route de la passerelle de réseau virtuel.
- Associez la table de routage au sous-réseau approprié.
L’activation de l’UDR pour ce scénario ne doit pas perturber les configurations existantes.
Scénario 2 : UDR pour diriger 0.0.0.0/0 vers Internet
Vous pouvez créer un UDR pour envoyer le trafic 0.0.0.0/0 directement à Internet.
Scénario 3 : UDR pour Azure Kubernetes Service (AKS) avec kubenet
Si vous utilisez kubenet avec AKS et Application Gateway Ingress Controller, vous avez besoin d’une table de routage pour permettre au trafic envoyé aux pods d’Application Gateway d’être routé vers le nœud approprié. Vous n’avez pas besoin d’utiliser une table de routage si vous utilisez Azure Container Networking Interface.
Pour utiliser la table de routage pour permettre au kubenet de fonctionner :
Accédez au groupe de ressources créé par AKS. Le nom du groupe de ressources doit commencer par
MC_.Recherchez la table de route créée par AKS dans ce groupe de ressources. La table de route doit être remplie avec les informations suivantes :
- Le préfixe d’adresse doit être la plage d’adresses IP des pods que vous souhaitez atteindre dans AKS.
- Le type de tronçon suivant doit être une appliance virtuelle.
- L’adresse du tronçon suivant doit être l’adresse IP du nœud qui héberge les pods.
Associez cette table de route au sous-réseau Application Gateway.
Scénarios non pris en charge par la v2
Scénario 1 : UDR pour les appliances virtuelles
Tout scénario dans lequel 0.0.0.0/0 doit être redirigé via une appliance virtuelle, un réseau virtuel hub/spoke ou un tunneling forcé (tunneling forcé) n’est pas pris en charge pour v2.