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

Avec le serveur de routes 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.

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.

Vous ne pouvez pas configurer les sous-réseaux dans les réseaux virtuels spoke pour apprendre uniquement les routes auprès du Serveur de routes Azure. La désactivation de l’option « Propager les routes de la passerelle » dans une table de routage associée à un sous-réseau empêche les deux types de routes (routes de la passerelle de réseau virtuel et routes du Serveur de routes Azure) d’être injectées sur les cartes réseau de ce sous-réseau.

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 d’itinéraire d’ExpressRoute ou du serveur de routage lui-même. 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 200 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.

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.

Différents serveurs de routage pour publier les itinéraires menant aux passerelles de réseau virtuel et aux réseaux virtuels

Comme indiqué dans les sections précédentes, le rôle du Serveur de routes Azure est double :

• Il apprend et publie les itinéraires à destination/en provenance des passerelles de réseau virtuel (VPN et ExpressRoute)
• Il configure les routes apprises sur son réseau virtuel et sur les réseaux virtuels directement appairés

Cette double fonctionnalité est souvent intéressante, mais elle peut parfois aller à l’encontre de certaines exigences. Par exemple, si le Serveur de routes est déployé dans un réseau virtuel avec une appliance virtuelle réseau qui publie un itinéraire 0.0.0.0/0 et une passerelle ExpressRoute qui publie des préfixes de sites locaux, il configure tous les itinéraires (aussi bien l’itinéraire 0.0.0.0/0 de l’appliance virtuelle réseau que les préfixes locaux) sur les machines virtuelles de son réseau virtuel et des réseaux virtuels directement appairés. Par conséquent, comme les préfixes locaux sont plus précis que l’itinéraire 0.0.0.0.0/0, le trafic entre les sites locaux et Azure contourne l’appliance virtuelle réseau. Si ce contournement n’est pas souhaité, les sections précédentes de cet article expliquent comment désactiver la propagation BGP dans les sous-réseaux de machines virtuelles et comment configurer des routes définies par l’utilisateur (UDR).

Cependant, il existe une autre approche plus dynamique. Plusieurs instances du Serveur de routes Azure peuvent être utilisées afin de bénéficier de différentes fonctionnalités : l’une d’elles sera chargée d’interagir avec les passerelles de réseau virtuel, et l’autre d’interagir avec le routage du réseau virtuel. Le diagramme suivant illustre une conception possible :

Le Serveur de routes Azure 1 du hub est utilisé pour injecter les préfixes de SDWAN dans ExpressRoute. Étant donné que les réseaux virtuels spoke sont appairés au réseau virtuel hub sans Utiliser la passerelle ou le serveur de routes du réseau virtuel distant (dans le peering de réseaux virtuels spoke) et Utiliser la passerelle ou le serveur de routes de ce réseau virtuel (transit par passerelle dans le peering de réseau virtuel hub), les réseaux virtuels spoke n’apprennent pas ces itinéraires (ni les préfixes SDWAN ni les préfixes ExpressRoute).

Pour propager des routes sur les réseaux virtuels spoke, l’appliance virtuelle réseau utilise une le Serveur de routes Azure 2, déployé dans un nouveau réseau virtuel auxiliaire. L’appliance virtuelle réseau ne propage qu’un seul itinéraire 0.0.0.0/0 vers le Serveur de routes Azure 2. Étant donné que les réseaux virtuels spoke sont appairés avec ce réseau virtuel auxiliaire avec Utiliser la passerelle ou le serveur de routes du réseau virtuel distant (dans le peering de réseau virtuel spoke) et Utiliser la passerelle ou le serveur de routes de ce réseau virtuel (transit par passerelle dans le peering de réseau virtuel hub), l’itinéraire 0.0.0.0/0 est appris par toutes les machines virtuelles dans les spokes.

Notez que le tronçon suivant de cette route 0.0.0.0/0 est l’appliance virtuelle réseau. Par conséquent, les réseaux virtuels spoke doivent toujours être appairés au réseau virtuel hub. Autre aspect important, le réseau virtuel hub doit être appairé au réseau virtuel dans lequel le Serveur de routes Azure 2 est déployé, sinon il ne peut pas créer la contiguïté BGP.

Si le trafic d’ExpressRoute vers les réseaux virtuels spoke doit être envoyé à une appliance virtuelle réseau de pare-feu à des fins d’inspection, une table de routage dans GatewaySubnet est toujours requise. Sinon, la passerelle de réseau virtuel ExpressRoute envoie des paquets aux machines virtuelles via les itinéraires appris par le peering de réseau virtuel. Les itinéraires de cette table de routage doivent correspondre aux préfixes spoke, et le tronçon suivant doit être l’adresse IP de l’appliance virtuelle réseau de pare-feu (ou l’équilibreur de charge devant les appliances virtuelles réseau de pare-feu, pour la redondance). L’appliance virtuelle réseau de pare-feu peut être identique à l’appliance virtuelle réseau SDWAN dans le diagramme ci-dessus, ou il peut s’agir d’un autre appareil, comme Pare-feu Azure, car l’appliance virtuelle réseau SDWAN peut publier des itinéraires avec le tronçon suivant pointant vers d’autres adresses IP. Le diagramme suivant illustre cette conception avec l’ajout de Pare-feu Azure :

Cette conception permet l’injection automatique de routes dans des réseaux virtuels spoke sans aucune interférence avec les autres routes apprises auprès d’ExpressRoute, d’un VPN ou d’un environnement SDWAN, et l’ajout de NVAs de pare-feu pour l’inspection du trafic.

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.