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

  • Article

L'intention de routage hub Virtual WAN vous permet de configurer des politiques de routage simples et déclaratives pour envoyer du trafic vers des solutions de sécurité intégrées comme les 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 politiques 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 , une appliance virtuelle réseau de pare-feu de nouvelle génération (NGFW-NVA) ou une solution SaaS (logiciel en tant que service) de sécurité 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.

  • politique de routage du trafic Internet : quand une politique 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 au Pare-feu Azure, au fournisseur de sécurité tiers, à l'appliance virtuelle réseau ou à la solution SaaS spécifié dans la politique de routage.

    En d'autres termes, lorsque la politique 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 à l'ensemble des spokes, passerelles et appliances virtuelles réseau (déployé dans le hub ou le spoke).

  • politique de routage du trafic privé : lorsqu'une politique 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 transmis à 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 politique de routage du trafic privé est configurée sur le hub Virtual WAN, tout le trafic de branche à branche, de branche à réseau virtuel et de réseau virtuel à branche ainsi que hub à hub 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.

Capture d’écran montrant l’architecture avec deux hubs sécurisés.

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 :

  • politique de trafic privé avec ressource de Pare-feu Azure, d'appliance virtuelle réseau ou de solution SaaS de hub 1 pour le tronçon suivant
  • politique de trafic Internet avec ressource de Pare-feu Azure, d'appliance virtuelle réseau ou de solution SaaS de hub 1 pour le tronçon suivant

Configuration de Hub 2 :

  • politique de trafic privé avec ressource de Pare-feu Azure, d'appliance virtuelle réseau ou de solution SaaS de hub 2 pour le tronçon suivant
  • politique de trafic Internet avec ressource de Pare-feu Azure, d'appliance virtuelle réseau ou de solution SaaS de hub 2 pour le 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 de hubs 1 et 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hubs 1 et 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 1
Branches Hub 1 → Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 1 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 1 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hubs 1 et 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hubs 1 et 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 1
Réseaux virtuels Hub 2 → Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hubs 1 et 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hubs 1 et 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2
Branches Hub 2 → Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hubs 1 et 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hubs 1 et 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 Pare-feu Azure, d'appliance virtuelle réseau ou de solution SaaS de 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 politiques 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 :

  • politique de trafic privé avec ressource de Pare-feu Azure, d'appliance virtuelle réseau ou de solution SaaS de hub 2 pour le tronçon suivant.
  • politique de trafic Internet avec ressource de Pare-feu Azure, d'appliance virtuelle réseau ou de solution SaaS de hub 2 pour le tronçon suivant.

Capture d’écran montrant l’architecture avec un hub sécurisé un hub normal.

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 de hub 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 -
Branches Hub 1 → Direct Direct Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 -
Réseaux virtuels Hub 2 → Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2
Branches Hub 2 → Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2 Pare-feu Azure, appliance virtuelle réseau ou solution SaaS de hub 2

Limites connues

  • L’intention de routage est actuellement disponible dans Azure Public. Microsoft Azure géré par 21Vianet et Azure Government sont actuellement dans la feuille de route.
  • 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.
    • 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.

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

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.

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.

Capture d’écran de l’adresse IP du tunnel d’appareil local du 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

Performances

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.
  • Activez l’inspection approfondie des paquets pour le trafic entre les points de terminaison du tunnel VPN. Pour plus d’informations sur la configuration du 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.

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.

  1. Accédez au hub Virtual WAN sur lequel vous souhaitez configurer les politiques de routage.

  2. 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 Capture d'écran montrant comment modifier des paramètres de hub sécurisé.

  3. Dans le menu, sélectionnez le hub sur lequel vous souhaitez configurer vos stratégies de routage.

  4. Sous Paramètres, sélectionnez Configuration de la sécurité.

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

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

    Capture d’écran montrant comment configurer des stratégies de routage.

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

    Capture d’écran montrant comment modifier les préfixes de trafic privé.

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

  9. Sélectionnez Enregistrer.

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

  11. À 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.

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

  2. Sous Routage, sélectionnez Stratégies de routage.

    Capture d’écran montrant comment naviguer vers les stratégies de routage.

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

    Capture d’écran montrant comment configurer les stratégies de routage privé d’une appliance virtuelle réseau.

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

    Capture d’écran montrant comment configurer les préfixes privés supplémentaires pour les politiques de routage des appliances virtuelles réseau.

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

    Capture d’écran montrant comment configurer des stratégies de routage publiques.

  6. Pour appliquer la configuration de votre intention et de vos stratégies de routage, cliquez sur Enregistrer.

    Capture d'écran montrant comment enregistrer les configurations des politiques de routage.

  7. Répétez cette opération pour tous les hubs pour lesquels vous souhaitez configurer des stratégies de routage.

  8. À 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

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 Pare-feu Azure, une appliance virtuelle réseau ou une solution SaaS dans le hub à des fins d'inspection.

Capture d'écran montrant les routes effectives pour defaultRouteTable.

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.

Capture d'écran montrant les itinéraires efficaces pour Pare-feu Azure.

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 de 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

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