Accès sortant par défaut dans Azure

Dans Azure, lorsque vous déployez une machine virtuelle dans un réseau virtuel sans méthode de connectivité sortante explicitement définie, Azure l’affecte automatiquement à une adresse IP publique sortante. Cette adresse IP permet la connectivité sortante des ressources vers Internet et vers d’autres points de terminaison publics au sein de Microsoft. Cet accès est appelé accès sortant par défaut.

Voici quelques exemples de connectivité sortante explicite pour les machines virtuels :

• Déployé dans un sous-réseau associé à une passerelle NAT.
• Déployé dans le pool principal d’un équilibreur de charge standard avec des règles sortantes définies.
• Déployé dans le pool principal de l’équilibreur de charge public de base.
• Des machines virtuelles avec des adresses IP publiques explicitement associées.

Comment et quand l’accès sortant par défaut est fourni

Si une machine virtuelle est déployée sans méthode de connectivité sortante explicite, Azure lui attribue une adresse IP publique sortante par défaut. Cette adresse IP, connue sous le nom d’adresse IP d’accès sortant par défaut, appartient à Microsoft et peut changer sans préavis. Il n’est pas recommandé pour les charges de travail de production.

Remarque

Dans certains cas, une adresse IP sortante par défaut est quand même affectée aux machines virtuelles d’un sous-réseau non privé, même lorsqu’une méthode sortante explicite (telle qu’une NAT Gateway ou un itinéraire UDR qui dirige le trafic vers une appliance virtuelle réseau/un pare-feu) est configurée. Cela ne signifie pas que les adresses IP sortantes par défaut sont utilisées pour la sortie, sauf si ces méthodes explicites sont supprimées. Pour supprimer complètement les adresses IP sortantes par défaut, le sous-réseau doit être rendu privé et les machines virtuelles doivent être arrêtées et libérées.

Important

Après le 31 mars 2026, les nouveaux réseaux virtuels utilisent par défaut des sous-réseaux privés, ce qui signifie qu’une méthode sortante explicite doit être activée pour atteindre des points de terminaison publics sur Internet et dans Microsoft. Pour plus d’informations, consultez l’annonce officielle. Nous vous recommandons d’utiliser une des formes explicites de connectivité décrites dans la section suivante. Pour d’autres questions, consultez la section « FAQ : Changement de comportement par défaut vers des sous-réseaux privés ».

Pourquoi la désactivation de l’accès sortant par défaut est-elle recommandée ?

Sécurité : l’accès Internet par défaut contredit les principes de confiance zéro.
Clarté : la connectivité explicite est préférée à l’accès implicite.
Stabilité : l’adresse IP sortante par défaut n’est pas détenue par le client et peut changer, ce qui entraîne des perturbations potentielles.

Voici quelques exemples de configurations qui ne fonctionnent pas lors de l’utilisation de l’accès sortant par défaut :

• Plusieurs cartes réseau sur une machine virtuelle peuvent produire des adresses IP sortantes incohérentes
• La mise à l'échelle des Azure Virtual Machine Scale Sets peut entraîner une modification des adresses IP sortantes.
• Les adresses IP sortantes ne sont pas cohérentes ou contiguës entre les instances d'un ensemble d'échelles de machines virtuelles.

En outre :

• Les adresses IP d’accès sortantes par défaut ne prennent pas en charge les paquets fragmentés
• Les adresses IP d’accès sortant par défaut ne prennent pas en charge les tests ping ICMP

Comment passer à une méthode explicite de connectivité publique (et désactiver l’accès sortant par défaut) ?

Vue d’ensemble des sous-réseaux privés

• La création d’un sous-réseau privé empêche les machines virtuelles du sous-réseau d’utiliser l’accès sortant par défaut pour se connecter aux points de terminaison publics.
• Les machines virtuelles sur un sous-réseau privé peuvent toujours accéder à Internet (ou à tout point de terminaison public au sein de Microsoft) à l’aide d’une connectivité sortante explicite.

  Remarque

  Certains services ne fonctionnent pas sur une machine virtuelle dans un sous-réseau privé sans méthode explicite de sortie (par exemple, activation Windows et mises à jour Windows).

Comment configurer des sous-réseaux privés

• Dans le portail Azure, sélectionnez le sous-réseau et cochez la case pour activer le sous-réseau privé, comme indiqué :

• À l’aide de PowerShell, le script suivant prend les noms du groupe de ressources et du réseau virtuel et effectue une boucle via chaque sous-réseau pour activer le sous-réseau privé.

$resourceGroupName = ""
$vnetName = ""
 
$vnet = Get-AzVirtualNetwork -ResourceGroupName $resourceGroupName -Name $vnetName
 
foreach ($subnet in $vnet.Subnets) {
    if ($subnet.DefaultOutboundAccess -eq $null) {
        $subnet.DefaultOutboundAccess = $false
        Write-Output "Set 'defaultoutboundaccess' to \$false for subnet: $($subnet.Name)"
    } 
    elseif ($subnet.DefaultOutboundAccess -eq $false) {
        # Output message if the value is already $false
        Write-Output "already private for subnet: $($subnet.Name)"
    }
}
Set-AzVirtualNetwork -VirtualNetwork $vnet

• À l’aide de l’interface CLI, mettez à jour le sous-réseau avec az network vnet subnet update et définissez --default-outbound sur « false »

az network vnet subnet update --resource-group rgname --name subnetname --vnet-name vnetname --default-outbound false

• En utilisant un modèle du Gestionnaire de ressources Azure, définissez la valeur du paramètre defaultOutboundAccess sur « false »

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "vnetName": {
      "type": "string",
      "defaultValue": "testvm-vnet"
    },
    "subnetName": {
      "type": "string",
      "defaultValue": "default"
    },
    "subnetPrefix": {
      "type": "string",
      "defaultValue": "10.1.0.0/24"
    },
    "vnetAddressPrefix": {
      "type": "string",
      "defaultValue": "10.1.0.0/16"
    }
  },
  "resources": [
    {
      "type": "Microsoft.Network/virtualNetworks",
      "apiVersion": "2023-11-01",
      "name": "[parameters('vnetName')]",
      "location": "westus2",
      "properties": {
        "addressSpace": {
          "addressPrefixes": [
            "[parameters('vnetAddressPrefix')]"
          ]
        },
        "subnets": [
          {
            "name": "[parameters('subnetName')]",
            "properties": {
              "addressPrefix": "[parameters('subnetPrefix')]",
              "defaultoutboundaccess": false
            }
          }
        ]
      }
    }
  ]
}

Limitations des sous-réseaux privés

• Pour activer ou mettre à jour des systèmes d’exploitation de machines virtuelles, tels que Windows, une méthode de connectivité sortante explicite est requise.

• Dans les configurations utilisant des routes définies par l’utilisateur (UDR), les routes configurées avec un type de tronçon suivant Internet échouent dans un sous-réseau privé.

  • Un exemple courant est l’utilisation d’un UDR pour diriger le trafic vers une appliance virtuelle/pare-feu réseau en amont, avec des exceptions pour certaines étiquettes de service Azure afin de contourner l’inspection. Pour cela, configurez les routes vers ces étiquettes de service avec le type de tronçon Internet. Dans ce scénario, vous configurez les éléments suivants :

    • Une route par défaut pour la destination 0.0.0.0/0, avec une appliance virtuelle comme type de tronçon suivant, est généralement applicable.

    • Une ou plusieurs routes sont configurées pour les destinations Service Tag avec le type de tronçon suivant Internet, pour contourner l’appliance virtuelle réseau/le pare-feu. Sauf si une méthode de connectivité sortante explicite est également configurée pour la source de la connexion à ces destinations, les tentatives de connexion à ces destinations échouent, car l’accès sortant par défaut n’est pas disponible par défaut dans un sous-réseau privé.

  • Cette limitation ne s’applique pas à l’utilisation de points de terminaison de service, qui utilisent un autre type de saut suivant VirtualNetworkServiceEndpoint. Consultez les points de terminaison de service de réseau virtuel.

• Les machines virtuelles peuvent toujours accéder aux comptes de Stockage Azure de la même région dans un sous-réseau privé, sans méthode sortante explicite. Les groupes de sécurité réseau sont suggérés pour contrôler la connectivité de sortie.

• Les sous-réseaux privés ne s’appliquent pas aux sous-réseaux délégués ou managés utilisés pour héberger des services PaaS. Dans ces scénarios, la connectivité sortante est gérée par le service individuel.

Important

Lorsqu’un pool principal d’équilibreur de charge est configuré par adresse IP, il utilise l’accès sortant par défaut en raison d’un problème connu en cours. Pour sécuriser par défaut la configuration et les applications avec des besoins sortants exigeants, associez une passerelle NAT aux machines virtuelles du pool principal de votre équilibreur de charge pour sécuriser le trafic. Apprenez-en plus sur les problèmes existants connus.

Ajouter une méthode sortante explicite

• Associer une passerelle NAT au sous-réseau de votre machine virtuelle. Notez qu’il s’agit de la méthode recommandée pour la plupart des scénarios.
• Associer un équilibreur de charge standard pour lequel des règles de trafic sortant sont configurées.
• Associez une adresse IP publique standard à n’importe laquelle des interfaces réseau de la machine virtuelle.
• Ajoutez un pare-feu ou une appliance virtuelle réseau (NVA) à votre réseau virtuel et pointez le trafic vers celui-ci à l’aide d’un itinéraire défini par l’utilisateur (UDR).

Utiliser le mode d’orchestration flexible pour les paramètres de mise à l’échelle des machines virtuelles

• Les paramètres de mise à l’échelle flexibles sont sécurisés par défaut. Aucune instance créée via des ensembles d'échelle flexibles n'est associée à l'adresse IP d'accès sortant par défaut, donc une méthode sortante explicite est requise. Pour plus d’informations, veuillez vous référer au mode d’orchestration flexible pour les paramètres de mise à l’échelle des machines virtuelles

FAQ : Effacement de l’alerte IP sortante par défaut

Pourquoi une alerte s’affiche-t-elle pour indiquer que j’ai une adresse IP sortante par défaut sur ma machine virtuelle ?

Il existe un paramètre au niveau de la carte réseau (defaultOutboundConnectivityEnabled) qui indique si l’adresse IP sortante par défaut est allouée à une instance de machine virtuelle ou à un ensemble de machines virtuelles. Cet élément sert à générer une bannière du portail Azure pour le VM/Virtual Machine Scale Set comportant l’indicateur correspondant. Il existe également des recommandations Azure Advisor spécifiques avec ces informations pour vos abonnements. Si vous souhaitez afficher les machines virtuelles ou les groupes de machines virtuelles identiques auxquels une adresse IP sortante par défaut est affectée, procédez comme suit :

1. Tapez « Advisor » dans la barre de recherche dans le portail Azure, puis sélectionnez cette option quand il s’affiche.
2. Sélectionnez « Excellence opérationnelle »
3. Recherchez les recommandations « Ajouter une méthode sortante explicite pour désactiver le trafic sortant par défaut » et/ou « Ajouter une méthode sortante explicite pour désactiver le trafic sortant par défaut pour les jeux d'échelles de machines virtuelles » (notez qu’il s’agit de deux éléments différents)
4. Si l’un de ces éléments existe, sélectionnez le nom de la recommandation respective et vous verrez les cartes d'interface réseau (NIC) de toutes les machines virtuelles ou instances d'ensemble de machines virtuelles qui ont activé la sortie par défaut.

Comment effacer cette alerte ?

1. Une méthode explicite de sortie doit être appliquée pour le VM/Virtual Machine Scale Set comportant l’indicateur. Consultez la section ci-dessus pour voir d’autres options.
2. Le sous-réseau doit être rendu privé pour empêcher la création d’adresses IP sortantes par défaut.
3. Toutes les machines virtuelles applicables dans le sous-réseau avec l’indicateur doivent être arrêtées et libérées pour que les modifications soient reflétées dans le paramètre au niveau de la carte réseau et pour que l’indicateur soit effacé. (Notez que cela vaut aussi pour le cas inverse. Pour qu’une machine dispose d’une adresse IP sortante par défaut après avoir défini le paramètre au niveau du sous-réseau sur « false », un arrêt ou une libération de la machine virtuelle est requis.)

J’utilise déjà une méthode explicite de trafic sortant. Pourquoi cette alerte continue-t-elle de s’afficher ?

Dans certains cas, une adresse IP sortante par défaut est quand même affectée aux machines virtuelles d’un sous-réseau non privé, même lorsqu’une méthode sortante explicite (telle qu’une NAT Gateway ou un itinéraire UDR qui dirige le trafic vers une appliance virtuelle réseau/un pare-feu) est configurée. Cela ne signifie pas que les adresses IP sortantes par défaut sont utilisées pour la sortie, sauf si ces méthodes explicites sont supprimées. Pour supprimer entièrement les adresses IP sortantes par défaut (et supprimer l’alerte), le sous-réseau doit être rendu privé et les machines virtuelles doivent être arrêtées et libérées.

FAQ : Changement de comportement par défaut en sous-réseaux privés

Que signifie le fait de rendre les sous-réseaux privés par défaut et comment cela sera-t-il mis en œuvre ?

Avec la version de l’API publiée après le 31 mars 2026, la propriété defaultOutboundAccess pour les sous-réseaux dans les nouveaux réseaux virtuels sera définie sur « false » par défaut. Cette modification rend les sous-réseaux privés par défaut et empêche la génération d’adresses IP sortantes par défaut pour les machines virtuelles de ces sous-réseaux. Ce comportement s’applique à toutes les méthodes de configuration : modèles ARM, portail Azure, PowerShell et CLI. Les versions antérieures des modèles ARM (ou des outils tels que Terraform qui peuvent spécifier des versions antérieures) continueront à définir defaultOutboundAccess comme null, ce qui autorise implicitement l’accès sortant.

Que se passe-t-il pour mes machines virtuelles et réseaux virtuels existants ? Qu’en est-il des nouvelles machines virtuelles créées dans des réseaux virtuels existants ?

Aucune modification n’est apportée aux réseaux virtuels existants. Cela signifie que les machines virtuelles existantes et les machines virtuelles nouvellement créées dans ces réseaux virtuels continuent de générer des adresses IP sortantes par défaut, sauf si les sous-réseaux sont modifiés manuellement pour devenir privés.

Qu’en est-il des nouveaux déploiements de réseau virtuel ? Mon infrastructure a une dépendance sur les adresses IP sortantes par défaut et n’est pas prête à passer à des sous-réseaux privés pour l’instant.

Vous pouvez toujours configurer des sous-réseaux en tant que non privés à l’aide de n’importe quelle méthode prise en charge (modèles ARM, portail, CLI, PowerShell). Cela garantit la compatibilité des infrastructures qui s’appuient sur des adresses IP sortantes par défaut et qui ne sont pas encore prêtes à passer aux sous-réseaux privés.

Étapes suivantes

Pour plus d’informations sur les connexions sortantes dans Azure, consultez :

• SNAT (Source Network Address Translation) pour les connexions sortantes.

• Qu’est-ce qu’Azure NAT Gateway ?