Cette page offre un aperçu du point de vue d'un administrateur spoke de cloud privé virtuel (VPC).
Si le hub Network Connectivity Center et le spoke VPC se trouvent dans le même projet, les administrateurs de spoke VPC doivent disposer des deux liaisons Identity and Access Management (IAM) suivantes sur ce projet:
Rôle d'administrateur réseau Compute (
roles/compute.networkAdmin
)Rôle d'administrateur Spoke Network Connectivity Center (
roles/networkconnectivity.spokeAdmin
).
Si le hub Network Connectivity Center et le spoke de VPC se trouvent dans des projets différents, les stratégies IAM doivent disposer des liaisons suivantes.
Les administrateurs de spoke VPC doivent disposer des deux liaisons IAM suivantes sur le projet contenant le réseau VPC (spoke) :
Les administrateurs de spoke VPC doivent également disposer des deux liaisons IAM suivantes sur le hub Network Connectivity Center ou sur le projet contenant le hub Network Connectivity Center:
Vous pouvez également utiliser des rôles personnalisés tant que ces rôles incluent les mêmes autorisations que les rôles prédéfinis répertoriés précédemment.
Lorsqu'un réseau VPC et le hub Network Connectivity Center se trouvent dans des projets différents, un administrateur de spoke VPC doit créer une proposition de spoke pour demander qu'un réseau VPC rejoint le hub. Un administrateur Hub examine la proposition. Si l'administrateur du hub accepte la proposition, le réseau VPC est connecté au hub. Un administrateur hub peut également rejeter les propositions de spoke. Les administrateurs de spoke peuvent vérifier l'état d'une proposition de spoke VPC à tout moment.
Pour plus d'informations, consultez les sections suivantes.
- Proposer un spoke VPC dans un autre projet
- Vérifier l'état d'une proposition de spoke VPC
- Afficher les tables de routage VPC
- Présentation des spokes VPC
Unicité de la route de sous-réseau
Comme pour l'appairage de réseaux VPC, Google Cloud interdit les conflits de plages d'adresses IP de sous-réseau entre les spokes VPC connectés à un hub Network Connectivity Center. Une plage d'adresses IP de sous-réseau entre en conflit avec une autre plage d'adresses IP de sous-réseau lorsque l'une des conditions suivantes est remplie:
- Une plage d'adresses IP de sous-réseau dans un réseau VPC correspond exactement à une plage d'adresses IP de sous-réseau d'un autre réseau VPC.
- Une plage d'adresses IP de sous-réseau dans un réseau VPC se trouve dans une plage d'adresses IP de sous-réseau dans un autre réseau VPC.
- Une plage d'adresses IP de sous-réseau dans un réseau VPC contient une plage d'adresses IP de sous-réseau dans un autre réseau VPC.
Les spokes VPC ne peuvent pas exporter de plages d'adresses IP de sous-réseau en conflit dans le même hub Network Connectivity Center. Vous pouvez utiliser l'option exclude-export-ranges
dans Google Cloud CLI ou le champ excludeExportRanges
de l'API pour empêcher le partage d'une plage d'adresses IP de sous-réseau. à partir d'un spoke VPC vers un hub Network Connectivity Center. Par exemple, supposons que vous disposez de deux réseaux VPC que vous souhaitez connecter au même hub Network Connectivity Center:
- Le premier réseau VPC possède un sous-réseau dont la plage d'adresses IPv4 interne principale est
100.64.0.0/16
, ce qui entraîne une route de sous-réseau pour100.64.0.0/16
. - Le second réseau VPC possède un sous-réseau avec une plage d'adresses IPv4 internes secondaires
100.64.0.0/24
, ce qui entraîne une route de sous-réseau pour100.64.0.0/24
.
Les deux routes de sous-réseau comportent des plages d'adresses IP de sous-réseau en conflit, car 100.64.0.0/24
fait partie de 100.64.0.0/16
. Vous ne pouvez pas connecter les deux réseaux en tant que spokes VPC au même hub Network Connectivity Center, sauf si vous résolvez le conflit. Pour résoudre le conflit, vous pouvez utiliser l'une des stratégies suivantes:
- Excluez la plage d'adresses IP
100.64.0.0/16
lorsque vous associez le premier réseau VPC au hub, ou excluez la plage d'adresses IP100.64.0.0/24
lorsque vous associez le deuxième réseau VPC au hub. - Excluez
100.64.0.0/16
ou l'intégralité de l'espace RFC 6598,100.64.0.0/10
, lorsque vous associez chaque réseau VPC.
Interaction avec les routes de sous-réseau d'appairage de réseau VPC
Les routes d'appairage de sous-réseau sont celles qui sont échangées entre des réseaux VPC connectés à l'aide de l'appairage de réseaux VPC. Même si les routes d'appairage de sous-réseau ne sont jamais échangées entre des spokes VPC connectés à un hub Network Connectivity Center, vous devez toujours prendre en compte les routes d'appairage de sous-réseau. Du point de vue de chaque spoke de VPC, toutes les routes de sous-réseau locales, les routes d'appairage de sous-réseau importées, et les routes de sous-réseau Network Connectivity Center importées ne peuvent pas entrer en conflit.
Pour illustrer ce concept, considérons la configuration suivante:
- Le réseau VPC
net-a
est un spoke VPC connecté à un hub Network Connectivity Center. - Le réseau VPC
net-b
est un spoke VPC connecté au même hub Network Connectivity Center. - Les réseaux VPC
net-b
etnet-c
sont connectés l'un à l'autre à l'aide de l'appairage de réseaux VPC.
Supposons qu'une plage d'adresses IP de sous-réseau locale pour 100.64.0.0/24
existe dans net-c
. Cela crée une route de sous-réseau locale dans net-c
et une route d'appairage de sous-réseau dans net-b
. Même si la route d'appairage de sous-réseau pour la plage d'adresses IP 100.64.0.0/24
n'est pas exportée dans le hub Network Connectivity Center, son existence dans net-b
empêche net-b
d'importer une route Network Connectivity Center dont la destination correspond exactement à 100.64.0.0/24
, fait partie de 100.64.0.0/24
ou contient 100.64.0.0/24
. Par conséquent, aucune route de sous-réseau locale pour 100.64.0.0/24
, 100.64.0.0/25
ou 100.64.0.0/16
ne peut exister dans net-a
à moins de configurer net-a
afin de ne pas exporter la plage en conflit.
Tables de routage affichant les routes de sous-réseau
Google Cloud affiche les routes de sous-réseau Network Connectivity Center importées à partir de spokes VPC dans deux tables de routage:
- La table de routage du hub Network Connectivity Center.
- La table de routage du réseau VPC pour chaque réseau VPC (spoke).
Google Cloud met automatiquement à jour la table de routage du réseau VPC de chaque spoke VPC et la table de routage du hub Network Connectivity Center lorsque l'une des conditions suivantes est remplie:
- Lorsque vous effectuez une activité de cycle de vie des routes de sous-réseau, telle que l'ajout ou la suppression d'un sous-réseau.
- Lorsque des spokes VPC sont ajoutés ou supprimés du hub.
Dans les tables de routage de réseau VPC, chaque route importée à partir d'autres spokes VPC apparaît sous la forme d'une route de sous-réseau Network Connectivity Center dont le saut suivant est le hub Network Connectivity Center. Le nom des routes de sous-réseau de Network Connectivity Center commence par le préfixe ncc-subnet-route-
. Pour afficher le saut suivant d'une route de sous-réseau Network Connectivity Center importée, vous pouvez afficher la table de routage du hub Network Connectivity Center ou afficher la table de routage du réseau VPC du spoke VPC qui exporte la route de sous-réseau dans le hub de Network Connectivity Center.
Pour plus d'informations sur les routes VPC, consultez la section Routes dans la documentation sur les VPC.
Étapes suivantes
- Pour apprendre à créer des hubs et des spokes, consultez la section Travailler avec des hubs et des spokes.
- Pour créer un spoke dans un projet différent du hub, consultez la section Proposer un spoke VPC dans un autre projet.
- Pour afficher la liste des partenaires dont les solutions sont intégrées à Network Connectivity Center, consultez la page Partenaires Network Connectivity Center.
- Pour trouver des solutions aux problèmes courants, consultez la page Dépannage.
- Pour obtenir des détails sur les commandes de l'API et
gcloud
, consultez la section API et documentation de référence.