Planifier et implémenter des itinéraires User-Defined (UDR)

Vous pouvez créer des itinéraires personnalisés ou définis par l’utilisateur (statiques) dans Azure pour remplacer les itinéraires système par défaut d’Azure ou ajouter d’autres itinéraires à la table de routage d’un sous-réseau. Dans Azure, vous créez une table de routage, puis associez la table de routage à 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 de routage définies par l’utilisateur que vous pouvez créer par abonnement Azure, consultez limites Azure. Lorsque vous créez une table de routage et que vous l’associez à un sous-réseau, les itinéraires de la table sont combinés avec les itinéraires par défaut du sous-réseau. S’il existe des affectations de routage en conflit, les itinéraires définis par l’utilisateur remplacent les itinéraires par défaut.

Vous pouvez spécifier les types de sauts suivants lors de la création d’un itinéraire défini par l’utilisateur :

• Appliance virtuelle : une appliance virtuelle est une machine virtuelle qui exécute généralement une application réseau, telle qu’un pare-feu. Pour en savoir plus sur les différentes appliances virtuelles réseau préconfigurées 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 de l’appliance virtuelle, vous spécifiez également une adresse IP de tronçon suivant. L’adresse IP peut être :

  • Adresse IP privée d’une interface réseau attachée à une machine virtuelle. Toute interface réseau attachée à une machine virtuelle qui transfère le trafic réseau vers une adresse autre que la sienne doit avoir l'option Azure Activer le transfert IP activée. Le paramètre désactive la vérification d’Azure de la source et de la destination d’une interface réseau. En savoir plus sur la façon d’activer le transfert IP pour une interface réseau. Bien que l’activation du transfert IP soit un paramètre Azure, vous devrez peut-être également activer le transfert IP dans le système d’exploitation de la machine virtuelle pour que l’appliance transfère le trafic entre les adresses IP privées affectées aux interfaces réseau Azure. Si l’appliance doit acheminer le trafic vers une adresse IP publique, elle doit soit proxyer le trafic, soit effectuer une traduction d’adresses réseau (NAT) à partir de l’adresse IP privée de la source vers sa propre adresse IP privée. Azure effectue ensuite une nat vers une adresse IP publique avant d’envoyer le trafic à Internet. Pour déterminer les paramètres requis dans la machine virtuelle, consultez la documentation de votre système d’exploitation ou de votre application réseau. Pour comprendre les connexions sortantes dans Azure, consultez Présentation des connexions sortantes.
    
  • 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 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. Si vous envisagez de créer un itinéraire défini par l’utilisateur qui contient le préfixe d’adresse 0.0.0.0/0, lisez d’abord le préfixe d’adresse 0.0.0.0/0.

• Passerelle de réseau virtuel : spécifiez quand vous souhaitez que le trafic destiné aux préfixes d’adresses spécifiques acheminés vers une passerelle de réseau virtuel. La passerelle de réseau virtuel doit être créée avec le type VPN. Vous ne pouvez pas spécifier une passerelle de réseau virtuel créée en tant que type ExpressRoute dans un itinéraire défini par l’utilisateur, car avec ExpressRoute, vous devez utiliser BGP pour les itinéraires personnalisés. Vous ne pouvez pas spécifier de passerelles de réseau virtuel si vous disposez de connexions VPN et ExpressRoute coexistant non plus. 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. Si vous envisagez de créer un itinéraire défini par l’utilisateur pour le préfixe d’adresse 0.0.0.0/0, lisez d’abord le préfixe d’adresse 0.0.0.0/0. Au lieu de configurer un itinéraire défini par l’utilisateur 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 vous avez activé BGP pour une passerelle de réseau virtuel VPN.
• Aucun : spécifiez quand vous souhaitez supprimer le trafic vers un préfixe d’adresse, plutôt que de transférer le trafic vers une destination. Si vous n’avez pas encore entièrement configuré une fonctionnalité, Azure peut définir l’option Aucun pour certains des itinéraires système facultatifs. Par exemple, si vous voyez Aucun répertorié comme adresse IP de tronçon suivant avec un type de tronçon suivant de passerelle de réseau virtuel ou d’appliance virtuelle, cela peut être dû au fait que 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'adresses réservées avec "None" comme type de saut suivant.
  
• Réseau virtuel : spécifiez l’option de réseau virtuel lorsque vous souhaitez remplacer le routage par défaut au sein d’un réseau virtuel.
  
• Internet : spécifiez l’option Internet lorsque vous souhaitez acheminer explicitement le trafic destiné à un préfixe d’adresse vers Internet, ou si vous souhaitez que le trafic destiné aux services Azure avec des adresses IP publiques conservées dans le réseau principal Azure. Pour obtenir un exemple de raison pour laquelle vous pouvez créer un itinéraire avec le type de tronçon de réseau virtuel, consultez Exemple de routage.
  

Vous ne pouvez pas spécifier l’appairage de réseaux virtuels ou VirtualNetworkServiceEndpoint comme type de tronçon suivant dans les itinéraires définis par l’utilisateur. Les itinéraires avec peering de réseaux virtuels ou les types de tronçons suivants VirtualNetworkServiceEndpoint sont créés par Azure uniquement, lorsque vous configurez un appairage de réseaux virtuels ou un point de terminaison de service.

Balises de service pour les itinéraires définis par l’utilisateur

Vous pouvez maintenant spécifier une balise de service comme préfixe d’adresse pour un itinéraire défini par l’utilisateur 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 donné. Microsoft gère les préfixes d’adresses englobés par la balise de service et met automatiquement à jour la balise de service à mesure que les adresses changent. Ainsi, réduire la complexité des mises à jour fréquentes des itinéraires définis par l’utilisateur et réduire le nombre d’itinéraires que vous devez créer. Vous pouvez actuellement créer 25 itinéraires ou moins avec des étiquettes de service dans chaque table de routage. Avec cette version, l’utilisation de balises de service dans les scénarios de routage pour les conteneurs est également prise en charge.

Correspondance exacte

Le système donne la préférence à l’itinéraire avec le préfixe explicite lorsqu’il existe une correspondance exacte entre un itinéraire avec un préfixe IP explicite et un itinéraire avec une balise de service. Lorsque plusieurs itinéraires avec des étiquettes de service ont des préfixes IP correspondants, les itinéraires sont évalués dans l’ordre suivant :

1. Balises régionales (par exemple, Storage.EastUS, AppService.AustraliaCentral)
   
2. Balises de niveau supérieur (par exemple, Stockage, AppService)
   
3. Balises régionales AzureCloud (par exemple, AzureCloud.canadacentral, AzureCloud.eastasia)
   
4. 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 IP stockage Azure vers une appliance virtuelle à l’aide de :

$param = @{ Name = 'StorageRoute' AddressPrefix = 'Storage' NextHopType = 'VirtualAppliance' NextHopIpAddress = '10.0.100.4' } New-AzRouteConfig @param

La même commande pour 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 suivant dans les outils Azure

Le nom affiché et référencé pour les types de tronçon suivant est différent entre le Portail Azure et les outils en ligne de commande, et le Resource Manager et les modèles de déploiement classiques. 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.

Agrandir le tableau

Type de saut suivant	Azure CLI et PowerShell (Resource Manager)	Azure Classic CLI et 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	Application virtuelle	Application virtuelle
Aucun	Aucun	Null (non disponible dans l’interface CLI classique en mode modèle de déploiement classique)
Appairage de réseaux virtuels	Appairage de réseaux virtuels	Sans objet
Point de terminaison de service de réseau virtuel	VirtualNetworkServiceEndpoint	Sans objet

Protocole BGP

Une passerelle réseau locale peut échanger des itinéraires avec une passerelle de réseau virtuel Azure en utilisant 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 Microsoft Edge. Vous ne pouvez pas créer d’UDR pour forcer le trafic vers la passerelle de réseau virtuel ExpressRoute si vous déployez une passerelle de réseau virtuel déployée en tant que type ExpressRoute. Vous pouvez utiliser des UDR pour forcer le trafic de l’itinéraire express vers, par exemple, une appliance virtuelle réseau.
• VPN : Si vous le souhaitez, vous pouvez utiliser BGP. Pour plus d’informations, consultez BGP avec des connexions VPN de site à site.

Lorsque vous échangez des itinéraires avec Azure en utilisant 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ée avec Passerelle de réseau virtuel comme source et type de tronçon suivant.

Vous pouvez désactiver la propagation d’itinéraires ExpressRoute et Passerelle VPN Azure sur un sous-réseau à l’aide d’une propriété sur une table de routage. Lorsque vous désactivez la propagation d’itinéraire, 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 aux itinéraires BGP. La connectivité avec les connexions VPN est obtenue à l’aide d’itinéraires personnalisés avec un type de tronçon suivant de Passerelle de réseau virtuel. Pour plus d’informations, consultez Désactiver la propagation de l’itinéraire de passerelle de réseau virtuel.

Comment Azure choisit un itinéraire

Lorsque le trafic sortant est envoyé depuis un sous-réseau, Azure sélectionne un itinéraire en fonction de 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 l’autre itinéraire spécifie le préfixe d’adresse 10.0.0.0/16.

Azure dirige le trafic destiné à 10.0.0.5 au 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 car 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 au 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 car le préfixe d’adresse 10.0.1.5 n’est pas inclus dans le préfixe d’adresse 10.0.0.0/24, ce qui rend l’itinéraire avec le préfixe d’adresse 10.0.0.0/16 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 :

1. Itinéraire défini par l’utilisateur
2. Itinéraire BGP
3. Itinéraire du système

Par exemple, une table de routage contient les itinéraires suivants :

Agrandir le tableau

Source	Préfixes d’adresse	Type de saut suivant
Par défaut	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 des autres itinéraires de la table de routage, Azure sélectionne l’itinéraire avec la source de l’utilisateur. Azure fait ce choix, car les UDR ont une priorité plus élevée que les itinéraires système par défaut.

Pour obtenir une table de routage complète avec des explications sur les 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 router le trafic destiné à une adresse IP qui ne se trouve pas dans le préfixe d’adresse d’un autre itinéraire 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 tout autre itinéraire vers Internet.

L’exception est que le trafic vers les adresses IP publiques des services Azure reste sur le réseau principal Azure et n’est pas routé 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’adresses de tout autre itinéraire de la table de routage est dirigé. La destination dépend de la spécification d’une appliance virtuelle réseau ou d’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 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 pour l’itinéraire avec le préfixe d’adresse 0.0.0.0/0 est Internet, le trafic du sous-réseau destiné aux adresses IP publiques des services Azure ne quitte jamais le réseau principal 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 une passerelle de réseau virtuel ou un type de tronçon suivant de l’appliance virtuelle, tout le 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 du 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. Après que le trafic ait traversé l’appareil, il atteint la ressource dans le réseau virtuel. Si l’itinéraire contient les valeurs suivantes pour le 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 en mesure de convertir et de transférer une adresse réseau, ou d’acheminer le trafic à travers un serveur proxy vers la ressource de destination dans le sous-réseau, et de retourner le trafic à Internet.

  • Passerelle de réseau virtuel : si la passerelle est une passerelle de réseau virtuel ExpressRoute, un appareil connecté à Internet local peut traduire et transférer l’adresse réseau, ou proxyr le trafic vers la ressource de destination dans le sous-réseau, via le peering privé 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 un itinéraire 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 DMZ entre Azure et votre centre de données local.

Exemple de routage

Pour illustrer les concepts de cet article, les sections suivantes décrivent :

• Un scénario, avec des exigences.
• Les itinéraires personnalisés nécessaires pour répondre aux exigences.
• La table de routage qui existe pour un sous-réseau, qui inclut les itinéraires par défaut et personnalisés nécessaires pour répondre aux exigences.

Spécifications

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

2. Activer un réseau local pour communiquer en toute sécurité avec les deux réseaux virtuels via un tunnel VPN sur Internet. Vous pouvez également utiliser une connexion ExpressRoute, mais cet exemple utilise une connexion VPN.

3. Pour un sous-réseau dans un réseau virtuel :

   • Routez tout le trafic sortant depuis le sous-réseau via une appliance virtuelle réseau pour l’inspection et la journalisation. Excluez le trafic vers le Stockage Azure et au sein du sous-réseau de ce routage.
   • 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.
   • Supprimez tout trafic sortant destiné à l’autre réseau virtuel.
   • Permettez au trafic sortant vers le Stockage Azure de circuler directement vers le stockage, sans le forcer à traverser une appliance virtuelle réseau.

4. Autorisez tout le trafic entre tous les autres sous-réseaux et réseaux virtuels.

Implémentation

Le diagramme suivant montre une implémentation par le biais du modèle de déploiement Resource Manager qui répond aux exigences précédentes.

Tables de route

Voici les tables de routage pour l’exemple de routage précédent.

Sous-réseau1

La table de routage pour Subnet1 dans le diagramme précédent contient les itinéraires suivants :

Agrandir le tableau

Identifiant	Source	État	Préfixes d’adresse	Type de saut suivant	Adresse IP du tronçon suivant	Nom de l’UDR
1	Par défaut	Non valide	10.0.0.0/16	Réseau virtuel
2	Utilisateur	Actif	10.0.0.0/16	Appliance virtuelle	10.0.100.4	Within-VNet1
3	Utilisateur	Actif	10.0.0.0/24	Réseau virtuel		Within-Subnet1
4	Par défaut	Non valide	10.1.0.0/16	Appairage de réseaux virtuels
5	Par défaut	Non valide	10.2.0.0/16	Appairage de réseaux virtuels
6	Utilisateur	Actif	10.1.0.0/16	Aucun		ToVNet2-1-Drop
7	Utilisateur	Actif	10.2.0.0/16	Aucun		ToVNet2-2-Drop
8	Par défaut	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	Par défaut	Actif	[X.X.X.X]	VirtualNetworkServiceEndpoint
11	Par défaut	Non valide	0.0.0.0/0	Internet
12	Utilisateur	Actif	0.0.0.0/0	Appliance virtuelle	10.0.100.4	Default-NVA

Voici une explication de chaque ID d’itinéraire :

• ID1 : Azure a automatiquement ajouté cette route pour tous les sous-réseaux dans Virtual-network-1 , car 10.0.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’itinéraire ID2, le trafic envoyé à une adresse comprise entre 10.0.0.1 et 10.0.255.254 est routé dans le réseau virtuel. Ce processus se produit, car le préfixe est supérieur à 0.0.0.0/0 et ne se trouve pas dans les préfixes d’adresses d’autres itinéraires.

  Azure a automatiquement changé l’état d’Active à Non valide, quand ID2, un UDR, a été ajouté. Il 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 cette route est toujours actif pour Subnet2, car la table de routage contenant l'UDR, ID2, n'est pas associée à Subnet2.

• ID2 : Azure a ajouté cette route lorsqu’un UDR pour le préfixe d’adresse 10.0.0.0/16 a été associé au sous-réseau Subnet1 dans le réseau virtuel Virtual-network-1 . L’UDR spécifie 10.0.100.4 comme adresse IP de l’appliance virtuelle, car l’adresse est l’adresse IP privée affectée à la machine virtuelle de l’appliance virtuelle. La table de routage dans laquelle cet itinéraire existe n’est pas associée à Subnet2. L’itinéraire n’apparaît donc pas dans la table de routage pour 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 réseau virtuel. Cet itinéraire existe pour répondre à l’exigence 3, qui consiste à forcer tout le trafic sortant via 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 routé 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.

  Cet itinéraire n’a pas été associé à Subnet2. L’itinéraire n’apparaît donc pas dans la table de routage pour Subnet2. Cet itinéraire remplace efficacement l’itinéraire ID2 pour le trafic au sein de Subnet1. Cet itinéraire existe pour répondre à l’exigence 3.

• ID4 : Azure a automatiquement ajouté les itinéraires dans les ID 4 et 5 pour tous les sous-réseaux au sein du réseau virtuel-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 d’itinéraire 6 et 7, 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 se produit, car le préfixe est supérieur à 0.0.0.0/0 et ne se trouve pas dans les préfixes d’adresses d’autres itinéraires.

  Lorsque vous avez ajouté les itinéraires dans les ID 6 et 7, Azure a automatiquement changé l’état d’Active à Non valide. Ce processus se produit parce qu’ils ont les mêmes préfixes que les itinéraires des ID 4 et 5, et les itinéraires définis par l’utilisateur remplacent les itinéraires par défaut. L’état des itinéraires dans les ID 4 et 5 est toujours actif pour Subnet2, car la table de routage dans laquelle les UDR dans les ID 6 et 7 n’est pas associée à Subnet2. Un appairage de réseaux virtuels a été créé pour répondre à l’exigence 1.

• ID5 : Même explication que l’ID4.

• ID6 : Azure a ajouté cette route et l’itinéraire dans l’ID7 lorsque les préfixes d’adresse 10.1.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-10.1.255.254 et 10.2.0.1-10.2.255.254, au lieu d’être acheminé vers le réseau virtuel appairé, car les UDR remplacent les itinéraires par défaut. Les itinéraires ne sont pas associés à Subnet2. Par conséquent, les itinéraires n’apparaissent pas dans la table de routage pour Subnet2. Les itinéraires remplacent les itinéraires ID4 et ID5 pour le trafic sortant de Subnet1. 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 l’ID6.

• ID8 : Azure a automatiquement ajouté cet itinéraire pour tous les sous-réseaux au sein du réseau virtuel-1 lorsqu’une passerelle de réseau virtuel de type VPN a été créée dans le 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 toute 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é cette route lorsqu’un UDR pour le préfixe d’adresse 10.10.0.0/16 a été ajouté à la table de routage associée au sous-réseau1. Cet itinéraire remplace ID8. L’itinéraire envoie tout le trafic destiné au réseau local vers une appliance virtuelle réseau à des fins d’inspection, plutôt que de router le trafic directement en local. Cet itinéraire a été créé pour répondre à l’exigence 3.

• ID10 : Azure a automatiquement ajouté cet itinéraire au sous-réseau lorsqu’un point de terminaison de service à un service Azure a été activé pour le sous-réseau. Azure achemine le trafic depuis le 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 dans Virtual-network-1 et 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 préfixe d’adresse plus long est routé en fonction des 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 d’Active à Non valide pour le sous-réseau 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 cette route est toujours actif pour tous les autres sous-réseaux au sein des deux réseaux virtuels, car l’itinéraire n’est associé à aucun autre sous-réseau au sein d’autres réseaux virtuels.

• ID12 : Azure a ajouté cette route 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 adresse IP de l’appliance virtuelle. Cet itinéraire n’est pas associé à Subnet2. L’itinéraire n’apparaît donc pas dans la table de routage pour Subnet2. Tout le trafic destiné à une 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 cette route a changé l’état de l’itinéraire par défaut pour le préfixe d’adresse 0.0.0.0/0 (ID11) de Actif à Non valide pour Subnet1 , car un UDR remplace une route par défaut. Cet itinéraire existe pour répondre à l’exigence 3.

Sous-réseau2

La table de routage pour Subnet2 dans le diagramme précédent contient les itinéraires suivants :

Agrandir le tableau

Source	État	Préfixes d’adresse	Type de saut suivant	Adresse IP du tronçon suivant
Par défaut	Actif	10.0.0.0/16	Réseau virtuel
Par défaut	Actif	10.1.0.0/16	Appairage de réseaux virtuels
Par défaut	Actif	10.2.0.0/16	Appairage de réseaux virtuels
Par défaut	Actif	10.10.0.0/16	Passerelle de réseau virtuel	[X.X.X.X]
Par défaut	Actif	0.0.0.0/0	Internet
Par défaut	Actif	10.0.0.0/8	Aucun
Par défaut	Actif	100.64.0.0/10	Aucun
Par défaut	Actif	192.168.0.0/16	Aucun

La table de routage pour Subnet2 contient tous les itinéraires par défaut créés par Azure et les itinéraires d’appairage de réseaux virtuels et de passerelle de réseau virtuel facultatifs. 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 des préfixes d’adresses 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/0 a été ajouté à Subnet1.