Cette rubrique explique comment mettre en œuvre et gérer le modèle en étoile lorsque vous utilisez le service Microsoft AD géré.
Modèle en étoile sur Google Cloud
Le modèle en étoile est une conception réseau dans laquelle l'appareil central, ou hub, est connecté à plusieurs autres appareils, ou spokes. Pour mettre en œuvre cette conception sur Google Cloud, créez un cloud privé virtuel (VPC) connecté à votre réseau sur site via Cloud Interconnect ou Cloud VPN. Le VPC sert de hub. L'appairage de VPC vous permet de créer des connexions à d'autres projets et vos ressources sur site, ou spokes.
Bien que ce modèle fonctionne pour les appairages directs du hub, il ne s'adapte pas aux pairs de pairs. L'appairage de VPC est un échange de routes non transitif et personnalisé qui n'accepte que les routes se propageant vers un pair immédiat, et non entre pairs.
Impact sur le service Microsoft AD géré
Pour assurer la connectivité avec des réseaux autorisés hébergés dans des projets utilisateur, le service Microsoft AD géré utilise l'appairage de VPC avec l'échange de routes activé par défaut. Cela permet la connectivité entre les réseaux autorisés et les projets locataires hébergés par le VPC. Vous pouvez également configurer Cloud Interconnect ou Cloud VPN directement avec un réseau autorisé.
Toutefois, si le réseau autorisé est un spoke ou s'il est appairé à un réseau connecté au réseau sur site, les ressources Microsoft AD gérées ne pourront pas atteindre les ressources sur site, et inversement. Il existe deux solutions possibles pour permettre la connectivité.
Utiliser le VPC partagé
Si possible, utilisez un VPC partagé. Il ne repose pas sur l'appairage et n'est donc pas affecté par les mêmes limitations d'échange de routes.
Utiliser un VPN
Vous pouvez également utiliser un VPN entre le hub et les spokes au lieu de l'appairage de VPC pour contourner la limitation de l'échange de routes.
Figure 1 : Utilisez un VPN pour éviter la limitation de l'échange de routes.
Cette solution est moins idéale, car elle nécessite une planification réseau plus importante et entraîne le surcoût des tunnels VPN. Lorsque vous créez un VPN entre le hub et le spoke, le service Microsoft AD géré est considéré comme un appairage direct du réseau autorisé, et les routes à destination du réseau hub sont exportées. Lorsque vous utilisez cette approche, nous vous recommandons d'utiliser l'appairage DNS entre le réseau autorisé et le hub et les spokes afin que les requêtes DNS puissent être transférées vers le réseau Microsoft AD géré via la configuration réseau autorisée.