Configurer votre environnement App Service avec le tunneling forcé

Article
08/22/2024

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.

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é.

Accès direct à Internet

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.

Tunneling forcé avec points de terminaison de service

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.

Tunneling forcé avec une liste d’autorisation SQL

É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