Comment configurer l’intention de routage et les stratégies de routage d’un hub Virtual Wan

Article
2025-03-26

L'intention de routage hub Virtual WAN vous permet de configurer des stratégies de routage simples et déclaratives pour envoyer du trafic vers des solutions de sécurité intégrées comme le Pare-feu Azure, les appliances virtuelles réseau ou les solutions SaaS (logiciel en tant que service) déployés au sein du hub Virtual WAN.

Contexte

Les stratégies d’intention de routage et de routage vous permettent de configurer le hub Virtual WAN pour transférer le trafic Internet et privé (VPN point à site, VPN site à site, ExpressRoute, réseau virtuel et appliance virtuelle réseau) vers un Pare-feu Azure, un pare-feu de nouvelle génération (NGFW), une appliance virtuelle réseau (NVA) ou une solution de sécurité SaaS (software as a service) déployé dans le hub virtuel.

Il existe deux types de stratégies de routage : les stratégies de routage du trafic Internet et du trafic privé. Chaque hub Virtual WAN peut avoir au plus une stratégie de routage du trafic Internet et une stratégie de routage du trafic privé, chacune avec une seule ressource de tronçon suivant. Alors que le trafic privé comprend des préfixes d'adresses de branches et de réseau virtuel, les politiques de routage les considèrent comme une entité unique dans les concepts d'intention de routage.

Stratégie de routage du trafic Internet : quand une stratégie de routage du trafic Internet est configurée sur un hub Virtual WAN, toutes les connexions de branche (VPN utilisateur distant [VPN point à site], VPN site à site et ExpressRoute) et les connexions de réseau virtuel à ce hub Virtual WAN transfèrent le trafic Internet vers le Pare-feu Azure, le fournisseur de sécurité tiers, l’appliance virtuelle réseau ou la solution SaaS spécifié dans le cadre de la stratégie de routage.

En d’autres termes, quand la stratégie de routage du trafic Internet est configurée sur un hub Virtual WAN, Virtual WAN publie un itinéraire (0.0.0.0/0) par défaut sur l’ensemble des spokes, passerelles et appliances virtuelles réseau (déployées dans le hub ou le spoke).
Stratégie de routage du trafic privé : quand une stratégie de routage du trafic privé est configurée sur un hub Virtual WAN, tout le trafic de la branche et du réseau virtuel entrant et sortant dans le hub Virtual WAN, y compris le trafic entre hubs, est transféré vers la ressource de Pare-feu Azure, d’appliance virtuelle réseau ou de solution SaaS de tronçon suivant.

En d’autres termes, quand une stratégie de routage du trafic privé est configurée sur le hub Virtual WAN, tout le trafic de branche à branche, de branche à réseau virtuel, de réseau virtuel à branche et entre hubs est envoyé par le biais du Pare-feu Azure, d’une appliance virtuelle réseau ou d’une solution SaaS déployé dans le hub WAN virtuel.

Cas d’utilisation

La section suivante décrit deux scénarios courants qui permettent où des politiques de routage sont appliquées à des hubs Virtual WAN sécurisés.

Tous les hubs Virtual WAN sont sécurisés (déployés avec le Pare-feu Azure, une appliance réseau virtuelle ou une solution SaaS)

Dans ce scénario, tous les hubs Virtual WAN sont déployés avec un Pare-feu Azure, une appliance virtuelle réseau ou une solution SaaS dans chacun d'eux. Dans ce scénario, vous pouvez configurer une stratégie de routage du trafic Internet, une stratégie de routage du trafic privé ou les deux sur chaque hub Virtual WAN.

Considérez la configuration suivante, où les hubs 1 et 2 ont des stratégies de routage pour le trafic privé et Internet.

Configuration du Hub 1 :

Stratégie de trafic privé avec Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 1 de tronçon suivant
Stratégie de trafic Internet avec Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 1 de tronçon suivant

Configuration de Hub 2 :

Stratégie de trafic privé avec Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2 de tronçon suivant
Stratégie de trafic Internet avec Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2 de tronçon suivant

Voici les flux de trafic qui résultent d’une telle configuration.

Remarque

Le trafic Internet doit passer par la solution de sécurité locale du hub car la route par défaut (0.0.0.0/0) ne se propage pas d'un hub à l'autre.

Depuis	Vers	Réseaux virtuels Hub 1	Branches du Hub 1	Réseaux virtuels Hub 2	Branches Hub 2	Internet
Réseaux virtuels Hub 1	→	Pare-feu Azure ou appliance virtuelle réseau dans le hub 1	Pare-feu Azure ou appliance virtuelle réseau dans le hub 1	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans les hubs 1 et 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans les hubs 1 et 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 1
Branches Hub 1	→	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 1	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 1	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans les hubs 1 et 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans les hubs 1 et 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 1
Réseaux virtuels Hub 2	→	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans les hubs 1 et 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans les hubs 1 et 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2
Branches Hub 2	→	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans les hubs 1 et 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans les hubs 1 et 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2

Déploiement de hubs Virtual WAN à la fois sécurisés et ordinaires

Dans ce scénario, les hubs du WAN ne sont pas tous des hubs Virtual WAN sécurisés (hubs qui ont une solution de sécurité déployée dans ceux-ci).

Considérez la configuration suivante, où Hub 1 (normal) et Hub 2 (sécurisé) sont déployés dans un Virtual WAN. Hub 2 a des stratégies de routage pour le trafic privé et Internet.

Configuration du Hub 1 :

N/A (ne peut pas configurer les stratégies de routage si le hub n’est pas déployé avec le Pare-feu Azure, une appliance virtuelle réseau ou une solution SaaS)

Configuration de Hub 2 :

Stratégie de trafic privé avec Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2 de tronçon suivant.
Stratégie de trafic Internet avec Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2 de tronçon suivant.

Voici les flux de trafic qui résultent d’une telle configuration. Les branches et les réseaux virtuels connectés au hub 1 ne peuvent pas accéder à Internet via une solution de sécurité déployée dans le hub, car l'itinéraire par défaut (0.0.0.0/0) ne se propage pas à travers les hubs.

Depuis	Vers	Réseaux virtuels Hub 1	Branches du Hub 1	Réseaux virtuels Hub 2	Branches Hub 2	Internet
Réseaux virtuels Hub 1	→	Immédiat	Immédiat	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	-
Branches Hub 1	→	Immédiat	Immédiat	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	-
Réseaux virtuels Hub 2	→	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2
Branches Hub 2	→	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2	Pare-feu Azure, appliance virtuelle réseau ou solution SaaS dans le hub 2

Limitations connues

Le tableau suivant décrit la disponibilité de l’intention de routage dans différents environnements Azure.
- L’intention de routage n’est pas disponible dans Microsoft Azure gérée par 21 Vianet.
- Palo Alto Cloud NGFW est uniquement disponible dans Azure Public. Contactez Palo Alto Networks au sujet de la disponibilité de Cloud NGFW dans Azure Government et Microsoft Azure géré par Viacom.
- Les appliances virtuelles réseau ne sont pas disponibles dans toutes les régions Azure Government. Contactez votre partenaire NVA au sujet de la disponibilité dans Azure Government.

Environnement nuage	Pare-feu Azure	Appliance virtuelle réseau	Solutions SaaS
Azure Public	Oui	Oui	Oui
Azure Gouvernement	Oui	Limité	Non
Microsoft Azure géré par 21Vianet	Non	Non	Non

L’intention de routage simplifie le routage en gérant les associations de tables de routage et les propagations pour toutes les connexions (réseau virtuel, VPN site à site, VPN point à site et ExpressRoute). Les réseaux WAN virtuels avec des tables de routage personnalisées et des politiques personnalisées ne peuvent pas être utilisés avec les concepts d'intention de routage.
ExpressRoute chiffré (tunnels VPN de site à site qui fonctionnent sur des circuits ExpressRoute) est pris en charge dans les hubs avec intention de routage configurée, à condition que le pare-feu Azure soit configuré pour autoriser le trafic entre les points de terminaison du tunnel VPN (adresse IP privée de la passerelle VPN de site à site et adresse IP privée du périphérique VPN local). Pour plus d’informations sur les configurations requises, consultez ExpressRoute chiffré avec intention de routage.
Les cas d'utilisation de connectivité suivants ne sont pas pris en charge avec Routing Intent :
- Les itinéraires statiques du paramètre defaultRouteTable qui pointent vers une connexion réseau virtuel ne peuvent pas être utilisés conjointement avec l'intention de routage. Toutefois, vous pouvez utiliser la fonctionnalité d’homologation BGP.
- Les itinéraires statiques sur la connexion de réseau virtuel avec « propagation d’itinéraire statique » ne sont pas appliqués à la ressource de tronçon suivant spécifiée dans les stratégies de routage privé. La prise en charge de l’application d’itinéraires statiques sur les connexions de réseau virtuel à la stratégie de routage privé de tronçon suivant est sur la feuille de route.
- La possibilité de déployer à la fois une NVA de connectivité SD-WAN et une NVA de pare-feu ou une solution SaaS distincte dans le même hub réseau étendu virtuel (Virtual WAN) est actuellement dans la planification. Une fois l'intention de routage configurée avec soit la solution SaaS du prochain saut, soit le pare-feu NVA, la connectivité entre le SD-WAN NVA et Azure est impactée. Déployez plutôt l’appliance virtuelle réseau SD-WAN et la solution NVA de pare-feu ou SaaS dans différents hubs virtuels. Vous pouvez également déployer l’appliance virtuelle réseau SD-WAN dans un réseau virtuel de rayon connecté au hub et tirer parti de la fonctionnalité d’homologation BGP du hub virtuel.
- Les appliances virtuelles réseau (NVA) peuvent être spécifiées comme ressource de tronçon suivant pour l'intention de routage uniquement si elles sont des pare-feu de nouvelle génération ou des NVAs à double rôle combinant un pare-feu de nouvelle génération et SD-WAN. Actuellement, checkpoint, fortinet-ngfw, fortinet-ngfw-and-sdwan et cisco-tdv-vwan-nva sont les seuls appliances virtuelles réseau éligibles à être configurées pour être le tronçon suivant pour l’intention de routage. Si vous essayez de spécifier une autre appliance virtuelle réseau, la création d’une intention de routage échoue. Vous pouvez vérifier le type des appliances virtuelles réseau en accédant à votre hub virtuel -> Appliances virtuelles réseau, puis en examinant le champ Fournisseur. Palo Alto Networks Cloud NGFW est également pris en charge comme tronçon suivant pour l’intention de routage, mais est considéré comme un tronçon suivant de type Solution SaaS.
- Les utilisateurs d'intention de routage qui souhaitent connecter plusieurs circuits ExpressRoute à Virtual WAN et qui souhaitent envoyer du trafic entre eux via une solution de sécurité déployée dans le hub, peuvent activer l'ouverture d'un cas de support afin d'activer ce cas d'usage. Pour plus d'informations, reportez-vous à l'activation de la connectivité entre les circuits ExpressRoute.

Limites d’espace d’adressage du réseau virtuel

Remarque

Le nombre maximal d’espaces d’adressage de réseau virtuel que vous pouvez connecter à un seul hub Virtual WAN est réglable. Ouvrez un cas de support Azure pour demander une augmentation de la limite. Les limites s’appliquent au niveau du hub Virtual WAN. Si vous avez plusieurs hubs Virtual WAN qui nécessitent une augmentation de la limite, demandez une augmentation de la limite pour tous les hubs Virtual WAN dans votre déploiement Virtual WAN.

Pour les clients utilisant l’intention de routage, le nombre maximal d’espaces d’adressage sur tous les réseaux virtuels directement connectés à un seul hub Virtual WAN est de 400. Cette limite est appliquée individuellement à chaque hub Virtual WAN dans un déploiement Virtual WAN. Les espaces d’adressage de réseau virtuel connectés à des hubs à distance (autres hubs Virtual WAN dans le même Virtual WAN) ne sont pas comptabilisés dans cette limite.

Si le nombre d’espaces d’adressage de réseau virtuel directement connectés à un hub dépasse la limite, l’activation ou la mise à jour de l’intention de routage sur le hub virtuel échoue. Pour les hubs déjà configurés avec l’intention de routage où les espaces d’adressage de réseau virtuel dépassent la limite en raison d’une opération telle qu’une mise à jour de l’espace d’adressage du réseau virtuel, l’espace d’adressage nouvellement connecté peut ne pas être routable.

Demandez de manière proactive une augmentation de la limite si le nombre total d’espaces d’adressage sur tous les réseaux virtuels connectés localement dépasse 90 % de la limite documentée ou si vous disposez d’opérations de déploiement ou d’expansion de réseau planifiées qui augmenteront le nombre d’espaces d’adressage de réseau virtuel au-delà de la limite.

Le tableau suivant fournit des exemples de calculs d’espace d’adressage de réseau virtuel.

Hub virtuel	Nombre de réseaux virtuels	Espaces d'adresse par réseau virtuel	Nombre total d’espaces d’adressage de réseau virtuel connectés au hub virtuel	Action suggérée
Hub #1	200	1	200	Aucune action n’est requise, surveillez le nombre d’espaces d’adressage.
Hub #2	150	3	450	Demandez une augmentation de la limite pour utiliser l’intention de routage.
Hub #3	370	1	370	Demander une augmentation de la limite.

Vous pouvez utiliser le script PowerShell suivant pour estimer le nombre d’espaces d’adressage dans les réseaux virtuels connectés à un seul hub Virtual WAN. Exécutez ce script pour tous les hubs Virtual WAN dans votre Virtual WAN. Une métrique Azure Monitor vous permettant de suivre et de configurer des alertes sur les espaces d’adressage de réseau virtuel connectés est sur la feuille de route.

Veillez à modifier l’ID de la ressource du hub Virtual WAN dans le script pour qu’il corresponde à votre environnement. Si vous avez des connexions de réseau virtuel entre clients, assurez-vous que vous disposez des autorisations suffisantes pour lire l’objet de connexion du réseau virtuel Virtual WAN ainsi que la ressource de réseau virtuel connecté.

$hubVNETconnections = Get-AzVirtualHubVnetConnection -ParentResourceId "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualHubs/<virtual hub name>"
$addressSpaceCount = 0
  
foreach($connection in $hubVNETconnections) {
  try{
    $resourceURI = $connection.RemoteVirtualNetwork.Id
    $RG = ($resourceURI -split "/")[4]
    $name = ($resourceURI -split "/")[8]
    $VNET = Get-AzVirtualNetwork -Name $name -ResourceGroupName $RG -ErrorAction "Stop"
    $addressSpaceCount += $VNET.AddressSpace.AddressPrefixes.Count
  }
  catch{
    Write-Host "An error occurred while processing VNET connected to Virtual WAN hub with resource URI:  " -NoNewline
    Write-Host $resourceURI 
    Write-Host "Error Message: " -ForegroundColor Red
    Write-Host $_.Exception.Message -ForegroundColor Red 
  }
  finally{
  }
}
Write-Host "Total Address Spaces in VNETs connected to this Virtual WAN Hub: " -ForegroundColor Green -NoNewline
Write-Host $addressSpaceCount -ForegroundColor Green

Considérations

Les clients qui utilisent actuellement le Pare-feu Azure dans le hub Virtual WAN sans intention de routage peuvent activer l’intention de routage à l’aide d’Azure Firewall Manager, du portail de routage du hub Virtual WAN ou via d’autres outils de gestion Azure (PowerShell, CLI, API REST).

Avant d'activer l'intention de routage, tenez compte des points suivants :

L'intention de routage ne peut être configurée que sur des hubs qui n'ont ni tables de routage personnalisées ni itinéraires statiques dans le DefaultRouteTable avec une connexion réseau virtuelle de saut suivant. Pour plus d’informations, voir Conditions préalables.
Enregistrez une copie de vos passerelles, connexions et tables de routage avant d’activer l’intention de routage. Le système n'enregistre pas et n'applique pas automatiquement les configurations précédentes. Pour plus d'informations, consultez stratégie de retour en arrière.
L'intention de routage modifie les itinéraires statiques dans defaultRouteTable. En raison des optimisations du portail Azure, l’état de defaultRouteTable après la configuration de l’intention de routage peut être différent si vous configurez l’intention de routage à l’aide de REST, CLI ou PowerShell. Pour plus d'informations, consultez Itinéraires statiques.
L’activation de l’intention de routage affecte la publication des préfixes en local. Pour plus d’informations, consultez Publications de préfixes.
Vous pouvez ouvrir un cas de support pour activer la connectivité entre les circuits ExpressRoute via une appliance de pare-feu dans le hub. L'activation de ce modèle de connectivité entraîne la modification des préfixes annoncés aux circuits ExpressRoute. Pour plus d'informations, consultez À propos d'ExpressRoute.
L’intention de routage est le seul mécanisme dans Virtual WAN pour activer l’inspection du trafic inter-hub via des appliances de sécurité déployées dans le hub. L’inspection du trafic inter-hub nécessite également l’activation de l’intention de routage sur tous les hubs pour s’assurer que le trafic est routé de manière symétrique entre les appliances de sécurité déployées dans des hubs Virtual WAN.
L’intention de routage envoie le trafic local et de réseau virtuel à la ressource de tronçon suivant spécifiée dans la stratégie de routage. Virtual WAN programme la plateforme Azure sous-jacente pour acheminer votre trafic local et de réseau virtuel conformément à la stratégie de routage et ne traite pas le trafic via le routeur de hub virtuel. Étant donné que les paquets acheminés via l’intention de routage ne sont pas traités par le routeur, vous n’avez pas besoin d’allouer d’unités d’infrastructure de routage supplémentaires pour le transfert des paquets sur le plan de données dans les hubs configurés avec une intention de routage. Toutefois, vous devrez peut-être allouer des unités d’infrastructure de routage supplémentaires en fonction du nombre de machines virtuelles dans les réseaux virtuels connectés au hub Virtual WAN.
L’intention de routage vous permet de configurer différentes ressources de tronçon suivant pour les stratégies de routage privé et Internet. Par exemple, vous pouvez définir le tronçon suivant pour les stratégies de routage privé vers le Pare-feu Azure dans le hub et le tronçon suivant pour la stratégie de routage Internet vers une appliance virtuelle réseau ou une solution SaaS dans le hub. Étant donné que les solutions SaaS et les appliances virtuelles réseau de Pare-feu sont déployées dans le même sous-réseau dans le hub Virtual WAN, le déploiement de solutions SaaS avec une appliance virtuelle réseau de Pare-feu dans le même hub peut avoir un impact sur la scalabilité horizontale des solutions SaaS, car il existe moins d’adresses IP pour un scale-out horizontal. En outre, vous pouvez avoir au plus une solution SaaS déployée dans chaque hub Virtual WAN.

Prérequis

Pour activer l'intention et les politiques de routage, votre hub virtuel doit remplir les conditions préalables ci-dessous :

Aucune table de routage personnalisée n'est déployée avec le hub virtuel. Les seules tables de routage qui existent sont noneRouteTable et defaultRouteTable.
Vous ne pouvez pas avoir des itinéraires statiques avec une connexion de réseau virtuel de tronçon suivant. Vous pouvez avoir des itinéraires statiques dans la defaultRouteTable avec un Pare-feu Azure de tronçon suivant.

L'option permettant de configurer l'intention de routage est grisée pour les hubs qui ne répondent pas aux exigences ci-dessus.

L'utilisation de l'intention de routage (activer l'option inter-hub) dans Azure Firewall Manager présente une exigence supplémentaire :

Les itinéraires créés par Azure Firewall Manager suivent la convention d'affectation de noms private_traffic, internet_traffic ou all_traffic. Par conséquent, tous les itinéraires de defaultRouteTable doivent respecter cette convention.

Stratégie de retour en arrière

Remarque

Lorsque la configuration de l’intention de routage est complètement supprimée d'un hub, toutes les connexions au hub sont définies pour se propager à l’étiquette par défaut (qui s’applique à « tous » les paramètres defaultRouteTables dans le Virtual WAN). Par conséquent, si vous envisagez d'implémenter l'intention de routage dans Virtual WAN, vous devez enregistrer une copie de vos configurations existantes (passerelles, connexions, tables de routage) à appliquer si vous souhaitez revenir à la configuration d'origine. Le système ne restaure pas automatiquement votre configuration précédente.

L'intention de routage simplifie le routage et la configuration en gérant les associations d'itinéraires et les propagations de toutes les connexions dans un hub.

La table suivante décrit la table de routage associée et les tables de routage propagées de toutes les connexions une fois l'intention de routage configurée.

Configuration de l’intention de routage	Table de routage associée	Tables de routage propagées
Internet	defaultRouteTable	étiquette par défaut (defaultRouteTable de tous les hubs du Virtual WAN)
Privé	defaultRouteTable	noneRouteTable
Internet et privé	defaultRouteTable	noneRouteTable

Itinéraires statiques dans defaultRouteTable

La section suivante décrit comment l'intention de routage gère les itinéraires statiques dans defaultRouteTable lorsque l'intention de routage est activée sur un hub. Les modifications apportées par l'intention de routage à defaultRouteTable sont irréversibles.

Si vous supprimez l'intention de routage, vous devrez restaurer manuellement votre configuration précédente. Par conséquent, nous vous recommandons d'enregistrer une capture instantanée de votre configuration avant d'activer l'intention de routage.

Azure Firewall Manager et portail du hub Virtual WAN

Lorsque l'intention de routage est activée sur le hub, les itinéraires statiques correspondant aux politiques de routage configurées sont créés automatiquement dans defaultRouteTable. Ces itinéraires sont les suivants :

Nom des routes	Préfixes	Ressource de tronçon suivant
_policy_PrivateTraffic	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Pare-feu Azure
_policy_PublicTraffic	0.0.0.0/0	Pare-feu Azure

Remarque

Tous les itinéraires statiques du defaultRouteTable contenant des préfixes qui ne correspondent pas exactement à 0.0.0.0/0 ou aux super-réseaux conformes à la norme RFC1918 (10.0.0.0/8, 192.168.0.0/16 et 172.16.0.0/12) sont automatiquement consolidés en un seul itinéraire statique, nommée private_traffic. Les préfixes du defaultRouteTable qui correspondent aux super-réseaux conformes à la norme RFC1918 ou à 0.0.0.0/0 sont toujours automatiquement supprimés une fois l'intention de routage configurée, quel que soit le type de politique.

Par exemple, considérez le scénario où defaultRouteTable a les itinéraires suivants avant de configurer l'intention de routage :

Nom des routes	Préfixes	Ressource de tronçon suivant
trafic privé	192.168.0.0/16, 172.16.0.0/12, 40.0.0.0/24, 10.0.0.0/24	Pare-feu Azure
vers_internet	0.0.0.0/0	Pare-feu Azure
additional_private	10.0.0.0/8, 50.0.0.0/24	Pare-feu Azure

L'activation de l'intention de routage sur ce hub entraînerait l'état final suivant de defaultRouteTable. Tous les préfixes autres que 0.0.0.0/0 ou que ceux conformes à la norme RFC1918 sont consolidés dans un itinéraire unique nommé private_traffic.

Nom des routes	Préfixes	Ressource de tronçon suivant
_policy_PrivateTraffic	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Pare-feu Azure
_policy_PublicTraffic	0.0.0.0/0	Pare-feu Azure
trafic privé	40.0.0.0/24, 10.0.0.0/24, 50.0.0.0/24	Pare-feu Azure

Autres méthodes (PowerShell, REST, CLI)

La création d'une intention de routage à l'aide de méthodes en dehors du portail crée automatiquement les itinéraires de politique correspondants dans defaultRouteTable et supprime également tous les préfixes dans les itinéraires statiques qui correspondent exactement à 0.0.0.0/0 ou aux super-réseaux conformes à la norme RFC1918 (10.0.0.0/8, 192.168.0.0/16 ou 172.16.0.0/12). Toutefois, les autres itinéraires statiques ne sont pas automatiquement consolidés.

Par exemple, considérez le scénario où defaultRouteTable a les itinéraires suivants avant de configurer l'intention de routage :

Nom des routes	Préfixes	Ressource de tronçon suivant
firewall_route_1	10.0.0.0/8	Pare-feu Azure
firewall_route_2	192.168.0.0/16, 10.0.0.0/24	Pare-feu Azure
firewall_route_3	40.0.0.0/24	Pare-feu Azure
vers_internet	0.0.0.0/0	Pare-feu Azure

La table suivante représente l'état final de defaultRouteTable après la création de l'intention de routage. Notez que firewall_route_1 et to_internet ont été automatiquement supprimés, car le seul préfixe de ces itinéraires était 10.0.0.0/8 et 0.0.0.0/0. firewall_route_2 a été modifié pour supprimer 192.168.0.0/16, car ce préfixe est un préfixe d'agrégation en vertu de la norme RFC1918.

Nom des routes	Préfixes	Ressource de tronçon suivant
_policy_PrivateTraffic	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Pare-feu Azure
_policy_PublicTraffic	0.0.0.0/0	Pare-feu Azure
firewall_route_2	10.0.0.0/24	Pare-feu Azure
firewall_route_3	40.0.0.0/24	Pare-feu Azure

Publication de préfixes en local

La section suivante décrit comment Virtual WAN publie des itinéraires vers un site local après la configuration de l'intention de routage sur un hub virtuel.

Stratégie de routage Internet

Remarque

L'itinéraire par défaut 0.0.0.0/0 n'est pas publié sur les hubs virtuels.

Si vous activez les politiques de routage Internet sur le hub virtuel, l'itinéraire par défaut 0.0.0.0/0 est publié pour toutes les connexions au hub (réseau virtuel ExpressRoute, VPN site à site, VPN point à site, appliance virtuelle réseau dans le hub et connexions BGP) où l'indicateur Propager l'itinéraire par défaut ou Activer la sécurité Internet est défini sur true (vrai). Vous pouvez définir cet indicateur sur false pour toutes les connexions qui ne doivent pas apprendre l’itinéraire par défaut.

politique de routage privé

Lorsqu'un hub virtuel est configuré avec une politique de routage privé, Virtual WAN publie les itinéraires vers les connexions locales de la manière suivante :

Itinéraires correspondant aux préfixes appris auprès des connexions de réseaux virtuel, ExpressRoute, VPN site à site, VPN point à site, d’appliance virtuelle réseau dans le hub ou BGP du hub local connectées au hub actuel.
Itinéraires correspondant aux préfixes appris à partir des connexions de réseaux virtuels, ExpressRoute, VPN site à site, VPN point à site, d'appliance virtuelle réseau dans le hub ou BGP du hub distant où des politiques de routage privé sont configurées.
Les itinéraires correspondant aux préfixes appris à partir des connexions de réseaux virtuels, ExpressRoute, VPN site à site, VPN point à site, d'appliance virtuelle réseau dans le hub ou BGP du hub distant où l'intention de routage n'est pas configurée et où les connexions distantes se propagent au paramètre defaultRouteTable du hub local.
Les préfixes appris à partir d'un circuit ExpressRoute ne sont pas publiés vers d'autres circuits ExpressRoute, sauf si Global Reach est activé. Si vous souhaitez activer le transit ExpressRoute à ExpressRoute par le biais d'une solution de sécurité déployée dans le hub, ouvrez un cas de support. Pour plus d'informations, Consultez Activation de la connectivité entre les circuits ExpressRoute.

Scénarios de routage clés

La section suivante décrit quelques scénarios de routage et comportements de routage clés lors de la configuration de l’intention de routage sur un hub Virtual WAN.

Connectivité de transit entre circuits ExpressRoute avec intention de routage

La connectivité de transit entre circuits ExpressRoute au sein de Virtual WAN est fournie en utilisant deux configurations différentes. Comme ces deux configurations ne sont pas compatibles, les clients doivent choisir une option de configuration pour prendre en charge la connectivité de transit entre deux circuits ExpressRoute.

Remarque

Pour activer la connectivité de transit ExpressRoute vers ExpressRoute en utilisant une appliance de pare-feu dans le hub avec des stratégies de routage privé, ouvrez un cas de support auprès du support Microsoft. Cette option n’est pas compatible avec Global Reach et exige que Global Reach soit désactivé pour garantir un routage de transit approprié entre tous les circuits ExpressRoute connectés à Virtual WAN.

ExpressRoute Global Reach : ExpressRoute Global Reach permet à deux circuits Global Reach de s’envoyer du trafic l’un à l’autre directement sans transiter par le hub virtuel.
Politique de routage privé : La configuration des politiques de routage privé permet à deux circuits ExpressRoute de s'envoyer du trafic mutuellement via une solution de sécurité déployée dans le hub.

La connectivité entre les circuits ExpressRoute via un pare-feu situé dans le hub, utilisant une stratégie de routage privé, est disponible dans les configurations suivantes :

Les deux circuits ExpressRoute sont connectés au même hub et une politique de routage privé est configurée sur ce hub.
Les circuits ExpressRoute sont connectés à différents hubs et une stratégie de routage privé est configurée sur les deux hubs. Par conséquent, les deux hubs doivent avoir une solution de sécurité déployée.

Facteurs à prendre en compte pour le routage avec ExpressRoute

Remarque

Les considérations relatives au routage ci-dessous s’appliquent à tous les hubs virtuels dans les abonnements qui sont activés par Support Microsoft pour autoriser la connectivité ExpressRoute à ExpressRoute via une appliance de sécurité dans le hub.

Une fois activée la connectivité de transit entre les circuits ExpressRoute à l'aide d'une appliance de pare-feu déployé dans le hub virtuel, vous pouvez vous attendre aux changements de comportement suivants dans la façon dont les itinéraires sont publiés vers ExpressRoute localement :

Virtual WAN publie automatiquement les préfixes d'agrégation conformes à la norme RFC1918 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) sur le site local connecté à ExpressRoute. Ces itinéraires agrégés sont publiés en plus des itinéraires décrits dans la section précédente.
Virtual WAN publie automatiquement tous les itinéraires statiques de defaultRouteTable vers un circuit ExpressRoute connecté localement. Cela signifie que Virtual WAN publie en local les itinéraires spécifiés dans la zone de texte Préfixe de trafic privé.

En raison de ces modifications de publication de routage, l'infrastructure locale connectée par ExpressRoute ne peut pas publier de plages d'adresses exactes pour les plages d'adresses agrégées conformes à la norme RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Veillez à publier des sous-réseaux plus spécifiques (dans des plages conformes à la RFC1918) au lieu d’agréger des super-réseaux et des préfixes dans la zone de texte Trafic privé.

De plus, si votre circuit ExpressRoute publie un préfixe non-RFC1918 sur Azure, vérifiez que les plages d’adresses que vous placez dans la zone de texte Préfixes de trafic privé sont moins spécifiques que les routes publiées par ExpressRoute. Par exemple, si le circuit ExpressRoute publie 40.0.0.0/24 à partir d’un emplacement local, placez une plage CIDR /23 ou plus grande dans la zone de texte Préfixe de trafic privé (par exemple 40.0.0.0.0/23).

Les annonces de routage vers d’autres réseaux locaux (VPN site à site, VPN point à site, NVA) ne sont pas impactées par l’activation de la connectivité de transit ExpressRoute à ExpressRoute via une appliance de sécurité déployée dans le hub.

ExpressRoute chiffré

Pour utiliser ExpressRoute chiffré (tunnel VPN site à site exécuté sur un circuit ExpressRoute) avec des stratégies de routage privé d’intention de routage, configurez une règle de pare-feu pour autoriser le trafic entre les adresses IP privées de tunnel de la passerelle VPN site à site Virtual WAN (source) et l’appareil VPN local (destination). Pour les clients qui utilisent l’inspection approfondie des paquets sur l’appareil de pare-feu, il est recommandé d’exclure le trafic entre ces adresses IP privées de l’inspection approfondie des paquets.

Vous pouvez obtenir les adresses IP privées de tunnel de la passerelle VPN de site à site Virtual WAN en téléchargeant la configuration VPN et en affichant vpnSiteConnections -> gatewayConfiguration -> IPAddresses. Les adresses IP répertoriées dans le champ IPAddresses sont les adresses IP privées affectées à chaque instance de la passerelle VPN de site à site utilisée pour arrêter les tunnels VPN sur ExpressRoute. Dans l’exemple ci-dessous, les adresses IP de tunnel sur la passerelle sont 192.168.1.4 et 192.168.1.5.

 "vpnSiteConnections": [
      {
        "hubConfiguration": {
          "AddressSpace": "192.168.1.0/24",
          "Region": "South Central US",
          "ConnectedSubnets": [
            "172.16.1.0/24",
            "172.16.2.0/24",
            "172.16.3.0/24",
            "192.168.50.0/24",
            "192.168.0.0/24"
          ]
        },
        "gatewayConfiguration": {
          "IpAddresses": {
            "Instance0": "192.168.1.4",
            "Instance1": "192.168.1.5"
          },
          "BgpSetting": {
            "Asn": 65515,
            "BgpPeeringAddresses": {
              "Instance0": "192.168.1.15",
              "Instance1": "192.168.1.12"
            },
            "CustomBgpPeeringAddresses": {
              "Instance0": [
                "169.254.21.1"
              ],
              "Instance1": [
                "169.254.21.2"
              ]
            },
            "PeerWeight": 0
          }
        }

Les adresses IP privées que les appareils locaux ont utilisées pour l’arrêt VPN sont les adresses IP spécifiées dans le cadre de la connexion de site VPN.

À l’aide de l’exemple de configuration VPN et du site VPN ci-dessus, créez des règles de pare-feu pour autoriser le trafic suivant. L’adresse IP de passerelle VPN doit être l’adresse IP source et l’appareil VPN local doit être l’adresse IP de destination dans les règles configurées.

Paramètre de règle	Valeur
IP Source	192.168.1.4 et 192.168.1.5
Port source	*
IP de destination	10.100.0.4
Port de destination	*
Protocole	QUELCONQUE

Niveau de performance pour Encrypted ExpressRoute

La configuration des stratégies de routage privé avec ExpressRoute chiffré achemine les paquets VPN ESP via l’appliance de sécurité de tronçon suivant déployée dans le hub. Par conséquent, vous pouvez vous attendre à un débit maximal du tunnel VPN ExpressRoute chiffré de 1 Gbit/s dans les deux directions (entrant depuis un emplacement local et sortant depuis Azure). Pour obtenir le débit maximal du tunnel VPN, envisagez les optimisations de déploiement suivantes :

Déployez le Pare-feu Azure Premium au lieu du Pare-feu Azure Standard ou du Pare-feu Azure De base.
Assurez-vous que le Pare-feu Azure traite la règle qui autorise le trafic entre les points de terminaison du tunnel VPN (192.168.1.4 et 192.168.1.5 dans l’exemple ci-dessus) tout d’abord en faisant de la règle la priorité la plus haute dans votre stratégie de Pare-feu Azure. Pour plus d’informations sur la logique de traitement des règles de Pare-feu Azure, consultez Logique de traitement des règles de Pare-feu Azure.
Désactivez deep-packet pour le trafic entre les points de terminaison du tunnel VPN. Pour plus d’informations sur la configuration des pare-feu Azure pour exclure le trafic de l’inspection approfondie des paquets, consultez la documentation sur la liste de contournements IDPS.
Configurez les appareils VPN de sorte qu’ils utilisent GCMAES256 pour le chiffrement et l’intégrité IPSEC afin d’optimiser les performances.

Routage direct vers les instances NVA pour la connectivité à double rôle et les NVA de pare-feu

Remarque

Le routage direct vers une appliance virtuelle réseau à double rôle utilisé avec des stratégies de routage privé dans Virtual WAN s’applique uniquement au trafic entre les réseaux virtuels et les itinéraires appris via BGP auprès d’une appliance virtuelle réseau déployée dans le hub Virtual WAN. La connectivité de transit ExpressRoute et VPN à une appliance virtuelle réseau connectée localement n’est pas acheminée directement vers les instances NVA. Au lieu de cela, elle est acheminée via l’équilibreur de charge de l’appliance virtuelle réseau à double rôle.

Certaines appliances virtuelles réseau peuvent combiner des fonctionnalités de connectivité (SD-WAN) et de sécurité (NGFW). On parle alors d’appliances virtuelles réseau à double rôle. Vérifiez si votre appliance virtuelle réseau est à double rôle sous la section Partenaires.

Lorsque des stratégies de routage privé sont configurées pour des appliances virtuelles réseau à double rôle, Virtual WAN publie automatiquement les itinéraires appris auprès de l’appliance virtuelle réseau du hub Virtual WAN sur les réseaux virtuels directement connectés (locaux) ainsi que sur d’autres hubs virtuels dans Virtual WAN, le tronçon suivant étant l’instance NVA, et non l’équilibreur de charge interne des appliances virtuelles réseau.

Pour les configurations d’appliance virtuelle réseau en mode actif/passif où une seule instance des appliances virtuelles réseau publie un itinéraire pour un préfixe spécifique sur Virtual WAN (ou la longueur AS-PATH des itinéraires appris à partir de l’une des instances est toujours la plus courte), Virtual WAN garantit que le trafic sortant d’un réseau virtuel Azure est toujours acheminé vers l’instance d’appliance virtuelle réseau active (ou préférée).

Pour les configurations d’appliance virtuelle réseau en mode actif/actif (plusieurs instances d’appliance virtuelle réseau publient le même préfixe avec la même longueur AS-PATH), Azure utilise automatiquement ECMP pour acheminer le trafic d’Azure vers un emplacement local. La plateforme SDN (Software-Defined Networking) d’Azure ne garantit pas la symétrie au niveau du flux, ce qui signifie que le flux entrant vers Azure et le flux sortant d’Azure peuvent se retrouver sur différentes instances de l’appliance virtuelle réseau. Cela entraîne un routage asymétrique qui est supprimé par l’inspection du pare-feu avec état. Il n’est donc pas recommandé d’utiliser des modèles de connectivité en mode actif-actif où une appliance virtuelle réseau se comporte comme une appliance virtuelle réseau à double rôle, sauf si l’appliance virtuelle réseau peut prendre en charge le transfert asymétrique ou le partage/la synchronisation de session. Pour savoir si votre appliance virtuelle réseau prend en charge le transfert asymétrique ou le partage/la synchronisation de l’état de session, contactez le fournisseur de votre appliance virtuelle réseau.

Configuration de l’intention de routage via le portail Azure

L’intention de routage et les stratégies de routage peuvent être configurées via le portail Azure à l’aide de Azure Firewall Manager ou du portail Virtual WAN. Le portail Pare-feu Azure Manager vous permet de configurer des stratégies de routage avec les Pare-feu Azure de ressources de tronçon suivant. Le portail Virtual WAN vous permet de configurer des stratégies de routage avec la ressource de prochain saut, le pare-feu Azure, les appliances réseau virtuelles déployées dans le hub virtuel ou les solutions SaaS.

Les clients qui utilisent Pare-feu Azure dans un hub sécurisé de Virtual WAN peuvent soit définir le paramètre « Activer l’inter-hub » du Gestionnaire Pare-feu Azure sur « Activé » pour utiliser l’intention de routage, soit utiliser le portail Virtual WAN pour configurer directement Pare-feu Azure comme ressource du prochain saut pour l’intention de routage et les stratégies. Les configurations des deux expériences du portail sont équivalentes et les modifications apportées à Azure Firewall Manager sont automatiquement reflétées dans le portail Virtual WAN et inversement.

Configurer l'intention et les politiques de routage par le biais d'Azure Firewall Manager

Les étapes suivantes décrivent comment configurer l'intention de routage et les politiques de routage sur votre hub virtuel à l'aide d'Azure Firewall Manager. Azure Firewall Manager prend uniquement en charge les ressources de saut suivant de type Azure Firewall.

Accédez au hub Virtual WAN sur lequel vous souhaitez configurer les politiques de routage.
Sous Sécurité, sélectionnez Paramètres du hub virtuel sécurisé, puis Gérer les paramètres de fournisseur de sécurité et de routage pour ce hub virtuel sécurisé dans Azure Firewall Manager
Dans le menu, sélectionnez le hub sur lequel vous souhaitez configurer vos stratégies de routage.
Sous Paramètres, sélectionnez Configuration de la sécurité.
Si vous souhaitez configurer une stratégie de routage de trafic Internet, sélectionnez Pare-feu Azure ou le fournisseur de sécurité Internet concerné dans la liste déroulante pour Trafic Internet. Si ce n’est pas le cas, sélectionnez Aucun
Si vous souhaitez configurer une stratégie de routage du trafic privé (pour le trafic de la branche et du réseau virtuel) via le Pare-feu Azure, sélectionnez Pare-feu Azure dans la liste déroulante pour Trafic privé. Sinon, sélectionnez Contourner le Pare-feu Azure.
Si vous voulez configurer une politique de routage de trafic privé et que des branches ou des réseaux virtuels annoncent des préfixes non IANA RFC1918, sélectionnez Préfixes de trafic privé et spécifiez les plages de préfixes non IANA RFC1918 dans la zone de texte qui s’affiche. Sélectionnez Terminé.
Réglez Interhub sur Activé. L’activation de cette option garantit que vos stratégies de routage sont appliquées à l’intention de routage de ce hub Virtual WAN.
Sélectionnez Enregistrer.
Répétez les étapes 2-8 pour les autres hubs Virtual WAN sécurisés pour lesquels vous souhaitez configurer des stratégies de routage.
À ce stade, vous êtes prêt à envoyer le trafic de test. Vérifiez que vos stratégies de pare-feu sont correctement configurées pour autoriser/refuser le trafic en fonction de vos configurations de sécurité souhaitées.

Configurer l'intention de routage et les politiques de routage via le portail Virtual WAN

Les étapes suivantes décrivent comment configurer l'intention de routage et les politiques de routage sur votre hub virtuel à l'aide du portail Virtual WAN.

À partir du lien du portail personnalisé fourni dans l’e-mail de confirmation de l’étape 3, dans la section Prérequis, naviguez vers le hub Virtual WAN sur lequel vous souhaitez configurer les stratégies de routage.
Sous Routage, sélectionnez Stratégies de routage.
Si vous souhaitez configurer une politique de routage du trafic privé (pour le trafic de branche et de réseau virtuel), sélectionnez Pare-feu Azure, Appliance virtuelle réseau ou Solutions SaaS sous Trafic privé. Sous Ressource de tronçon suivant, sélectionnez la ressource de tronçon suivant appropriée.
Si vous souhaitez configurer une stratégie de routage du trafic privé et que vous avez des branches ou des réseaux virtuels qui utilisent des préfixes non-IANA RFC1918, sélectionnez Préfixes supplémentaires et spécifiez les plages de préfixes non-IANA RFC1918 dans la zone de texte qui s’affiche. Sélectionnez Terminé. Veillez à ajouter le même préfixe à la zone de texte du préfixe Trafic privé dans tous les hubs virtuels configurés avec des stratégies de routage privé pour vous assurer que les itinéraires appropriés sont publiés pour tous les hubs.
Si vous souhaitez configurer une politique de routage du trafic Internet, sélectionnez Pare-feu Azure, Appliance virtuelle réseau ou Solution SaaS. Sous Ressource de tronçon suivant, sélectionnez la ressource de tronçon suivant appropriée.
Pour appliquer la configuration de votre intention et de vos stratégies de routage, cliquez sur Enregistrer.
Répétez cette opération pour tous les hubs pour lesquels vous souhaitez configurer des stratégies de routage.
À ce stade, vous êtes prêt à envoyer le trafic de test. Vérifiez que vos politiques de pare-feu sont correctement configurées pour autoriser/refuser le trafic en fonction de vos configurations de sécurité souhaitées.

Configurer l’intention de routage à l’aide d’un fichier Bicep

Pour plus d’informations sur le modèle et les étapes, consultez le fichier Bicep .

Résolution des problèmes

La section suivante décrit les méthodes courantes de résolution des problèmes lorsque vous configurez l'intention de routage et les politiques de routage sur votre hub Virtual WAN.

Itinéraires effectifs

Remarque

L’obtention d’itinéraires effectifs appliqués aux ressources de tronçon suivant de l’intention de routage Virtual WAN est prise en charge uniquement pour la ressource de tronçon suivant spécifiée dans la stratégie de routage privé. Si vous utilisez à la fois des stratégies de routage privé et Internet, vérifiez les itinéraires effectifs sur la ressource de tronçon suivant spécifiée dans la stratégie de routage privé pour les itinéraires effectifs des programmes Virtual WAN sur la ressource de tronçon suivant de la stratégie de routage Internet. Si vous utilisez uniquement des stratégies de routage Internet, vérifiez les itinéraires effectifs sur defaultRouteTable pour afficher les itinéraires programmés sur la ressource de tronçon suivant de la stratégie de routage Internet.

Lorsque les stratégies de routage privé sont configurées sur le hub virtuel, l’ensemble du trafic entre les réseaux locaux et les réseaux virtuels est inspecté par le Pare-feu Azure, une appliance virtuelle réseau ou une solution SaaS dans le hub virtuel.

Par conséquent, les routes effectives de defaultRouteTable affichent les préfixes d'agrégation conformes à la norme RFC1918 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) avec Pare-feu Azure ou une appliance virtuelle réseau de tronçon suivant. Cela indique que l’intégralité du trafic entre les réseaux virtuels et les branches est acheminée vers le Pare-feu Azure, une appliance virtuelle réseau ou une solution SaaS dans le hub à des fins d’inspection.

Une fois que le pare-feu a inspecté le paquet (et que ce dernier est autorisé conformément à la configuration de règle de pare-feu), Virtual WAN transfère le paquet vers sa destination finale. Pour voir quels itinéraires Virtual WAN utilise pour transférer les paquets inspectés, consultez la table de routage efficace du pare-feu ou de l'appliance virtuelle réseau.

La table d'itinéraires efficaces du pare-feu permet d'affiner et d'isoler les problèmes dans votre réseau, tels que des configurations incorrectes ou des problèmes avec certaines branches et certains réseaux virtuels.

Dépannage des problèmes de configuration

Pour résoudre les problèmes de configuration, tenez compte des facteurs suivants :

Vérifiez que vous n'avez pas de tables de routage personnalisées ou d'itinéraires statiques dans defaultRouteTable associés à la connexion réseau virtuel de tronçon suivant.
- L'option permettant de configurer l'intention de routage est grisée dans le portail Azure si votre déploiement ne répond pas aux exigences ci-dessus.
- Si vous utilisez l'interface CLI, PowerShell ou REST, l'opération de création d'intention de routage échouera. Supprimez l'intention de routage ayant échoué, supprimez les tables de routage personnalisées et les itinéraires statiques, puis essayez de les recréer.
- Si vous utilisez Azure Firewall Manager, vérifiez que les itinéraires existants dans defaultRouteTable sont nommés private_traffic, internet_traffic ou all_traffic. L'option de configuration de l'objectif de routage (activer l'inter-hub) est rendue inaccessible si les itinéraires ont des noms différents.
Après avoir configuré l'intention de routage sur un hub, assurez-vous que toutes les mises à jour apportées aux connexions existantes ou nouvelles au hub sont créées avec les champs facultatifs de table de routage associés et propagés laissés vierges. La définition des associations et des propagations facultatives sur la valeur vides est effectuée automatiquement pour toutes les opérations effectuées via le portail Azure.

Résolution des problèmes de chemin de données

En supposant que vous avez déjà examiné la section Limitations connues, voici quelques façons de résoudre les problèmes de chemin de données et de connectivité :

Résolution des problèmes avec les itinéraires effectifs :
- Si des stratégies de routage privé sont configurées, vous devriez voir les itinéraires avec le pare-feu de tronçon suivant dans les itinéraires effectifs de la defaultRouteTable pour les agrégats conformes à la RFC1918 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) ainsi que les préfixes spécifiés dans la zone de texte Trafic privé. Vérifiez que tous les préfixes Réseau virtuel et locaux sont des sous-réseaux dans les itinéraires statiques dans defaultRouteTable. Si un site local ou un réseau virtuel utilise un espace d'adressage qui n'est pas un sous-réseau dans les routes effectives dans defaultRouteTable, ajoutez le préfixe à la zone de texte Trafic privé.
- Si les politiques de routage du trafic Internet sont configurées, vous devriez voir un itinéraire par défaut (0.0.0.0/0) dans la route effective de defaultRouteTable.
- Une fois que vous avez vérifié que les préfixes des routes effectives de defaultRouteTable sont corrects, affichez les routes effectives de l'appliance virtuelle réseau ou du Pare-feu Azure. Les routes effectives sur le pare-feu indiquent les itinéraires que Virtual WAN a sélectionnés et déterminent les destinations vers lesquelles le pare-feu peut transférer les paquets. Déterminer quels préfixes sont manquants ou dans un état incorrect permet de limiter les problèmes de chemin de données et de pointer vers la connexion VPN, ExpressRoute, d'appliance virtuelle réseau ou BGP appropriée pour résoudre les problèmes.
Résolution des problèmes propres à des scénarios :
- Si votre Virtual WAN comporte un hub non sécurisé (hub sans pare-feu Azure ni appliance virtuelle réseau), assurez-vous que les connexions au hub non sécurisé se propagent à la table defaultRouteTable des hubs avec l'intention de routage configurée. Si les propagations ne sont pas définies sur defaultRouteTable, les connexions au hub sécurisé ne pourront pas envoyer de paquets au hub non sécurisé.
- Si vous avez configuré des politiques de routage Internet, assurez-vous que le paramètre « Propager l'itinéraire par défaut » ou « Activer la sécurité Internet » est défini sur « true » (vrai) pour toutes les connexions qui doivent apprendre l'itinéraire par défaut 0.0.0.0/0. Les connexions pour lesquelles ce paramètre est défini sur « false » (faux) n'apprendront pas la route 0.0.0.0/0, même si des politiques de routage Internet sont configurées.
- Si vous utilisez des points de terminaison privés déployés dans des réseaux virtuels connectés au hub virtuel, le trafic local destiné aux points de terminaison privés déployés dans les réseaux virtuels connectés au hub Virtual WAN par défaut contourne le Pare-feu Azure, l’appliance virtuelle réseau ou la solution SaaS de tronçon suivant de l’intention de routage. Toutefois, cela entraîne un routage asymétrique (qui peut entraîner une perte de connectivité entre les points de terminaison locaux et privés) car les points de terminaison privés dans les réseaux virtuels Spoke transfèrent le trafic local vers le pare-feu. Pour garantir la symétrie du routage, activez les stratégies réseau de table de routage pour les points de terminaison privés sur les sous-réseaux où les points de terminaison privés sont déployés. La configuration d’itinéraires /32 correspondant aux adresses IP privées de point de terminaison privé dans la zone de texte Trafic privé ne garantit pas la symétrie du trafic lorsque les stratégies de routage privé sont configurées sur le hub.
- Si vous utilisez ExpressRoute chiffré avec des stratégies de routage privé, vérifiez qu’une règle de pare-feu est configurée pour autoriser le trafic entre le point de terminaison de tunnel IP privé de passerelle VPN de site à site Virtual WAN et le périphérique VPN local. Les paquets ESP (externes chiffrés) doivent se connecter aux journaux Pare-feu Azure. Pour plus d’informations sur ExpressRoute chiffré avec intention de routage, consultez la documentation sur ExpressRoute chiffré.
- Si vous utilisez des tables d’itinéraires définies par l’utilisateur sur vos réseaux virtuels spoke, vérifiez que l’option « Propager les itinéraires de passerelle » est réglée sur « Oui » dans la table de routage. L’option « Propager les itinéraires de passerelle » doit être activée pour que Virtual WAN puisse publier des itinéraires sur les charges de travail déployées dans les réseaux virtuels de rayon connectés à Virtual WAN. Pour plus d’informations sur les paramètres de table d’un routage défini par l’utilisateur, consultez la documentation sur le routage de réseau virtuel défini par l’utilisateur.

Résolution des problèmes de routage Pare-feu Azure

Assurez-vous que l'état d'approvisionnement du Pare-feu Azure est réussi avant d'essayer de configurer l'intention de routage.
Si vous utilisez des préfixes non conformes à la norme RFC1918 de l'IANA dans vos branches/réseaux virtuels, vérifiez que vous avez spécifié ces préfixes dans la zone de texte Préfixes de trafic privé. Les « préfixes privés » configurés ne se propagent pas automatiquement à d’autres hubs dans le Virtual WAN configuré avec une intention de routage. Pour garantir la connectivité, ajoutez ces préfixes à la zone de texte « Préfixes privés » de chaque hub qui a une intention de routage.
Si vous avez spécifié des adresses non RFC1918 dans la zone de texte Préfixes de trafic privés du gestionnaire de pare-feu, vous devrez peut-être configurer des stratégies SNAT sur votre pare-feu pour désactiver SNAT pour le trafic privé non RFC1918. Pour plus d'informations, consultez les plages SNAT du Pare-feu Azure.
Configurez et consultez les journaux du Pare-feu Azure pour faciliter le dépannage et l'analyse de votre trafic réseau. Pour plus d’informations sur la configuration de la surveillance du Pare-feu Azure, consultez Diagnostics du Pare-feu Azure. Pour obtenir une vue d'ensemble des différents types de journaux de pare-feu, consultez Journaux et métriques du Pare-feu Azure.
Pour plus d’informations sur le Pare-feu Azure, consultez la documentation du Pare-feu Azure.

Résoudre les problèmes d’appliance virtuelle réseau

Assurez-vous que l'état d'approvisionnement de l'appliance virtuelle réseau est réussi avant d'essayer de configurer l'intention de routage.
Si vous utilisez des préfixes non conformes à la norme RFC1918 de l'IANA dans vos sites locaux ou vos réseaux virtuels connectés, vérifiez que vous avez spécifié ces préfixes dans la zone de texte Préfixes de trafic privé. Les « préfixes privés » configurés ne se propagent pas automatiquement à d’autres hubs dans le Virtual WAN configuré avec une intention de routage. Pour garantir la connectivité, ajoutez ces préfixes à la zone de texte « Préfixes privés » de chaque hub qui a une intention de routage.
Si vous avez spécifié des adresses non conformes à la norme RFC1918 dans la zone de texte Préfixes de trafic privé, vous devrez peut-être configurer des politiques SNAT sur votre pare-feu pour désactiver SNAT pour une partie du trafic privé non conforme à la norme RFC1918.
Vérifiez les journaux Pare-feu NVA pour voir si le trafic est actuellement supprimé ou refusé par vos règles de pare-feu.
Veuillez contacter votre fournisseur NVA pour obtenir une assistance et des conseils supplémentaires sur la résolution de problèmes.

Résolution des problèmes liés au logiciel en tant que service

Assurez-vous que l'état d'approvisionnement de la solution SaaS est réussi avant d'essayer de configurer l'intention de routage.
Pour obtenir d'autres conseils sur la résolution des problèmes, consultez la section Résolution des problèmes de la documentation consacrée à Virtual WAN ou de la documentation relative à Palo Alto Networks Cloud NGFW.

Étapes suivantes

Pour plus d’informations sur le routage de hub virtuel, consultez À propos du routage de hub virtuel. Pour plus d’informations sur Virtual WAN, consultez la FAQ.

Partage via

Comment configurer l’intention de routage et les stratégies de routage d’un hub Virtual Wan

Contexte

Cas d’utilisation

Tous les hubs Virtual WAN sont sécurisés (déployés avec le Pare-feu Azure, une appliance réseau virtuelle ou une solution SaaS)

Déploiement de hubs Virtual WAN à la fois sécurisés et ordinaires

Limitations connues

Limites d’espace d’adressage du réseau virtuel

Considérations

Prérequis

Stratégie de retour en arrière

Itinéraires statiques dans defaultRouteTable

Azure Firewall Manager et portail du hub Virtual WAN

Autres méthodes (PowerShell, REST, CLI)

Publication de préfixes en local

Stratégie de routage Internet

politique de routage privé

Scénarios de routage clés

Connectivité de transit entre circuits ExpressRoute avec intention de routage

Facteurs à prendre en compte pour le routage avec ExpressRoute

ExpressRoute chiffré

Niveau de performance pour Encrypted ExpressRoute

Routage direct vers les instances NVA pour la connectivité à double rôle et les NVA de pare-feu

Configuration de l’intention de routage via le portail Azure

Configurer l'intention et les politiques de routage par le biais d'Azure Firewall Manager

Configurer l'intention de routage et les politiques de routage via le portail Virtual WAN

Configurer l’intention de routage à l’aide d’un fichier Bicep

Résolution des problèmes

Itinéraires effectifs

Dépannage des problèmes de configuration

Résolution des problèmes de chemin de données

Résolution des problèmes de routage Pare-feu Azure

Résoudre les problèmes d’appliance virtuelle réseau

Résolution des problèmes liés au logiciel en tant que service

Étapes suivantes

Commentaires

Ressources supplémentaires