Partager via


Utiliser Pare-feu Azure pour acheminer une topologie multi hub-and-spoke

La topologie hub-and-spoke est un modèle d’architecture réseau courant dans Azure. Le hub est un réseau virtuel (VNet) dans Azure qui centralise la connectivité à votre réseau local. Les rayons (spokes) sont des réseaux virtuels qui s’homologuent avec le hub et qui peuvent être utilisés pour isoler les charges de travail. Le hub peut être utilisé pour isoler et sécuriser le trafic entre les spokes. Le hub peut également être utilisé pour acheminer le trafic entre les spokes. Le hub peut être utilisé pour acheminer le trafic entre les spokes à l’aide de différentes méthodes.

Par exemple, vous pouvez utiliser le serveur de routes Azure avec le routage dynamique et les appliances virtuelles réseau (NVA) pour acheminer le trafic entre les spokes. Il peut s’agir d’un déploiement assez complexe. Une méthode moins complexe consiste à utiliser des itinéraires statiques et Pare-feu Azure pour acheminer le trafic entre les spokes.

Cet article vous montre comment utiliser Pare-feu Azure avec des itinéraires statiques définis par l’utilisateur (UDR) pour acheminer une topologie multi hub-and-spoke. Le diagramme qui suit montre la topologie :

Schéma conceptuel montrant l’architecture hub-and-spoke.

Architecture de base de référence

Pare-feu Azure sécurise et inspecte le trafic, mais il achemine également le trafic entre les réseaux virtuels. Il s’agit d’une ressource managée qui crée automatiquement des itinéraires système vers les spokes locaux, le hub et les préfixes locaux appris par sa passerelle de réseau virtuel locale. Le fait de placer une appliance virtuelle réseau (NVA) sur le hub et d’interroger les itinéraires effectifs entraînerait une table de routage qui ressemble à ce qui se trouve dans le Pare-feu Azure.

Étant donné qu’il s’agit d’une architecture de routage statique, le chemin d’accès le plus court vers un autre hub peut être obtenu à l’aide du peering de réseau virtuel global entre les hubs. Ainsi, les hubs se connaissent, et chaque pare-feu local contient la table de routage de chaque hub directement connecté. Toutefois, les hubs locaux ne connaissent que leurs spokes locaux. En outre, ces hubs peuvent se trouver dans la même région ou dans une région différente.

Routage sur le sous-réseau du pare-feu

Chaque pare-feu local doit savoir comment atteindre les autres spokes distants. Vous devez donc créer des UDR dans les sous-réseaux du pare-feu. Pour ce faire, vous devez d’abord créer un itinéraire par défaut de n’importe quel type, ce qui vous permet ensuite de créer des itinéraires plus spécifiques vers les autres spokes. Par exemple, les captures d’écran suivantes montrent la table de routage des deux réseaux virtuels hub :

Table de routage Hub-01Capture d’écran montrant la table de routage pour Hub-01.

Table de routage Hub-02Capture d’écran montrant la table de routage pour Hub-02.

Routage sur les sous-réseaux spoke

L’avantage de l’implémentation de cette topologie est qu’avec le trafic passant d’un hub à un autre, vous pouvez atteindre le tronçon suivant qui est directement connecté via le peering global.

Comme illustré dans le diagramme, il est préférable de placer un UDR dans les sous-réseaux spoke qui ont un itinéraire 0/0 (passerelle par défaut) avec le pare-feu local comme tronçon suivant. Cela verrouille l’unique point de sortie du tronçon suivant en tant que pare-feu local. Cela réduit également le risque de routage asymétrique s’il apprend des préfixes plus spécifiques à partir de votre environnement local qui peuvent amener le trafic à contourner le pare-feu. Pour plus d’informations, consultez la rubrique Ne pas laisser vos routes Azure vous mordre.

Voici un exemple de table de routage pour les sous-réseaux spoke connectés à Hub-01 :

Capture d’écran montrant la table de routage pour les sous-réseaux spoke.

Étapes suivantes