Injection de routes par défaut dans des réseaux virtuels spoke

L’une des architectures les plus courantes dans Azure est la conception hub-and-spoke, où les charges de travail déployées dans un réseau virtuel spoke envoient du trafic via des appareils réseau partagés qui existent dans le réseau virtuel hub. Les routes définies par l’utilisateur doivent généralement être configurées dans les réseaux virtuels spoke pour diriger le trafic vers les appareils de sécurité dans le hub. Toutefois, cette conception oblige les administrateurs à gérer ces routes sur de nombreux spokes.

Le Serveur de routes Azure offre un point centralisé où les appliances virtuelles réseau peuvent publier des itinéraires qu’il injecte dans les réseaux virtuels spoke. Ainsi, les administrateurs n’ont pas besoin de créer et de mettre à jour des tables de routage dans des réseaux virtuels spoke.

Topologie

Le diagramme suivant illustre une conception hub-and-spoke simple avec un réseau virtuel hub et deux réseaux virtuels spoke. Dans le hub, une appliance virtuelle réseau et un serveur de routes ont été déployés. Sans le serveur de routes, les itinéraires définis par l’utilisateur doivent être configurés dans chaque spoke. Ces routes définies par l’utilisateur (UDR) contiennent généralement un itinéraire par défaut pour 0.0.0.0/0 qui envoie tout le trafic des réseaux virtuels spoke via l’appliance virtuelle réseau (NVA). Ce scénario peut être utilisé, par exemple, pour inspecter le trafic à des fins de sécurité.

Dans ce scénario avec le serveur de routage dans le réseau virtuel hub, il n’est pas nécessaire d’utiliser des itinéraires définis par l’utilisateur. L’appliance virtuelle réseau publie des préfixes réseau au serveur de routes, qui les injecte afin qu’ils apparaissent dans les itinéraires effectifs de toute machine virtuelle déployée dans le réseau virtuel hub ou les réseaux virtuels spoke qui sont appairés avec le réseau virtuel hub avec le paramètre Utiliser la passerelle ou le serveur de routes du réseau virtuel distant.

Connectivité à un serveur local via l’appliance virtuelle réseau

Si l’appliance virtuelle réseau est utilisée pour assurer la connectivité au réseau local via des réseaux VPN IPsec ou des technologies SD-WAN, le même mécanisme peut être utilisé pour attirer le trafic des spokes vers l’appliance virtuelle réseau. En outre, l’appliance virtuelle réseau peut découvrir de manière dynamique les préfixes Azure à partir du Serveur de routes Azure et les publier avec un protocole de routage dynamique vers le site local. Le diagramme suivant décrit cette configuration :

Inspection du trafic privé via l’appliance virtuelle réseau

Les sections précédentes illustrent le trafic inspecté par l’Appliance virtuelle réseau (NVA) en injectant un itinéraire par défaut 0.0.0.0/0 de l’appliance virtuelle réseau vers le serveur de routes. Cependant, si vous souhaitez inspecter uniquement le trafic de spoke à spoke et de spoke à local via l’appliance virtuelle réseau, vous devez tenir compte du fait que le Serveur de routes Azure ne publie pas une route dont le préfixe est de longueur égale ou supérieure à l’espace d’adressage du réseau virtuel appris auprès de l’appliance virtuelle réseau. En d’autres termes, le Serveur de routes Azure n’injecte pas ces préfixes dans le réseau virtuel et ils ne sont pas programmés sur les cartes réseau des machines virtuelles dans les réseaux virtuels hub ou spoke.

En revanche, le Serveur de routes Azure publiera un sous-réseau plus étendu que l’espace d’adressage du réseau virtuel qui est appris auprès l’appliance virtuelle réseau. Il est possible de publier à partir de l’appliance virtuelle réseau un supernet de ce que vous avez dans votre réseau virtuel. Par exemple, si votre réseau virtuel utilise l’espace d’adressage RFC 1918 10.0.0.0/16, votre appliance virtuelle réseau peut publier 10.0.0.0/8 sur le Serveur de routes Azure et ces préfixes sont injectés dans les réseaux virtuels hub-and-spoke. Ce comportement de réseau virtuel est référencé dans À propos du protocole BGP avec la passerelle VPN.

Important

Si vous êtes exposé à un scénario où des préfixes de même longueur sont publiés à partir d’ExpressRoute et de l’appliance virtuelle réseau, Azure préfère programmer les routes apprises auprès d’ExpressRoute. Pour obtenir plus d’informations, consultez Préférence de routage.

Connectivité locale via des passerelles de réseau virtuel

Si une passerelle VPN ou ExpressRoute existe dans le même réseau virtuel que le Serveur de routes Azure et l’appliance virtuelle réseau pour assurer la connectivité vers les réseaux locaux, les routes apprises par ces passerelles sont également programmées dans les réseaux virtuels spoke. Ces routes remplacent la route par défaut (0.0.0.0/0) injectée par le Serveur de routes Azure, car elles sont plus spécifiques (masques de réseau plus longs). Le diagramme suivant décrit la conception précédente, dans laquelle une passerelle ExpressRoute a été ajoutée.

Pour empêcher les réseaux virtuels spoke d’être programmés avec les préfixes locaux appris par la passerelle VPN et ExpressRoute, vous pouvez désactiver « Propager les itinéraires de passerelle » sur les tables de routage des sous-réseaux spoke. Pour vous assurer que le réseau virtuel vers le trafic local est inspecté par l’appliance virtuelle réseau, vous pouvez configurer un UDR 0.0.0.0/0 (itinéraire défini par l’utilisateur) sur les tables de routage des sous-réseaux spoke avec tronçon suivant en tant qu’appliance virtuelle réseau/pare-feu dans le réseau virtuel hub. Notez que la désactivation de « Propagation des itinéraires de passerelle » empêche ces sous-réseaux spoke d’apprendre dynamiquement des itinéraires à partir du serveur de routage.

Par défaut, le serveur de routes publie aussi tous les préfixes appris de l’appliance virtuelle réseau vers ExpressRoute. Cela peut ne pas être souhaité, par exemple en raison des limites de routage d’ExpressRoute. Dans ce cas, l’appliance virtuelle réseau peut annoncer ses itinéraires vers le serveur de routes, y compris la communauté BGP no-advertise (avec la valeur 65535:65282). Quand le serveur de routes reçoit des itinéraires avec cette communauté BGP, il les injecte dans les sous-réseaux, mais il ne les publie pas auprès d’autres homologues BGP (comme ExpressRoute ou les passerelles VPN, ou autres appliances réseau virtuelles).

Coexistence de SDWAN avec ExpressRoute et le Pare-feu Azure

Un cas particulier de la conception précédente est le moment où les clients insèrent le Pare-feu Azure dans le flux de trafic pour inspecter tout le trafic sur les réseaux locaux, via ExpressRoute ou des appliances SD-WAN/VPN. Dans ce cas, tous les sous-réseaux spoke ont des tables de routage qui empêchent les spokes d’apprendre n’importe quel itinéraire d’ExpressRoute ou du serveur de routage, et ont des itinéraires par défaut (0.0.0.0/0) avec le Pare-feu Azure comme tronçon suivant, comme le montre le diagramme suivant :

Le sous-réseau Pare-feu Azure apprend les itinéraires provenant d’ExpressRoute et de l’appliance virtuelle réseau VPN/SDWAN, et décide si le trafic est envoyé d’une manière ou de l’autre. Comme décrit dans la section précédente, si l’appliance NVA publie plus de 1000 itinéraires vers le serveur de routes, il doit envoyer ses itinéraires BGP marqués avec la communauté BGP no-advertise. De cette façon, les préfixes SDWAN ne sont pas réinjectés localement via ExpressRoute.

Remarque

Pour tout trafic provenant d’un emplacement local destiné aux points de terminaison privés, ce trafic contourne l’appliance virtuelle réseau de pare-feu ou le Pare-feu Azure dans le hub. 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 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.

Symétrie du trafic

Si plusieurs instances d’appliances virtuelles réseau sont utilisées dans le scénario actif/actif afin d’améliorer la résilience ou l’évolutivité, la symétrie du trafic est requise si les appliances virtuelles réseau doivent conserver l’état des connexions. C’est par exemple le cas des pare-feu de nouvelle génération.

• Pour la connectivité des machines virtuelles Azure à l’Internet public, l’appliance virtuelle réseau utilise la traduction d’adresses réseau source (SNAT) afin que le trafic sortant soit issu de l’adresse IP publique de l’appliance virtuelle réseau, ce qui permet d’obtenir une symétrie du trafic.
• Pour le trafic entrant à partir d’Internet vers des charges de travail exécutées sur des machines virtuelles, en plus de la traduction d’adresses réseau de destination (DNAT), les appliances virtuelles réseau requièrent la traduction d’adresses réseau source (SNAT) pour s’assurer que le trafic de retour des machines virtuelles se trouve sur la même instance d’appliance virtuelle réseau qui a traité le premier paquet.
• Pour la connectivité Azure vers Azure, étant donné que la machine virtuelle source prend la décision de routage indépendamment de la destination, la traduction SNAT est nécessaire aujourd’hui pour parvenir à une symétrie du trafic.

Plusieurs instances d’appliances virtuelles réseau peuvent également être déployées dans une installation active/passive, par exemple si l’une d’entre elles publie des routes pires (avec un chemin d’accès plus long) que l’autre. Dans ce cas, le Serveur de routes Azure injecte uniquement la route préférée sur les machines virtuelles du réseau virtuel, et la route la moins préférée est utilisée uniquement lorsque l’instance d’appliance virtuelle réseau principale arrête la publication sur BGP.

Il est également important de noter que le serveur de routage ne prend pas en charge le trafic datapath. Lorsque vous publiez des itinéraires vers le serveur de routage, l’appliance virtuelle réseau doit publier des itinéraires avec le tronçon suivant comme lui-même, un équilibreur de charge devant l’appliance virtuelle réseau ou une appliance virtuelle réseau/pare-feu dans le même réseau virtuel que l’appliance virtuelle réseau.

Contenu connexe

• Apprenez-en davantage sur la prise en charge d’ExpressRoute et du VPN Azure par le Serveur de routes Azure.
• Découvrez comment configurer le peering entre le Serveur de routes Azure et une appliance virtuelle réseau.