Routage du trafic de réseau virtuel
Dans cet article, découvrez comment Azure achemine le trafic entre les ressources Azure, sur site et Internet. Azure crée automatiquement une table de routage pour chaque sous-réseau au sein d’un réseau virtuel Azure et y ajoute les itinéraires par défaut du système. Pour plus d’informations sur les réseaux virtuels et les sous-réseaux, voir Présentation du réseau virtuel. Vous pouvez remplacer certains itinéraires système d’Azure par des itinéraires personnalisés et ajouter d’autres itinéraires personnalisés aux tables de routage. Azure achemine le trafic sortant à partir d’un sous-réseau selon les itinéraires disponibles dans la table de routage d’un sous-réseau.
Itinéraires système
Azure crée des itinéraires système automatiquement et assigne les itinéraires pour chaque sous-réseau dans un réseau virtuel. Vous ne pouvez pas créer ni supprimer d’itinéraires système, mais vous pouvez remplacer certains itinéraires système par des itinéraires personnalisés. Azure crée des itinéraires système par défaut pour chaque sous-réseau et ajoute d’autres itinéraires par défaut facultatifs à des sous-réseaux spécifiques, ou à chaque sous-réseau, quand vous utilisez des fonctionnalités Azure spécifiques.
Par défaut
Chaque itinéraire comporte un préfixe d’adresse et le type de tronçon suivant. Lorsque le trafic sortant d’un sous-réseau est envoyé à une adresse IP dans le préfixe d’adresse d’un itinéraire, l’itinéraire qui contient le préfixe est celui utilisé par Azure. En savoir plus sur la façon dont Azure choisit un itinéraire lorsque plusieurs itinéraires contiennent les mêmes préfixes ou des préfixes qui se chevauchent. Chaque fois qu’un réseau virtuel est créé, Azure crée automatiquement les itinéraires système par défaut suivants pour chaque sous-réseau au sein du réseau virtuel :
| Source | Préfixes d’adresse | Type de tronçon suivant |
|---|---|---|
| Default | Propre au réseau virtuel | Réseau virtuel |
| Default | 0.0.0.0/0 | Internet |
| Default | 10.0.0.0/8 | None |
| Par défaut | 172.16.0.0/12 | Aucun |
| Default | 192.168.0.0/16 | None |
| Default | 100.64.0.0/10 | None |
Les types de tronçon suivants répertoriés dans le tableau précédent représentent la façon dont Azure achemine le trafic à destination du préfixe d’adresse répertorié. Vous trouverez ci-dessous des explications pour les types de tronçon suivant :
Réseau virtuel : achemine le trafic entre les plages d’adresses au sein de l’espace d’adressage d’un réseau virtuel. Azure crée un itinéraire avec un préfixe d’adresse qui correspond à chaque plage d’adresses définie dans l’espace d’adressage d’un réseau virtuel. Si plusieurs plages d’adresses sont définies dans l’espace d’adressage de réseau virtuel, Azure crée un itinéraire individuel pour chaque plage d’adresses. Par défaut, Azure achemine le trafic entre les sous-réseaux. Il n’est pas nécessaire de définir des tables de routage ou des passerelles pour qu’Azure achemine le trafic entre les sous-réseaux. Azure ne crée pas de routes par défaut pour les plages d’adresses de sous-réseau. Chaque plage d’adresses de sous-réseau se trouve dans une plage d’adresses de l’espace d’adressage d’un réseau virtuel.
Internet : achemine le trafic spécifié par le préfixe d’adresse à Internet. L’itinéraire par défaut du système spécifie le préfixe d’adresse 0.0.0.0/0. Si vous ne remplacez pas les itinéraires par défaut d’Azure, Azure achemine le trafic pour n’importe quelle adresse non spécifiée par une plage d’adresses au sein d’un réseau virtuel vers Internet. Il existe une exception à ce routage. Si l’adresse de destination est celle d’un service Azure, Azure achemine le trafic directement vers le service sur le réseau principal Azure (plutôt que vers Internet). Le trafic entre les services Azure ne traverse pas le réseau Internet. Peu importe la région Azure où le réseau virtuel existe ou la région Azure dans laquelle une instance du service Azure est déployée. Vous pouvez remplacer l’itinéraire système par défaut d’Azure pour le préfixe d’adresse 0.0.0.0/0 par un itinéraire personnalisé.
Aucun : le trafic acheminé vers le type de tronçon suivant Aucun est supprimé, plutôt que d’être acheminé à l’extérieur du sous-réseau. Azure crée automatiquement des itinéraires par défaut pour les préfixes d’adresse suivants :
- 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16 : réservé à un usage privé dans le document RFC 1918.
- 100.64.0.0/10 : réservé dans RFC 6598.
Si vous assignez l’une des plages d’adresses précédentes au sein de l’espace d’adressage d’un réseau virtuel, Azure modifie automatiquement le type de tronçon suivant pour l’itinéraire de Aucun en Réseau virtuel. Si vous affectez une plage d’adresses à l’espace d’adressage d’un réseau virtuel qui comprend, mais n’est pas identique à, un des quatre préfixes d’adresse réservés, Azure supprime l’itinéraire pour le préfixe et ajoute un itinéraire pour le préfixe d’adresse que vous avez ajouté, avec Réseau virtuel en tant que type de tronçon suivant.
Itinéraires par défaut facultatifs
Azure ajoute d’autres routes système par défaut pour les différentes fonctionnalités d’Azure, mais uniquement celles que vous activez. En fonction de la fonctionnalité, Azure ajoute les itinéraires par défaut facultatifs à des sous-réseaux spécifiques ou à tous les sous-réseaux au sein d’un réseau virtuel. Le tableau suivant répertorie les autres itinéraires système et les types de tronçon suivant qu’Azure peut ajouter quand vous activez différentes fonctionnalités.
| Source | Préfixes d’adresse | Type de tronçon suivant | Sous-réseau au sein d’un réseau virtuel auquel l’itinéraire est ajouté |
|---|---|---|---|
| Default | Unique pour le réseau virtuel, par exemple : 10.1.0.0/16 | Appairage de réseaux virtuels | Tous |
| Passerelle de réseau virtuel | Préfixes publiés à partir du site via le protocole BGP (Border Gateway Protocol), ou configurés dans la passerelle de réseau local | Passerelle de réseau virtuel | Tous |
| Default | Multiple | VirtualNetworkServiceEndpoint |
Uniquement le sous-réseau pour lequel un point de terminaison de service est activé |
Appairage de réseaux virtuels : lorsque vous créez un appairage entre deux réseaux virtuels, le système ajoute un itinéraire pour chaque plage d’adresses dans l’espace d’adressage de chaque réseau virtuel impliqué dans l’appairage. En savoir plus sur le peering de réseaux virtuels.
Passerelle de réseau virtuel : un ou plusieurs itinéraires avec passerelle de réseau virtuel répertorié comme le type de tronçon suivant sont ajoutés lorsqu’une passerelle de réseau virtuel est ajoutée à un réseau virtuel. La source est également la passerelle de réseau virtuel, car la passerelle ajoute les itinéraires au sous-réseau. Si votre passerelle de réseau local échange des itinéraires BGP avec une passerelle de réseau virtuel, le système ajoute un itinéraire pour chaque itinéraire. Ces itinéraires sont propagés à partir de la passerelle réseau locale. Nous recommandons de résumer les itinéraires locaux vers les plages d’adresses les plus vastes possible, pour propager le plus petit nombre possible d’itinéraires vers une passerelle de réseau virtuel Azure. Le nombre d’itinéraires que vous pouvez propager vers une passerelle de réseau virtuel Azure est limité. Pour plus d'informations, consultez Limites Azure.
VirtualNetworkServiceEndpoint: les adresses IP publiques de certains services sont ajoutées à la table de routage par Azure lorsque vous activez un point de terminaison de service pour le service. Les points de terminaison de service sont activés pour des sous-réseaux individuels d’un réseau virtuel, de sorte que l’itinéraire est ajouté uniquement à la table de routage d’un sous-réseau pour lequel un point de terminaison de service est activé. Les adresses IP publiques des services Azure changent régulièrement. Azure gère automatiquement les adresses dans la table de routage en cas de changement d’adresses. En savoir plus sur les points de terminaison de service de réseau virtuel et les services pour lesquels vous pouvez créer des points de terminaison de service.Remarque
L’appairage de réseaux virtuels et les types de tronçon suivant
VirtualNetworkServiceEndpointsont ajoutés uniquement aux tables de routage des sous-réseaux au sein de réseaux virtuels créés par le biais du modèle de déploiement Azure Resource Manager. Les types de tronçon suivants ne sont pas ajoutés aux tables de routage qui sont associées à des sous-réseaux de réseau virtuel créés par le biais du modèle de déploiement classique. En savoir plus sur les modèles de déploiement Azure.
Itinéraires personnalisés
Vous pouvez créer des itinéraires personnalisés en créant des itinéraires définis par l’utilisateur (UDR) ou en échangeant les itinéraires BGP entre votre passerelle de réseau local et une passerelle de réseau virtuel Azure.
Défini par l’utilisateur
Pour personnaliser vos itinéraires de trafic, vous ne devez pas modifier les itinéraires par défaut. Vous devez créer des itinéraires personnalisés ou définis par l’utilisateur (statiques), qui remplacent les itinéraires système par défaut d’Azure. Dans Azure, vous créez une table de routage, puis vous l’associez à zéro ou plusieurs sous-réseaux de réseau virtuel. Chaque sous-réseau peut avoir zéro ou une table de routage associée. Pour en savoir plus sur le nombre maximal d’itinéraires que vous pouvez ajouter à une table de routage et le nombre maximal de tables UDR que vous pouvez créer par abonnement Azure, consultez Limites Azure.
Par défaut, une table de routage peut contenir jusqu’à 400 UDR. Avec la configuration de routage d’Azure Virtual Network Manager, vous pouvez augmenter ce nombre jusqu’à 1 000 UDR par table de routage. Cette augmentation de limite permet de prendre charge des configurations de routage plus avancées. Il s’agit, par exemple, des cas de direction du trafic à partir de centres de données locaux via un pare-feu vers chaque réseau virtuel spoke dans une topologie hub-and-spoke lorsque vous avez un plus grand nombre de réseaux virtuels spoke.
Quand vous créez une table de routage et que vous l’associez à un sous-réseau, les routes de la table sont combinées aux routes par défaut du sous-réseau. En cas de conflit d’affectations d’itinéraires, les UDR remplacent les itinéraires par défaut.
Vous pouvez spécifier les types de tronçon suivant ci-dessous lors de la création d’un UDR :
Appliance virtuelle : une appliance virtuelle réseau est une machine virtuelle qui exécute une application réseau telle qu’un pare-feu. Pour en savoir plus sur les différentes appliances virtuelles préconfigurées du réseau que vous pouvez déployer dans un réseau virtuel, consultez la Place de marché Azure. Lorsque vous créez un itinéraire avec le type de tronçon appliance virtuelle, vous spécifiez également les adresses IP de tronçon suivant. L’adresse IP peut être :
L’adresse IP privée d’une interface réseau attachée à une machine virtuelle. L’optionActiver le transfert IP doit être activée pour toute interface réseau attachée à une machine virtuelle qui transfère le trafic réseau vers une adresse autre que celle qui lui appartient. Le paramètre désactive la vérification, par Azure, de la source et de destination pour une interface réseau. En savoir plus sur la façon d’activer le transfert IP pour une interface réseau. Activer le transfert IP est un paramètre Azure.
Il peut être nécessaire d’activer le transfert IP au sein du système d’exploitation de la machine virtuelle pour que l’appliance transfère le trafic entre les adresses IP privées affectées à des interfaces réseau Azure. Si l’appliance doit acheminer le trafic vers une adresse IP publique, elle doit acheminer le trafic via proxy ou effectuer une traduction d’adresses réseau (NAT) de l’adresse IP privée de la source vers sa propre adresse IP privée. Azure effectue ensuite une opération NAT vers une adresse IP publique avant d’envoyer le trafic vers Internet. Pour déterminer les paramètres requis pour la machine virtuelle, consultez la documentation de votre système d’exploitation ou application réseau. Pour comprendre les connexions sortantes dans Azure, consultez Comprendre les connexions sortantes dans Azure.
Notes
Déployer une appliance virtuelle dans un sous-réseau différent de celui des ressources qui passent par l’appliance virtuelle. Le déploiement de l’appliance virtuelle dans le même sous-réseau suivi de l’application d’une table de routage au sous-réseau qui achemine le trafic via l’appliance virtuelle peut entraîner des boucles de routage, où le trafic ne quitte jamais le sous-réseau.
Une adresse IP privée de tronçon suivant doit disposer d’une connectivité directe sans avoir besoin d’exécuter le routage via une passerelle Azure ExpressRoute ou via Azure Virtual WAN. La définition du tronçon suivant sur une adresse IP sans connectivité directe entraîne une configuration d’UDR non valide.
L’adresse IP privée d’un équilibreur de charge interne Azure. Un équilibreur de charge est souvent utilisé dans le cadre d’une stratégie de haute disponibilité pour les appliances virtuelles du réseau.
Vous pouvez définir un itinéraire avec 0.0.0.0/0 comme préfixe d’adresse et un type de tronçon suivant d’appliance virtuelle. Cette configuration permet à l’appliance d’inspecter le trafic et de déterminer s’il faut transférer ou supprimer le trafic. Pour créer un UDR contenant le préfixe d’adresse 0.0.0.0/0, lisez d’abord la rubrique Préfixe d’adresse 0.0.0.0/0.
Passerelle de réseau virtuel : indiquez quand vous souhaitez que le trafic destiné à des préfixes d’adresse spécifiques soit routé vers une passerelle de réseau virtuel. Vous devez créer la passerelle de réseau virtuel avec le type VPN. Vous ne pouvez pas définir une passerelle de réseau virtuel créée avec le type ExpressRoute sur un UDR, car ExpressRoute exige d’utiliser BGP pour les itinéraires personnalisés. Vous ne pouvez pas spécifier de passerelles de réseau virtuel (VPN) si vous avez des connexions VPN et ExpressRoute coexistantes. Vous pouvez définir un itinéraire qui dirige le trafic destiné au préfixe d’adresse 0.0.0.0/0 vers une passerelle de réseau virtuel basée sur un itinéraire.
Dans votre environnement local, vous pouvez avoir un dispositif qui inspecte le trafic et détermine s’il faut le transférer ou le supprimer. Pour créer un UDR pour le préfixe d’adresse 0.0.0.0/0, lisez d’abord la rubrique Préfixe d’adresse 0.0.0.0/0. Au lieu de configurer un UDR pour le préfixe d’adresse 0.0.0.0/0, vous pouvez publier un itinéraire avec le préfixe 0.0.0.0/0 via BGP si BGP pour une passerelle de réseau virtuel VPN est activé.
Aucun : indiquez quand vous souhaitez supprimer le trafic vers un préfixe d’adresse, plutôt que de le transférer vers une destination. Azure peut indiquer Aucun pour certains itinéraires système facultatifs si une fonctionnalité n’est pas configurée. Par exemple, si Adresse IP du tronçon suivant indique Aucun et que le Type de tronçon suivant est défini sur Passerelle de réseau virtuel ou Appliance virtuelle, l’appareil n’est pas en cours d’exécution ou n’est pas entièrement configuré. Azure crée des itinéraires système par défaut pour les préfixes d’adresse réservés avec Aucun en tant que type de tronçon suivant.
Réseau virtuel : spécifiez l’option Réseau virtuel quand vous souhaitez remplacer le routage par défaut dans un réseau virtuel. Pour obtenir un exemple des raisons pour lesquelles il convient de créer un itinéraire avec le type de tronçon suivant Réseau virtuel, consultez Exemple de routage.
Internet : choisissez l’option Internet pour acheminer explicitement le trafic destiné à un préfixe d’adresse vers Internet. Vous pouvez également l’utiliser pour conserver le trafic destiné aux services Azure avec des adresses IP publiques dans le réseau principal Azure.
Vous ne pouvez pas spécifier l’appairage de réseaux virtuels ni VirtualNetworkServiceEndpoint comme type de tronçon suivant dans les UDR. Azure crée des itinéraires avec un appairage de réseaux virtuels ou les types de tronçon suivant VirtualNetworkServiceEndpoint uniquement lorsque vous configurez un appairage de réseaux virtuels ou un point de terminaison de service.
Étiquettes de service pour les routes définies par l’utilisateur
Vous pouvez désormais spécifier une étiquette de service comme préfixe d’adresse d’un UDR au lieu d’une plage d’adresses IP explicite. Une étiquette de service représente un groupe de préfixes d’adresses IP d’un service Azure spécifique. Microsoft gère les préfixes d’adresse englobés par la balise de service et met à jour automatiquement la balise de service quand les adresses changent. Cela permet de simplifier les mises à jour fréquentes des UDR et de réduire le nombre d’itinéraires que vous devez créer. Actuellement, vous pouvez créer jusqu’à 25 itinéraires avec des étiquettes de service dans chaque table de routage. Avec cette version, l’utilisation des étiquettes de service dans les scénarios de routage pour les conteneurs est également prise en charge.
Correspondance exacte
Le système privilégie l’itinéraire avec le préfixe explicite lorsqu’il existe une correspondance de préfixe exacte entre un itinéraire avec un préfixe IP explicite et un itinéraire avec une étiquette de service. Lorsque plusieurs itinéraires avec des étiquettes de service ont des préfixes d’adresse IP qui correspondent, les itinéraires sont évalués dans l’ordre suivant :
Balises régionales (par exemple,
Storage.EastUSouAppService.AustraliaCentral)Balises de niveau supérieur (par exemple,
StorageouAppService)Balises régionales
AzureCloud(par exemple,AzureCloud.canadacentralouAzureCloud.eastasia)Balise
AzureCloud
Pour utiliser cette fonctionnalité, spécifiez un nom d’étiquette de service pour le paramètre de préfixe d’adresse dans les commandes de table de routage. Par exemple, dans PowerShell, vous pouvez créer un itinéraire pour diriger le trafic envoyé vers un préfixe d’adresse IP de Stockage Azure vers une appliance virtuelle en utilisant la commande suivante :
$param = @{
Name = 'StorageRoute'
AddressPrefix = 'Storage'
NextHopType = 'VirtualAppliance'
NextHopIpAddress = '10.0.100.4'
}
New-AzRouteConfig @param
La commande correspondante pour l’interface Azure CLI est la suivante :
az network route-table route create \
--resource-group MyResourceGroup \
--route-table-name MyRouteTable \
--name StorageRoute \
--address-prefix Storage \
--next-hop-type VirtualAppliance \
--next-hop-ip-address 10.0.100.4
Types de tronçon suivants dans les outils Azure
Le nom affiché et référencé pour les types de tronçon suivant diffère entre le portail Azure et les outils de la ligne de commande, et entre Resource Manager et les modèles de déploiement classique. Le tableau suivant répertorie les noms utilisés pour faire référence à chaque type de tronçon suivant avec les différents outils et modèles de déploiement.
| Type de tronçon suivant | Azure CLI et PowerShell (Gestionnaire des ressources) | Azure CLI classique and PowerShell (classique) |
|---|---|---|
| Passerelle de réseau virtuel | VirtualNetworkGateway |
VPNGateway |
| Réseau virtuel | VNetLocal |
VNETLocal (non disponible dans l’interface CLI classique en mode Modèle de déploiement classique) |
| Internet | Internet | Internet (non disponible dans l’interface CLI classique en mode Modèle de déploiement classique) |
| Appliance virtuelle | VirtualAppliance |
VirtualAppliance |
| Aucun(e) | None | Nul (non disponible dans l’interface CLI classique en mode Modèle de déploiement classique) |
| Peering de réseau virtuel | Peering de réseau virtuel | Non applicable |
| Point de terminaison de service de réseau virtuel | VirtualNetworkServiceEndpoint |
Non applicable |
Protocole de passerelle frontière
Une passerelle de réseau local peut échanger les itinéraires avec une passerelle de réseau virtuel Azure via le protocole BGP. L’utilisation du protocole BGP avec une passerelle de réseau virtuel Azure dépend du type que vous avez sélectionné lorsque vous avez créé la passerelle :
- ExpressRoute : vous devez utiliser le protocole BGP pour publier les itinéraires locaux vers le routeur de périphérie Microsoft. Vous ne pouvez pas créer d’UDR pour forcer le routage du trafic vers la passerelle de réseau virtuel ExpressRoute si vous déployez une passerelle de réseau virtuel avec le type ExpressRoute. Vous pouvez utiliser les UDR pour forcer le routage du trafic provenant d’ExpressRoute vers, par exemple, une appliance virtuelle du réseau.
- VPN : sinon, vous pouvez utiliser le protocole BGP. Pour plus d’informations, consultez BGP avec les connexions VPN de site à site.
Lorsque vous échangez des itinéraires avec Azure via le protocole BGP, un itinéraire distinct est ajouté à la table de routage de tous les sous-réseaux d’un réseau virtuel pour chaque préfixe publié. L’itinéraire est ajouté avec Passerelle de réseau virtuel comme source et type de tronçon suivant.
Vous pouvez désactiver la propagation d’itinéraire d’une passerelle VPN ExpressRoute et Azure sur un sous-réseau avec une propriété dans une table de routage. Lorsque vous désactivez la propagation d’itinéraires, le système n’ajoute pas d’itinéraires à la table de routage de tous les sous-réseaux avec la propagation d’itinéraire de passerelle de réseau virtuel désactivée. Ce processus s’applique aux itinéraires statiques et BGP. La connectivité avec les connexions VPN s’obtient à l’aide d’itinéraires personnalisés avec un tronçon suivant de type Passerelle de réseau virtuel. Pour plus d’informations, consultez Désactiver la propagation d’itinéraire d’une passerelle de réseau virtuel.
Remarque
La propagation d’itinéraire ne doit pas être désactivée sur GatewaySubnet. La passerelle ne fonctionne pas si ce paramètre est désactivé.
Comment Azure choisit un itinéraire
Lorsque le trafic sortant est envoyé à partir d’un sous-réseau, Azure choisit un itinéraire d’après l’adresse IP de destination, à l’aide de l’algorithme de correspondance de préfixe le plus long. Par exemple, une table de routage contient deux itinéraires. Un itinéraire spécifie le préfixe d’adresse 10.0.0.0/24 et un autre spécifie le préfixe d’adresse 10.0.0.0/16.
Azure dirige le trafic destiné à 10.0.0.5 vers le type de tronçon suivant spécifié dans l’itinéraire avec le préfixe d’adresse 10.0.0.0/24. Ce processus se produit parce que 10.0.0.0/24 est un préfixe plus long que 10.0.0.0/16, même si 10.0.0.5 se trouve dans les deux préfixes d’adresse.
Azure dirige le trafic destiné à 10.0.1.5 vers le type de tronçon suivant spécifié dans l’itinéraire avec le préfixe d’adresse 10.0.0.0/16. Ce processus se produit parce que 10.0.1.5 n’est pas inclus dans le préfixe d’adresse 10.0.0.0/24. De ce fait, l’itinéraire avec le préfixe d’adresse 10.0.0.0/16 est le préfixe correspondant le plus long.
Si plusieurs itinéraires contiennent le même préfixe d’adresse, Azure choisit le type d’itinéraire en se basant sur l’ordre de priorité suivant :
Itinéraire défini par l’utilisateur
Itinéraire BGP
Itinéraire du système
Remarque
Les itinéraires système pour le trafic lié au réseau virtuel, aux appairages de réseaux virtuels ou aux points de terminaison de service de réseau virtuel sont les itinéraires sélectionnés par défaut. Cependant, les itinéraires BGP sont plus spécifiques. Les itinéraires qui utilisent un point de terminaison de service de réseau virtuel comme type de tronçon suivant ne peuvent pas être remplacés, même avec une table de routage.
Par exemple, une table de routage contient les itinéraires suivants :
| Source | Préfixes d’adresse | Type de tronçon suivant |
|---|---|---|
| Default | 0.0.0.0/0 | Internet |
| Utilisateur | 0.0.0.0/0 | Passerelle de réseau virtuel |
Lorsque le trafic est destiné à une adresse IP en dehors des préfixes d’adresses de tous les itinéraires de la table de routage, Azure choisit l’itinéraire avec la source Utilisateur. Azure fonctionne ainsi, car les UDR ont une priorité plus élevée que les itinéraires système par défaut.
Pour une table de routage complète avec des explications des itinéraires de la table, consultez Exemple de routage.
Préfixe d’adresse 0.0.0.0/0
Un itinéraire avec le préfixe d’adresse 0.0.0.0/0 fournit des instructions à Azure. Azure utilise ces instructions pour acheminer le trafic destiné à une adresse IP qui n’est pas dans le préfixe d’adresse de n’importe quel autre itinéraire figurant dans la table de routage d’un sous-réseau. Lors de la création d’un sous-réseau, Azure crée un itinéraire par défaut vers le préfixe d’adresse 0.0.0.0/0, avec Internet comme type de tronçon suivant. Si vous ne remplacez pas cet itinéraire, Azure achemine tout le trafic destiné à des adresses IP non incluses dans le préfixe d’adresse de n’importe quel autre itinéraire vers Internet.
L’exception réside dans le trafic destiné aux adresses IP publiques des services Azure, qui reste sur le réseau principal Azure et n’est pas acheminé vers Internet. Lorsque vous remplacez cet itinéraire par un itinéraire personnalisé, le trafic destiné aux adresses qui ne se trouvent pas dans les préfixes d’adresse d’un autre itinéraire dans la table de routage est dirigé. La destination varie selon que vous spécifiez une appliance virtuelle réseau ou une passerelle de réseau virtuel dans l’itinéraire personnalisé.
Lorsque vous remplacez le préfixe d’adresse 0.0.0.0/0, le trafic sortant du sous-réseau transite par la passerelle de réseau virtuel ou l’appliance virtuelle. Les modifications suivantes se produisent également avec le routage par défaut d’Azure :
Azure envoie tout le trafic vers le type de tronçon suivant spécifié dans l’itinéraire y compris le trafic destiné à des adresses IP publiques de services Azure.
Lorsque le type de tronçon suivant de l’itinéraire avec le préfixe d’adresse 0.0.0.0/0 est Internet, le trafic sortant du sous-réseau et destiné aux adresses IP publiques de services Azure ne quitte jamais le réseau principal d’Azure, quelle que soit la région Azure dans laquelle le réseau virtuel ou la ressource de service Azure existe.
Lorsque vous créez un itinéraire UDR ou BGP avec le type de tronçon suivant Passerelle de réseau virtuel ou Appliance virtuelle, l’ensemble du trafic est envoyé au type de tronçon suivant spécifié dans l’itinéraire. Cela inclut le trafic envoyé aux adresses IP publiques des services Azure pour lesquels vous n’avez pas activé les points de terminaison de service.
Lorsque vous activez un point de terminaison de service pour un service, Azure crée un itinéraire avec des préfixes d’adresse pour le service. Le trafic vers le service n’est pas acheminé vers le type de tronçon suivant dans un itinéraire avec le préfixe d’adresse 0.0.0.0/0. Les préfixes d’adresse pour le service sont plus longs que 0.0.0.0/0.
Vous ne pouvez plus accéder directement aux ressources du sous-réseau depuis Internet. Vous pouvez accéder indirectement aux ressources du sous-réseau depuis Internet. L’appareil spécifié par le type de tronçon suivant pour un itinéraire avec le préfixe d’adresse 0.0.0.0/0 doit traiter le trafic entrant. Une fois que le trafic traverse l’appareil, le trafic atteint la ressource dans le réseau virtuel. Si l’itinéraire contient les valeurs suivantes comme type de tronçon suivant :
Appliance virtuelle : L’appliance doit :
- être accessible depuis Internet.
- avoir une adresse IP publique affectée.
- ne pas avoir de règle de groupe de sécurité réseau associée qui empêche la communication avec l’appareil.
- ne pas refuser la communication.
- être capable de traduire et de transférer une adresse réseau, ou de rediriger via proxy le trafic vers la ressource de destination dans le sous-réseau, et de retourner le trafic vers Internet.
Passerelle de réseau virtuel : si la passerelle est une passerelle de réseau virtuel ExpressRoute, un appareil local connecté à Internet peut traduire et transférer les adresses du réseau ou rediriger via proxy le trafic vers la ressource de destination dans le sous-réseau avec l’appairage privé d’ExpressRoute.
Si votre réseau virtuel est connecté à une passerelle VPN Azure, n’associez pas de table de routage au sous-réseau de passerelle qui inclut une route avec la destination 0.0.0.0/0. Cela peut empêcher la passerelle de fonctionner correctement. Pour plus d’informations, consultez Pourquoi certains ports sont-ils ouverts sur ma passerelle VPN ?.
Pour plus d’informations sur l’implémentation lorsque vous utilisez des passerelles de réseau virtuel entre Internet et Azure, consultez Zone DMZ entre Azure et votre centre de données local.
Exemple de routage
Pour illustrer les concepts abordés dans cet article, les sections suivantes décrivent :
- Un scénario, avec la configuration requise
- Les itinéraires personnalisés nécessaires pour satisfaire aux exigences
- La table de routage qui existe pour un sous-réseau qui comprend les itinéraires par défaut et personnalisés nécessaires pour satisfaire aux exigences
Remarque
Cet exemple ne saurait constituer une recommandation ni une bonne pratique. Il vise uniquement à illustrer les concepts de cet article.
Spécifications
Mettre en œuvre deux réseaux virtuels dans la même région Azure et activer les ressources de communication entre les réseaux virtuels.
Activez un réseau local pour communiquer en toute sécurité avec les deux réseaux virtuels via un tunnel VPN sur Internet. Vous pouvez aussi utiliser une connexion ExpressRoute. Cependant, cet exemple utilise une connexion VPN.
Pour un sous-réseau dans un réseau virtuel :
- Routez tout le trafic sortant provenant du sous-réseau via une appliance virtuelle réseau pour l’inspection et la journalisation. Excluez de ce routage le trafic vers Stockage Azure et le trafic au sein du sous-réseau.
- N’inspectez pas le trafic entre les adresses IP privées au sein du sous-réseau. Autorisez le trafic à circuler directement entre toutes les ressources.
- Supprimer tout trafic sortant destiné à l’autre réseau virtuel.
- Autorisez le trafic sortant vers le stockage Azure à circuler directement vers le stockage, sans le forcer à traverser une appliance virtuelle du réseau.
Autoriser tout le trafic entre tous les autres sous-réseaux et réseaux virtuels.
Implémentation
Le diagramme suivant représente une implémentation basée sur le modèle de déploiement Resource Manager qui respecte les exigences précédentes.
Flèches indiquent le flux du trafic.
Tables de routage
Voici les tables de routage associées à l’exemple de routage précédent.
Sous-réseau1
Dans le diagramme précédent, la table de routage de Subnet1 contient les itinéraires suivants :
| id | Source | State | Préfixes d’adresse | Type de tronçon suivant | Adresse IP de tronçon suivant | Nom de l’UDR |
|---|---|---|---|---|---|---|
| 1 | Default | Non valide | 10.0.0.0/16 | Réseau virtuel | ||
| 2 | Utilisateur | Actif | 10.0.0.0/16 | Appliance virtuelle | 10.0.100.4 | Au sein de VNet1 |
| 3 | Utilisateur | Actif | 10.0.0.0/24 | Réseau virtuel | Dans le Sous-réseau1 | |
| 4 | Default | Non valide | 10.1.0.0/16 | Appairage de réseaux virtuels | ||
| 5 | Default | Non valide | 10.2.0.0/16 | Appairage de réseaux virtuels | ||
| 6 | Utilisateur | Actif | 10.1.0.0/16 | None | ToVNet2-1-Drop | |
| 7 | Utilisateur | Actif | 10.2.0.0/16 | None | ToVNet2-2-Drop | |
| 8 | Default | Non valide | 10.10.0.0/16 | Passerelle de réseau virtuel | [X.X.X.X] | |
| 9 | Utilisateur | Actif | 10.10.0.0/16 | Appliance virtuelle | 10.0.100.4 | To-On-Prem |
| 10 | Default | Actif | [X.X.X.X] | VirtualNetworkServiceEndpoint |
||
| 11 | Default | Non valide | 0.0.0.0/0 | Internet | ||
| 12 | Utilisateur | Actif | 0.0.0.0/0 | Appliance virtuelle | 10.0.100.4 | Default-NVA |
Vous trouverez ci-dessous une description de chaque identificateur d’itinéraire :
ID1 : Azure a automatiquement ajouté cet itinéraire pour tous les sous-réseaux de Virtual-network-1, car 10.0.0.0/16 est la seule plage d’adresses définie dans l’espace d’adressage du réseau virtuel. Si vous ne créez pas l’UDR dans l’ID2 de l’itinéraire, le trafic envoyé à une adresse comprise entre 10.0.0.1 et 10.0.255.254 est acheminé au sein du réseau virtuel. Ce processus survient lorsque le préfixe est plus long que 0.0.0.0/0 et qu’il n’entre pas dans les préfixes d’adresse des autres itinéraires.
Azure a automatiquement changé l’état Actif en Non valide lors de l’ajout d’ID2 (un UDR). Celui-ci a le même préfixe que l’itinéraire par défaut et les UDR remplacent les itinéraires par défaut. L’état de cet itinéraire est toujours Actif pour Subnet2, car la table de routage à laquelle appartient l’UDR (ID2) n’est pas associée au Subnet2.
ID2 : Azure a ajouté cet itinéraire quand un UDR pour le préfixe d’adresse 10.0.0.0/16 a été associée au sous réseau Subnet1 du réseau virtuel Virtual-network-1. L’UDR définit 10.0.100.4 comme adresse IP de l’appliance virtuelle, car il s’agit de l’adresse IP privée affectée à la machine virtuelle de l’appliance virtuelle. La table de routage à laquelle cet itinéraire appartient n’est pas associée à Subnet2. Ce dernier n’apparaît donc pas dans la table de routage de Subnet2.
Cet itinéraire remplace l’itinéraire par défaut pour le préfixe 10.0.0.0/16 (ID1), qui a automatiquement acheminé le trafic adressé à 10.0.0.1 et à 10.0.255.254 dans le réseau virtuel via le type de tronçon suivant de réseau virtuel. Cet itinéraire existe pour répondre à l’exigence 3, afin de forcer tout le trafic sortant à traverser une appliance virtuelle.
ID3 : Azure a ajouté cet itinéraire lorsqu’un UDR pour le préfixe d’adresse 10.0.0.0/24 a été associé au sous-réseau Subnet1. Le trafic destiné aux adresses comprises entre 10.0.0.1 et 10.0.0.254 reste dans le sous-réseau. Le trafic n’est pas acheminé vers l’appliance virtuelle spécifiée dans la règle précédente (ID2), car il a un préfixe plus long que l’itinéraire ID2.
Cette route n’a pas été associée à Subnet2 et n’apparaît donc pas dans la table de routage de Subnet2. Cet itinéraire substitue efficacement l’itinéraire ID2 pour le trafic au sein du Sous-réseau1. Cet itinéraire existe pour répondre à l’exigence 3.
ID4 : Azure a ajouté automatiquement les itinéraires dans les ID 4 et 5 pour tous les sous-réseaux de Virtual-network-1, lorsque le réseau virtuel a été appairé avec Virtual-network-2. Virtual-network-2 a deux plages d’adresses dans son espace d’adressage : 10.1.0.0/16 et 10.2.0.0/16. Azure a donc ajouté un itinéraire pour chaque plage. Si vous ne créez pas les UDR dans les ID 6 et 7 d’itinéraire, le trafic envoyé à une adresse comprise entre 10.1.0.1-10.1.255.254 et 10.2.0.1-10.2.255.254 est acheminé vers le réseau virtuel appairé. Ce processus survient lorsque le préfixe est plus long que 0.0.0.0/0 et qu’il n’entre pas dans les préfixes d’adresse des autres itinéraires.
Lorsque vous avez ajouté les itinéraires dans les ID 6 et 7, Azure a automatiquement changé l’état d’Actif à Non valide. Ce processus survient lorsqu’ils ont les mêmes préfixes que les itinéraires des ID 4 et 5, et que les UDR remplacent les itinéraires par défaut. L’état des itinéraires des ID 4 et 5 est toujours Actif pour Subnet2, car la table de routage à laquelle appartiennent les UDR dans les ID 6 et 7 n’est pas associée à Subnet2. Un peering de réseau virtuel a été créé pour répondre à l’exigence 1.
ID5 : Même explication que pour ID4.
ID6 : Azure a ajouté cet itinéraire et l’itinéraire d’ID7 lorsque les UDR pour les préfixes d’adresse 10.1.0.0/16 et 10.2.0.0/16 ont été associés au sous-réseau Subnet1. Azure supprime le trafic destiné aux adresses comprises entre 10.1.0.1 et 10.1.255.254, et entre 10.2.0.1 et 10.2.255.254 plutôt que de l’acheminer vers le réseau virtuel appairé, car les UDR remplacent les itinéraires par défaut. Les routes ne sont pas associées à Subnet2 et n’apparaissent donc pas dans la table de routage de Subnet2. Les itinéraires remplacent les itinéraires ID4 et ID5 pour le trafic sortant du Sous-réseau1. Les itinéraires ID6 et ID7 existent pour répondre à l’exigence 3 afin de supprimer le trafic destiné à l’autre réseau virtuel.
ID7 : Même explication que pour ID6.
ID8 : Azure a ajouté automatiquement cette route pour tous les sous-réseaux de Virtual-network-1 lorsqu’une passerelle de réseau virtuel de type VPN a été créée au sein du réseau virtuel. Azure a ajouté l’adresse IP publique de la passerelle de réseau virtuel à la table de routage. Le trafic envoyé vers n’importe quelle adresse entre 10.10.0.1 et 10.10.255.254 est acheminé vers la passerelle de réseau virtuel. Le préfixe est plus long que 0.0.0.0/0 et ne fait pas partie des préfixes d’adresse des autres itinéraires. Une passerelle de réseau virtuel a été créée pour répondre à l’exigence 2.
ID9 : Azure a ajouté cet itinéraire lorsque l’UDR pour le préfixe d’adresse 10.10.0.0/16 a été ajouté à la table de routage associée à Subnet1. Cet itinéraire remplace ID8. L’itinéraire envoie tout le trafic destiné au réseau local à une NVA pour inspection, plutôt que d’acheminer le trafic directement sur site. Cet itinéraire a été créé pour répondre à l’exigence 3.
ID10 : Azure a ajouté automatiquement cette route au sous-réseau lorsqu’un point de terminaison de service pour un service Azure a été activé pour le sous-réseau. Azure achemine le trafic à partir du sous-réseau vers une adresse IP publique du service, sur le réseau d’infrastructure Azure. Le préfixe est plus long que 0.0.0.0/0 et ne fait pas partie des préfixes d’adresse des autres itinéraires. Un point de terminaison de service a été créé pour répondre à l’exigence 3, afin de permettre au trafic destiné au stockage Azure de circuler directement vers le stockage Azure.
ID11: : Azure a automatiquement ajouté cette route à la table de routage de tous les sous-réseaux de Virtual-network-1 et de Virtual-network-2. Le préfixe d’adresse 0.0.0.0/0 est le préfixe le plus court. Tout le trafic envoyé à des adresses avec un plus long préfixe d’adresse est routé en fonction d’autres itinéraires.
Par défaut, Azure achemine tout le trafic destiné aux adresses autres que les adresses spécifiées dans l’un des autres itinéraires vers Internet. Azure a automatiquement changé l’état Actif en Non valide pour le Subnet1 lorsqu’un UDR pour le préfixe d’adresse 0.0.0.0/0 (ID12) a été associé au sous-réseau. L’état de cet itinéraire est toujours Actif pour tous les autres sous-réseaux dans les deux réseaux virtuels, car l’itinéraire n’est associé à aucun autre sous-réseau au sein de tout autre réseau virtuel.
ID12 : Azure a ajouté cet itinéraire lorsqu’un UDR pour le préfixe d’adresse 0.0.0.0/0 a été associé au sous-réseau Subnet1. L’UDR spécifie 10.0.100.4 comme l’adresse IP de l’appliance virtuelle. Cette route n’est pas associée à Subnet2 et n’apparaît donc pas dans la table de routage de Subnet2. Tout le trafic destiné à toute adresse qui n’est pas incluse dans les préfixes d’adresse de tout autre itinéraire est envoyé à l’appliance virtuelle.
L’ajout de cet itinéraire a changé l’état de l’itinéraire par défaut pour le préfixe d’adresse 0.0.0.0/0 (ID11) d’Actif en Non valide pour le Subnet1, car les UDR remplacent les itinéraires par défaut. Cet itinéraire existe pour répondre à l’exigence 3.
Sous-réseau2
Dans le diagramme précédent, la table de routage de Subnet2 contient les itinéraires suivants :
| Source | State | Préfixes d’adresse | Type de tronçon suivant | Adresse IP de tronçon suivant |
|---|---|---|---|---|
| Default | Actif | 10.0.0.0/16 | Réseau virtuel | |
| Default | Actif | 10.1.0.0/16 | Peering de réseau virtuel | |
| Default | Actif | 10.2.0.0/16 | Peering de réseau virtuel | |
| Default | Actif | 10.10.0.0/16 | Passerelle de réseau virtuel | [X.X.X.X] |
| Default | Actif | 0.0.0.0/0 | Internet | |
| Default | Actif | 10.0.0.0/8 | None | |
| Default | Actif | 100.64.0.0/10 | None | |
| Default | Actif | 192.168.0.0/16 | None |
La table de routage du Sous-réseau2 contient tous les itinéraires par défaut créés par Azure et les itinéraires facultatifs d’appairage de réseaux virtuels et de passerelle de réseau virtuel. Azure a ajouté les itinéraires facultatifs à tous les sous-réseaux du réseau virtuel lorsque la passerelle et le peering ont été ajoutés au réseau virtuel.
Azure a supprimé les itinéraires pour les préfixes d’adresse 10.0.0.0/8, 192.168.0.0/16 et 100.64.0.0/10 de la table de routage de Subnet1 lorsque l’UDR pour le préfixe d’adresse 0.0.0.0/0 a été ajouté à Subnet1.
Contenu connexe
- Créer une table d’UDR avec des itinéraires et une appliance virtuelle du réseau.
- Configurer BGP pour une passerelle VPN Azure.
- Utiliser le protocole BGP avec ExpressRoute.
- Afficher tous les itinéraires pour un sous-réseau. Une table d’UDR affiche uniquement les UDR, et non les itinéraires BGP par défaut pour un sous-réseau. L’affichage de l’ensemble des itinéraires reprend les itinéraires par défaut, les itinéraires BGP et les UDR pour le sous-réseau sur lequel se trouve une interface réseau.
- Déterminer le type de tronçon suivant entre une machine virtuelle et une adresse IP de destination. Vous pouvez utiliser la fonctionnalité de tronçon suivant d’Azure Network Watcher pour déterminer si le trafic a quitté un sous-réseau et s’il est en cours de routage vers la destination escomptée.