Configurer votre environnement App Service avec le tunneling forcé

Article
06/01/2023

Important

Cet article concerne la fonctionnalité App Service Environment v2, qui est utilisée avec les plans App Service isolés. App Service Environment v2 sera 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 v2, suivez les étapes de cet article pour migrer vers la nouvelle version.

Depuis le 29 janvier 2024, vous ne pouvez plus créer de ressources App Service Environment v2 à l’aide de l’une des méthodes disponibles, notamment les modèles ARM/Bicep, le portail Azure, Azure CLI ou l’API REST. Vous devez migrer vers App Service Environment v3 avant le 31 août 2024 pour empêcher la suppression des ressources et la perte de données.

L’environnement ASE (App Service Environment) est un déploiement d’Azure App Service dans le réseau virtuel Azure d’un client. De nombreux clients configurent leurs réseaux virtuels Azure en tant qu’extensions de leurs réseaux locaux avec des réseaux privés virtuels ou des connexions Azure ExpressRoute. Le tunneling forcé consiste à rediriger le trafic Internet sortant vers votre réseau privé virtuel ou vers une appliance virtuelle. Les appliances virtuelles servent souvent à inspecter et à auditer le trafic réseau sortant.

L’environnement ASE a de nombreuses dépendances externes, décrites dans ce document sur l’architecture réseau de l’environnement App Service. Normalement, tout le trafic de dépendance sortant de l’ASE doit passer par l’adresse IP virtuelle qui est configurée avec l’ASE. Si vous modifiez le routage du trafic vers ou depuis l’ASE sans tenir compte des informations ci-dessous, votre ASE cessera de fonctionner.

Dans un réseau virtuel Azure, le routage repose sur la correspondance de préfixe la plus longue. S’il existe plusieurs itinéraires avec la même correspondance de préfixe la plus longue, un itinéraire est sélectionné en fonction de son origine dans l’ordre suivant :

Itinéraire défini par l’utilisateur (UDR)
Itinéraire BGP (lorsque ExpressRoute est utilisé)
Itinéraire du système

Pour en savoir plus sur le routage dans un réseau virtuel, consultez Routages définis par l’utilisateur et transfert IP.

Si vous souhaitez acheminer le trafic sortant de votre environnement ASE vers une autre destination que directement vers Internet, vous pouvez choisir parmi les options suivantes :

Autoriser votre ASE à avoir un accès direct à Internet
Configurer votre sous-réseau ASE de manière à ignorer les itinéraires BGP
Configurer votre sous-réseau ASE pour qu’il utilise des points de terminaison de service vers Azure SQL et Stockage Azure
Ajouter vos propres adresses IP au pare-feu Azure SQL de l’ASE

Configurer votre environnement App Service pour qu’il dispose d’un accès Internet direct

Pour activer votre ASE afin qu’il accède directement à Internet, même si votre réseau virtuel Azure est configuré avec ExpressRoute, vous pouvez :

Configurer ExpressRoute pour qu’il publie 0.0.0.0/0. Par défaut, il achemine de force tout le trafic sortant local.
Créer un UDR avec le préfixe d’adresse 0.0.0.0/0 et le type de tronçon Internet suivant, puis l’appliquer au sous-réseau ASE.

Si vous apportez ces deux modifications, le trafic à destination d’Internet provenant du sous-réseau de l’environnement App Service n’est plus acheminé de force via la connexion ExpressRoute.

Si le réseau achemine déjà du trafic en local, vous devez alors créer le sous-réseau pour héberger votre ASE et configurer son UDR avant de procéder au déploiement de l’ASE.

Important

Les itinéraires définis dans un UDR doivent être suffisamment spécifiques pour avoir la priorité sur les itinéraires annoncés par la configuration ExpressRoute. L’exemple précédent utilise la plage d’adresses 0.0.0.0/0 large. Il peut potentiellement être remplacé accidentellement par des annonces de routage utilisant des plages d’adresses plus spécifiques.

Les environnements App Service ne sont pas pris en charge avec les configurations ExpressRoute qui annoncent de façon croisée des itinéraires à partir du chemin d’accès d’homologation publique vers le chemin d’accès d’homologation privée. Les configurations ExpressRoute ayant un peering public configuré reçoivent les publications de routage de Microsoft. Les publications contiennent un grand ensemble de plages d’adresses Microsoft Azure. Si ces plages d’adresses sont publiées de façon croisée sur le chemin d’accès d’homologation privée, il en résulte que tous les paquets réseau sortants du sous-réseau de l’environnement App Service sont acheminés vers l’infrastructure réseau locale d’un client. Ce flux de réseau n’est pas pris en charge par défaut par les environnements App Service. L’une des solutions à ce problème consiste à arrêter les itinéraires croisés depuis le chemin d’accès d’homologation publique vers le chemin d’accès d’homologation privée. Une autre solution consiste à autoriser votre environnement App Service à fonctionner dans une configuration de tunneling forcé.

Direct internet access

Configurer votre sous-réseau ASE de manière à ignorer les itinéraires BGP

Vous pouvez configurer votre sous-réseau ASE de manière à ignorer les itinéraires BGP. Lorsqu’il est configuré pour ignorer les routes BGP, l’ASE peut accéder à ses dépendances sans problème. Toutefois, vous devrez créer des UDR pour permettre à vos applications d’accéder aux ressources locales.

Pour configurer votre sous-réseau ASE de manière à ignorer les itinéraires BGP :

créez un UDR et affectez-le à votre sous-réseau ASE si vous n’en n’avez pas encore.
Dans le portail Azure, ouvrez l’interface utilisateur pour la table de routage affectée à votre sous-réseau ASE. Sélectionnez une configuration. Définissez la Propagation de la route de la passerelle de réseau virtuel sur Désactivée. Cliquez sur Enregistrer. La documentation sur la désactivation se trouve dans le document Créer une table de routage.

Une fois que vous avez configuré le sous-réseau ASE de façon à ignorer toutes les routes BGP, vos applications ne peuvent plus accéder aux ressources locales. Pour permettre aux applications d’accéder aux ressources locales, modifiez l’UDR affecté à votre sous-réseau ASE, puis ajoutez des routes pour vos plages d’adresses locales. Le type de tronçon suivant doit être défini sur Passerelle de réseau virtuel.

Configurer votre ASE avec des points de terminaison de service

Pour acheminer tout le trafic sortant à partir de votre ASE, à l’exception de celui qui est acheminé vers Azure SQL et Stockage Azure, procédez comme suit :

Créez une table de routage et affectez-la à votre sous-réseau ASE. Pour retrouver les adresses qui correspondent à votre région, consultez Adresses de gestion de l’environnement Azure App Service. Créez des itinéraires pour ces adresses ou utilisez l’étiquette de service AppServiceManagement avec un tronçon Internet suivant. Ces routes sont nécessaires, car le trafic de gestion entrant de l’environnement ASE doit répondre à partir de la même adresse que celle à laquelle il a été envoyé.
Activez des points de terminaison de service avec Azure SQL et Stockage Azure pour votre sous-réseau ASE. Une fois cette étape terminée, vous pouvez ensuite configurer votre réseau virtuel avec le tunneling forcé.

Pour plus d’informations sur le déploiement d’un ASE à l’aide d’un modèle, consultez Créer un environnement ASE à l’aide d’un modèle.

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 en savoir plus sur les points de terminaison de service, consultez la documentation Points de terminaison de service de réseau virtuel.

Lorsque vous activez les points de terminaison de service sur une ressource, certains itinéraires sont créés avec une priorité plus élevée que d’autres. Si vous utilisez des points de terminaison de service avec un ASE tunnelisé de force, le trafic de gestion Azure SQL et Stockage Azure n’est pas tunnelisé de force. L’autre trafic de dépendance ASE est tunnelisé de force et ne peut pas être perdu, ou l’ASE ne fonctionnerait pas correctement.

Lorsque les points de terminaison de service sont activés sur un sous-réseau avec une instance Azure SQL, toutes les instances Azure SQL connectées à partir de ce sous-réseau doivent avoir des points de terminaison de service activés. Si vous souhaitez accéder à plusieurs instances Azure SQL à partir du même sous-réseau, vous ne pouvez pas activer les points de terminaison de service sur une instance Azure SQL et pas sur une autre. Stockage Azure ne se comporte pas de la même manière qu’Azure SQL. 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, mais pourrez toujours accéder aux autres comptes Stockage Azure même si les points de terminaison de service ne sont pas activés.

Si vous configurez le tunneling forcé avec une appliance de filtre de réseau, n’oubliez pas que l’ASE possède des dépendances en plus d’Azure SQL et de Stockage Azure. Si le trafic vers ces dépendances est bloqué, l’environnement ASE ne fonctionnera pas correctement.

Forced tunnel with service endpoints

Ajouter vos propres adresses IP au pare-feu Azure SQL de l’ASE

Pour tunneliser tout le trafic sortant à partir de votre ASE, à l’exception de celui qui est acheminé vers Stockage Azure, procédez comme suit :

Créez une table de routage et affectez-la à votre sous-réseau ASE. Pour retrouver les adresses qui correspondent à votre région, consultez Adresses de gestion de l’environnement Azure App Service. Créez des itinéraires pour ces adresses avec un tronçon Internet suivant. Ces routes sont nécessaires, car le trafic de gestion entrant de l’environnement ASE doit répondre à partir de la même adresse que celle à laquelle il a été envoyé.
Activer des points de terminaison de service avec Stockage Azure pour votre sous-réseau ASE
Recherchez les adresses qui seront utilisées pour tout le trafic sortant de votre environnement App Service vers Internet. Si vous effectuez un tunneling forcé, il s’agit de vos adresses NAT ou adresses IP de passerelle. Si vous voulez acheminer le trafic sortant de l’environnement App Service via une appliance virtuelle réseau, l’adresse de sortie est l’adresse IP publique de l’appliance.
Pour définir les adresses de sortie dans un environnement ASE existant : accédez à resources.azure.com, puis à Subscription/<ID d’abonnement>/resourceGroups/<groupe de ressources ASE>/providers/Microsoft.Web/hostingEnvironments/<nom ASE>. Vous voyez ainsi le code JSON qui décrit votre environnement App Service. Vérifiez que la mention read/write apparaît au début. Sélectionnez Modifier. Faites défiler vers le bas. Modifiez la valeur userWhitelistedIpRangesnull en quelque chose qui ressemble à ce qui suit. Utiliser les adresses que vous souhaitez définir en tant que plage d’adresses de sortie.
```
"userWhitelistedIpRanges": ["11.22.33.44/32", "55.66.77.0/24"]
```
Sélectionnez PUT (Placer) en haut. Cette option déclenche une opération de mise à l’échelle de votre environnement App Service et ajuste le pare-feu.

Pour créer votre ASE avec les adresses de sortie : suivez les instructions données dans Créer un ASE à l’aide d’un modèle et tirez (pull) le modèle approprié. Modifiez la section « resources » dans le fichier azuredeploy.json, mais pas dans le bloc « properties », et incluez une ligne pour userWhitelistedIpRanges avec vos valeurs.

"resources": [
    {
        "apiVersion": "2015-08-01",
        "type": "Microsoft.Web/hostingEnvironments",
        "name": "[parameters('aseName')]",
        "kind": "ASEV2",
        "location": "[parameters('aseLocation')]",
        "properties": {
            "name": "[parameters('aseName')]",
            "location": "[parameters('aseLocation')]",
            "ipSslAddressCount": 0,
            "internalLoadBalancingMode": "[parameters('internalLoadBalancingMode')]",
            "dnsSuffix" : "[parameters('dnsSuffix')]",
            "virtualNetwork": {
                "Id": "[parameters('existingVnetResourceId')]",
                "Subnet": "[parameters('subnetName')]"
            },
            "userWhitelistedIpRanges":  ["11.22.33.44/32", "55.66.77.0/30"]
        }
    }
]

Ces modifications envoient le trafic directement vers Stockage Azure à partir de l’ASE et autorisent l’accès à Azure SQL à partir des adresses supplémentaires autres que l’adresse IP virtuelle de l’ASE.

Forced tunnel with SQL allowlist

Éviter les problèmes

Si la communication entre l’ASE et ses dépendances est interrompue, l’ASE sera défectueux. S’il reste défectueux trop longtemps, l’ASE sera suspendu. Pour annuler la suspension de l’ASE, suivez les instructions de votre portail ASE.

Outre la simple interruption de la communication, vous pouvez nuire à votre ASE si vous introduisez trop de latence. Une trop grande latence peut se produire si votre ASE est trop loin de votre réseau local. « Trop loin » peut signifier traverser un océan ou un continent pour atteindre le réseau local, par exemple. De la latence peut également être introduite en raison d’une surcharge de l’Intranet ou de contraintes de bande passante sortante.

Partager via