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

Article
10/14/2024

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é transparentes (« bump-in-the-wire ») comme le Pare-feu Azure, les appliances virtuelles réseau ou les solutions SaaS (software as a service) déployées au sein du hub Virtual WAN.

Background

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 virtuelle réseau 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 intégré. 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.

Notes

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.

Du	À	Réseaux virtuels Hub 1	Branches Hub 1	Réseaux virtuels Hub 2	Branches Hub 2	Internet
Réseaux virtuels Hub 1	→	Hub 1 avec AzFW ou NVA	Hub 1 avec AzFW ou NVA	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.

Du	À	Réseaux virtuels Hub 1	Branches Hub 1	Réseaux virtuels Hub 2	Branches Hub 2	Internet
Réseaux virtuels Hub 1	→	Direct	Direct	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	→	Direct	Direct	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

Limites 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é par 21Vianet.
- 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 (NVA) ne sont pas disponibles dans toutes les régions Azure Government. Contactez votre partenaire NVA au sujet de la disponibilité dans Azure Government.

Environnement cloud	Pare-feu Azure	Appliance virtuelle réseau	Solutions SaaS
Azure (public)	Oui	Oui	Oui
Azure Government	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 Virtual WAN avec des tables de routage personnalisées et des politiques personnalisées ne peuvent pas être utilisés avec les constructions d'intention de routage.
ExpressRoute chiffré (tunnels VPN de site à site s’exécutant sur des circuits ExpressRoute) est pris en charge dans les hubs où l’intention de routage est configurée si Pare-feu Azure est configuré pour autoriser le trafic entre les points de terminaison de tunnel VPN (adresse IP privée de passerelle VPN de site à site et adresse IP privée du périphérique de VPN local). Pour plus d’informations sur les configurations requises, consultez ExpressRoute chiffré avec intention de routage.
Les cas d'usage de connectivité suivants ne sont pas pris en charge avec l'intention de routage :
- 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é de peering 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 se trouve sur la feuille de route.
- La possibilité de déployer à la fois une appliance virtuelle réseau de connectivité SD-WAN et une solution distincte SaaS ou NVA de pare-feu dans le même hub Virtual WAN est actuellement dans la feuille de route. Une fois l’intention de routage configurée avec la solution SaaS du tronçon suivant ou l’appliance virtuelle réseau de pare-feu, la connectivité entre l’appliance virtuelle réseau SD-WAN et Azure est affecté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 spoke connecté au hub et tirer parti de la fonctionnalité de peering BGP du hub virtuel.
- Les appliances virtuelles réseau (NVA) peuvent être spécifiées en tant que ressource de tronçon suivant pour l'intention de routage uniquement s'il s'agit d'un pare-feu de nouvelle génération ou d'un pare-feu de nouvelle génération à double rôle, et s'il s'agit d'appliances virtuelles réseau SD-WAN. Actuellement, le point de contrôle, fortinet-ngfw et fortinet-ngfw-and-sdwan sont les seules appliances virtuelles réseau pouvant être configurées comme tronçon suivant pour l'intention de routage. Si vous essayez de spécifier une autre appliance virtuelle réseau, la création d'intention de routage échoue. Vous pouvez cochez le type de l'appliance virtuelle 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 SolutionSaaS.
- 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 de l’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’adressage 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 ocurred  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

À propos de l’installation

Les clients qui utilisent actuellement le Pare-feu Azure dans le hub Virtual WAN sans intention de routage peuvent activer l'intention de routage en utilisant Azure Firewall Manager, le portail de routage hub Virtual WAN ou 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 sans tables de routage personnalisées et sans itinéraires statiques dans le defaultRouteTable avec la connexion réseau virtuelle de tronçon 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 politique de restauration.
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 effectuez la configuration à l'aide de REST, de CLI ou de PowerShell. Pour plus d'informations, consultez Itinéraires statiques.
L'activation de l'intention de routage affecte la publication des préfixes vers le site 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 publiés vers les 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 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 un paquet de plan de données effectuant un transfert sur des hubs configurés avec une intention de routage. Toutefois, vous devrez peut-être allouer des unités d’infrastructure de routage 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.
Les itinéraires statiques ne peuvent pas être associés à la connexion réseau virtuel de tronçon suivant. Des itinéraires statiques de la table defaultRouteTable peuvent avoir 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 restauration

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

Notes

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
private_traffic	192.168.0.0/16, 172.16.0.0/12, 40.0.0.0/24, 10.0.0.0/24	Pare-feu Azure
to_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
private_traffic	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
to_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 vers un site 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

Notes

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 (faux) 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 à partir des connexions réseaux virtuel, ExpressRoute, VPN site à site, VPN point à site, 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 ExpressRoute vers le transit 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 nécessite 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.
Stratégie de routage privé d’intention de routage : la configuration de stratégies de routage privé permet à deux circuits ExpressRoute de s’envoyer du trafic l’un à l’autre en utilisant une solution de sécurité déployée dans le hub.

La connectivité entre circuits ExpressRoute en utilisant une appliance de pare-feu dans le hub avec une stratégie de routage privé d’intention de routage 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 vers un site 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, le circuit ExpressRoute connecté localement 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 publications de route sur 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 vers ExpressRoute avec une appliance de sécurité déployée dans le hub.

ExpressRoute chiffré

Pour utiliser ExpressRoute chiffré (tunnel VPN de site à site s’exécutant 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 de site à site Virtual WAN (source) et le périphérique 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	*
Protocol	ANY

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 l’inspection approfondie des paquets 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 des instances d’appliance virtuelle réseau pour la connectivité à double rôle et les appliances virtuelles réseau 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 à partir 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 d’appliance virtuelle réseau. 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 à partir 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 d’appliance virtuelle réseau (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. Virtual WAN portail vous permet de configurer des stratégies de routage avec la ressource de tronçon suivante Pare-feu Azure, appliances virtuelles réseau déployées dans le hub virtuel ou les solutions SaaS.

Les clients qui utilisent Pare-feu Azure dans Virtual WAN hub sécurisé peuvent définir le paramètre « Activer l’inter-hub » de Pare-feu Azure Manager sur « Activé » pour utiliser l’intention de routage ou utiliser Virtual WAN portail pour configurer directement Pare-feu Azure comme ressource de tronçon suivant pour l’intention de routage et les stratégies. Les configurations des deux expériences du portail sont équivalentes et les modifications apportées à Pare-feu Azure Manager sont automatiquement reflétées dans Virtual WAN portail 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 tronçon suivant de type Pare-feu Azure.

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 avec un modèle BICEP

Consultez le Modèle BICEP pour plus d’informations sur le modèle et les étapes.

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 des itinéraires effectifs appliqués aux ressources de tronçon suivant de l’intention de routage Virtual WAN n’est prise en charge que 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 à nouveau de créer l'intention de routage.
- 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'intention de routage (activer l'inter hub) est grisée si les itinéraires sont nommés différemment.
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 routes effectives :
- Si des politiques de routage privé sont configurées, vous devriez voir les itinéraires avec le pare-feu de tronçon suivant dans les routes effectives de defaultRouteTable pour les agrégats conformes à la norme 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 le 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 ExpressRoute chiffré.

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 Qu'est-ce que le Pare-feu Azure ?.
Configurez et affichez les journaux du Pare-feu Azure pour vous aider à dépanner et analyser le 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 du pare-feu d'appliance virtuelle réseau pour voir si le trafic est supprimé ou refusé par vos règles de pare-feu.
Contactez votre fournisseur d'appliance virtuelle réseau pour obtenir une assistance et des conseils supplémentaires sur la résolution des 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.

Partager via

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

Background

Cas d'utilisation

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

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

Limites connues

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

À propos de l’installation

Prérequis

Stratégie de restauration

Itinéraires statiques dans defaultRouteTable

Azure Firewall Manager et portail du hub Virtual WAN

Autres méthodes (PowerShell, REST, CLI)

Publication de préfixes vers un site 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 des instances d’appliance virtuelle réseau pour la connectivité à double rôle et les appliances virtuelles réseau 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 avec un modèle 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