Spokes VPC
Network Connectivity Center fournit une connectivité réseau inter-VPC à grande échelle, compatible avec les spokes VPC. L'utilisation des spokes VPC et d'un modèle de gestion centralisée de la connectivité réduit la complexité des opérations de gestion des connexions d'appairage individuelles entre deux réseaux VPC. Les spokes VPC peuvent exporter et importer toutes les routes de sous-réseau à partir d'autres spokes VPC sur un hub Network Connectivity Center. Cela garantit une connectivité complète entre toutes les charges de travail qui se trouvent dans ces réseaux VPC. Le trafic réseau inter-VPC reste sur le réseau Google Cloud et ne passe pas par Internet, ce qui contribue à garantir la confidentialité et la sécurité.
Les spokes VPC peuvent se trouver dans le même projet et la même organisation, ou dans un projet et une organisation différents du hub Network Connectivity Center. Un spoke VPC ne peut être connecté qu'à un seul hub à la fois.
Pour en savoir plus sur la création d'un spoke VPC, consultez la section Créer un spoke VPC.
Comparaison avec l'appairage de réseaux VPC
Les spokes VPC répondent aux exigences des entreprises moyennes et grandes en fournissant une connectivité de routage de sous-réseau IPv4 et IPv6, ainsi qu'une connectivité de routage dynamique IPv4 à l'aide de spokes hybrides.
Un réseau VPC peut être à la fois un spoke Network Connectivity Center et être connecté à un autre réseau VPC à l'aide de l'appairage de réseaux VPC, à condition que le réseau VPC appairé ne soit pas lui-même un spoke VPC.
Gardez à l'esprit les points suivants lorsque vous utilisez les spokes VPC Network Connectivity Center et l'appairage de réseaux VPC:
Les routes de sous-réseau d'appairage d'un spoke VPC ne sont pas exportées vers le hub.
Network Connectivity Center ne fournit pas de connectivité aux ressources d'un réseau VPC connecté à un spoke VPC à l'aide de l'appairage de réseaux VPC, à l'exception de ce qui suit:
- Vous pouvez ajouter un réseau VPC de producteur de services appairé pour l'accès aux services privés en tant que spoke VPC de producteur (aperçu).
Fonctionnalité | Appairage de réseaux VPC | Spokes VPC |
---|---|---|
Réseaux VPC | ||
Plages de sous-réseaux (routes de sous-réseau) | ||
Routes statiques et dynamiques |
Préfixes de route dynamique uniques par table de routage de hub et par région L'échange de route statique n'est pas accepté. |
|
Filtres d'exportation |
Les filtres spécifiques ne sont pas acceptés. Consultez la section Options d'échange de routage dans la documentation sur l'appairage de réseaux VPC. |
Jusqu'à 16 plages CIDR acceptées par spoke VPC. |
Inter-VPC NAT |
Non compatible |
Compatible |
Propagation de connexion Private Service Connect |
Non compatible |
Compatible (bêta) |
Connectivité des spokes VPC de producteur à partir d'autres réseaux VPC |
Non compatible |
Compatible (bêta) |
Adressage IP |
Adresses IPv4 internes, y compris des adresses IPv4 privées et des adresses IPv4 publiques utilisées en mode privé. Consultez la section Plages IPv4 valides. Adresses IPv6 internes et externes |
Adresses IPv4 internes privées uniquement, à l'exception des adresses IPv4 publiques utilisées en mode privé. Consultez la section Plages IPv4 valides. Adresses IPv6 internes et externes (bêta) |
Familles d'adresses IP |
Configurations compatibles :
|
Configurations compatibles :
|
Performances et débit (par rapport à d'autres mécanismes de connectivité VPC) |
Latence la plus faible, débit le plus élevé (équivalent VM à VM) |
Latence la plus faible, débit le plus élevé (équivalent VM à VM) |
Spokes VPC dans un projet différent d'un hub
En utilisant Network Connectivity Center, vous pouvez associer des réseaux VPC, représentés par des spokes VPC, à un seul hub dans un autre projet, y compris un projet d'une autre organisation. Cela vous permet de connecter vos réseaux VPC à plusieurs projets et organisations à grande échelle.
Vous pouvez utiliser les types d'utilisateurs suivants :
- Administrateur de hub propriétaire d'un hub dans un projet
- Un administrateur de spoke dans un réseau VPC ou un administrateur réseau qui souhaite ajouter son réseau VPC dans un autre projet en tant que spoke vers le hub
L'administrateur du hub contrôle qui peut créer un spoke VPC dans un autre projet associé à son hub à l'aide des autorisations IAM (Identity and Access Management). L'administrateur de spoke dans le réseau VPC crée un spoke dans un projet différent du hub. Ces spokes sont inactifs lors de leur création. L'administrateur du hub doit les examiner, et peut accepter ou refuser le spoke. Si l'administrateur du hub accepte le spoke, celui-ci devient actif.
Network Connectivity Center accepte toujours automatiquement les spokes créés dans le même projet que le hub.
Pour en savoir plus sur la gestion des hubs comportant des spokes VPC dans un projet différent du hub, consultez la section Présentation de l'administration de Hub. Pour obtenir des informations détaillées concernant les administrateurs de spoke, consultez la section Présentation de l'administration de Spoke.
Interaction par rayon avec VPC Service Controls
Network Connectivity Center est compatible avec VPC Service Controls pour les spokes inter-projets et inter-organisations. Pour un spoke dans un projet différent du hub, lorsqu'un nouveau périmètre VPC Service Controls est ajouté, vous ne pouvez pas ajouter de spokes qui ne respectent pas le périmètre. Toutefois, les spokes existants que vous avez ajoutés avant d'ajouter le périmètre VPC Service Controls continuent de fonctionner.
Connectivité VPC avec filtres d'exportation
Network Connectivity Center vous permet de limiter la connectivité de tous les spokes de réseaux VPC à un sous-ensemble de sous-réseaux dans le VPC du spoke. Vous pouvez limiter la connectivité comme suit:
- Pour les plages de sous-réseaux IPv4 :
- Vous pouvez configurer le rayon pour qu'il annonce toutes ses plages de sous-réseau IPv4 ou aucune d'entre elles.
- Vous pouvez spécifier des plages d'adresses IPv4 à ne pas annoncer et établir une liste de plages CIDR pouvant être annoncées à partir du réseau VPC. Vous pouvez également ne spécifier qu'une liste de plages CIDR autorisées, ce qui bloque toutes les plages, à l'exception des plages autorisées.
- Pour les plages de sous-réseaux IPv6 (Aperçu) :
- Vous pouvez configurer le rayon pour qu'il annonce toutes ses plages de sous-réseaux IPv6 ou aucune d'entre elles.
Vous pouvez utiliser des filtres d'exportation pour configurer les rayons VPC afin qu'ils n'échangent que des plages de sous-réseaux IPv4, uniquement des plages de sous-réseaux IPv6 ou les deux. Imaginons un spoke dont le réseau VPC combine différents types de piles de sous-réseaux. Si vous configurez le spoke pour n'exporter que des plages de sous-réseaux IPv6, les plages IPv6 des sous-réseaux à double pile et IPv6 uniquement sont échangées, mais les plages de sous-réseaux IPv4 des sous-réseaux à double pile et IPv4 uniquement ne le sont pas.
Exclure des plages d'exportation
Vous pouvez empêcher l'annonce d'une plage d'adresses IPv4 à l'aide de l'option --exclude-export-ranges
dans Google Cloud CLI ou du champ excludeExportRanges
dans l'API. Toutes les plages d'adresses IPv4 correspondant à la plage spécifiée sont exclues de l'exportation vers le hub. Ce filtrage est utile lorsque vous disposez de sous-réseaux qui doivent être privés dans le réseau VPC ou qui sont susceptibles de chevaucher d'autres sous-réseaux de la table de routage du hub.
Inclure les plages d'exportation
Vous pouvez déterminer les plages d'adresses IP autorisées à être annoncées à partir d'un spoke VPC à l'aide de l'option --include-export-ranges
ou du champ includeExportRanges
dans l'API. Vous pouvez spécifier les éléments suivants:
- Pour annoncer toutes les plages de sous-réseaux IPv4, vous pouvez spécifier
ALL_PRIVATE_IPV4_RANGES
. - Pour annoncer uniquement des plages de sous-réseaux IPv4 spécifiques, vous pouvez spécifier une liste de plages CIDR.
- Pour annoncer toutes les plages de sous-réseaux IPv6, vous pouvez spécifier
ALL_IPV6_RANGES
.
Pour les plages d'adresses IPv4, vous pouvez établir une connectivité plus précise lorsque vous utilisez un filtre d'exportation d'inclusion avec le filtre d'exportation d'exclusion. Ce filtrage détermine si une plage de sous-réseau spécifique peut être annoncée à partir du réseau VPC.
Remarques
Tenez compte des points suivants lorsque vous utilisez les filtres d'exportation de plages d'exclusion et d'inclusion :
Les plages d'inclusion doivent être exclusives les unes aux autres, ce qui signifie qu'elles ne doivent pas se chevaucher. Par exemple, supposons qu'il existe trois plages d'adresses IP :
Range 1
:10.100.64.0/18
Range 2
:10.100.250.0/21
Range 3
:10.100.100.0/22
Range 1
etrange 2
sont des plages d'inclusion valides, car elles ne se chevauchent pas. Toutefois,range 3
se trouve sousrange 1
, ce qui peut entraîner un chevauchement.range 3
est donc non valide.Étant donné que Network Connectivity Center dispose déjà de filtres d'exportation d'exclusion disponibles dans la règle de configuration réseau, les filtres d'exportation d'inclusion et d'exclusion affectent les plages CIDR des configurations réseau valides. Lorsque des filtres d'exportation d'inclusion et d'exclusion sont utilisés, les plages d'adresses IP d'inclusion doivent être un sur-ensemble des plages d'adresses IP d'exclusion.
Par défaut, toutes les règles de connectivité VPC ont une plage CIDR d'inclusion
0.0.0.0/0
, ce qui signifie que si vous ne spécifiez pas le filtre d'inclusion lors de la création du spoke VPC, Network Connectivity Center définit la plage d'inclusion par défaut sur toutes les plages d'adresses IP privées IPv4 valides, telles que définies dans la section Plages IPv4 valides.Pour affiner une plage d'inclusion, vous pouvez ajouter plusieurs plages d'exclusion. Par exemple, si vous spécifiez
10.1.0.0/16
en tant que plage d'inclusion et10.1.100.0/24
et10.1.200.0/24
en tant que plages d'exclusion, le résultat est une connectivité affinée avec la combinaison des filtres d'inclusion et d'exclusion. Cette plage inclut tout de10.1.0.0/24
à10.1.99.0/24
, de10.1.101.0/24
à10.1.199.0/24
et de10.1.201.0/24
à10.1.255.0/24
.Les plages de sous-réseaux existantes continuent de fonctionner comme prévu. Les chevauchements avec les plages d'inclusion et d'exclusion lors de la création de plages de sous-réseaux génèrent une erreur.
Exemples de plages de sous-réseaux non valides
Les exemples suivants montrent des plages de sous-réseau non valides:
Chevauchement avec la plage d'exclusion: supposons que les plages d'adresses IP suivantes existent.
Plage d'inclusion :
10.0.0.0/8
Exclude range 4
:10.1.1.0/24
Subnet range 4
:10.1.0.0/16
Dans ce cas, la plage d'inclusion contient
subnet range 4
. Toutefois, il s'agit d'un sur-ensemble deexclude range 4
. Par conséquent,subnet range 4
n'est pas valide.Chevauchement avec la plage d'inclusion : supposons que les plages d'adresses IP suivantes existent.
Plage d'inclusion :
10.1.1.0/24
Subnet range 5
:10.1.0.0/16
Subnet range 5
chevauche la plage d'inclusion. Il n'est donc pas valide.
Lorsque vous saisissez une plage de sous-réseau non valide lors du processus de création du sous-réseau, vous obtenez une erreur Invalid IPCidrRange
semblable à celle-ci :
Invalid IPCidrRange:CIDR_RANGE conflicts with existing subnetworkSUBNET_RANGE in regionREGION
Topologies prédéfinies
Network Connectivity Center vous permet de spécifier la configuration de connectivité souhaitée sur tous les spokes VPC. Vous pouvez choisir l'une des deux topologies prédéfinies suivantes:
- Topologie maillée
- Topologie en étoile
Lorsque vous créez un hub à l'aide de la commande gcloud network-connectivity hubs create
, choisissez la topologie maillée ou en étoile prédéfinie. Si la topologie n'est pas spécifiée, elle est définie par défaut sur "Mesh". Une fois définie lors de la création du hub, vous ne pouvez pas modifier la topologie d'un hub donné.
Pour modifier les paramètres de topologie d'un spoke, vous pouvez le supprimer et créer un spoke avec un nouveau hub qui utilise une topologie différente.
Topologie maillée
La topologie en maillage fournit une connectivité réseau à grande échelle entre les spokes VPC. Cette topologie permet à tous les spokes de se connecter et de communiquer entre eux. Les sous-réseaux de ces spokes VPC sont entièrement accessibles, sauf si vous spécifiez exclude export filters (exclure les filtres d'exportation). Par défaut, lorsque deux ou plusieurs réseaux VPC de charge de travail sont configurés pour joindre un hub Network Connectivity Center en tant que spokes, Network Connectivity Center crée automatiquement un maillage complet de connectivité entre chaque spoke.
Tous les spokes de la topologie du réseau maillé appartiennent à un seul groupe par défaut. La topologie maillée est compatible avec les types de spokes VPC et hybrides.
Le schéma suivant illustre la connectivité de la topologie de maillage dans Network Connectivity Center.

Topologie en étoile
Lorsque vous utilisez la topologie en étoile pour la connectivité, les spokes périphériques et leurs sous-réseaux associés n'atteignent que les spokes centres désignés, tandis que les spokes centres peuvent atteindre tous les autres spokes. Cela permet d'assurer la séparation de la segmentation et de la connectivité entre les réseaux VPC périphériques.
Les spokes VPC pouvant être associés à un hub dans un autre projet, ils peuvent provenir de différents domaines administratifs. Ces spokes situés dans un projet différent du hub peuvent ne pas avoir besoin de communiquer avec tous les autres spokes du hub Network Connectivity Center.
Vous pouvez choisir une topologie en étoile pour les cas d'utilisation suivants:
Charges de travail exécutées dans différents réseaux VPC qui n'ont pas besoin de connectivité entre eux, mais qui ont besoin d'accéder aux réseaux VPC uniquement via le réseau VPC de services partagés central.
Contrôle de la sécurité des communications sur plusieurs réseaux VPC, qui nécessite que le trafic passe par un ensemble d'appliances virtuelles réseau (NVA) centralisées.
Le schéma suivant illustre la connectivité de la topologie en étoile dans Network Connectivity Center.
center-vpc-a
et center-vpc-b
sont associés au groupe central, et edge-vpc-c
et edge-vpc-d
sont associés au groupe périphérique. Dans ce cas, l'utilisation d'une topologie en étoile permet à edge-vpc-c
et edge-vpc-d
d'être connectés à center-vpc-a
et center-vpc-b
, et de propager leurs sous-réseaux au groupe central, mais pas d'être connectés entre eux (pas de connectivité directe entre edge-vpc-c
et edge-vpc-d
). Pendant ce temps, center-vpc-a
et center-vpc-b
sont connectés entre eux, et à la fois à edge-vpc-c
et edge-vpc-d
, ce qui permet une connectivité complète des VPC du groupe central aux VPC du groupe périphérique.

Groupes de spokes
Un groupe de spokes est un sous-ensemble de spokes associés à un hub. Pour configurer Network Connectivity Center à l'aide de la topologie en étoile, vous devez séparer tous les spokes VPC en deux groupes différents, également appelés domaines de routage:
- Un groupe de spokes central qui communiquent entre tous les autres spokes connectés au hub.
- Un groupe périphérique de spokes qui ne communiquent qu'avec les spokes appartenant au groupe central
Un spoke VPC ne peut appartenir qu'à un seul groupe à la fois. Les groupes sont créés automatiquement lorsque vous créez un hub.
Un administrateur de hub peut mettre à jour un groupe de spokes à l'aide de la commande gcloud network-connectivity hubs groups update
. L'administrateur du hub peut ajouter une liste d'ID ou de numéros de projet afin d'activer l'acceptation automatique des spokes. Lorsque l'acceptation automatique est activée, le spoke du projet d'acceptation automatique est automatiquement connecté au hub, sans qu'il soit nécessaire d'examiner chaque proposition de spoke.
Vous pouvez répertorier les groupes centraux et périphériques en tant que ressources imbriquées pour un hub spécifique à l'aide de la commande gcloud network-connectivity hubs groups list --hub
.
Pour les hubs créés avec la topologie de maillage, le résultat renvoie le groupe par défaut.
Pour les hubs créés avec la topologie en étoile, le résultat renvoie des groupes centraux et périphériques.
Pour en savoir plus sur la configuration de la topologie maillée ou en étoile pour vos spokes VPC, consultez la section Configurer un hub.
Limites
Cette section décrit les limites des spokes VPC en général, et lorsqu'ils sont associés à un hub dans un autre projet. Ces limites s'appliquent également aux spokes VPC de producteur (Preview).
Limites des spokes VPC
- Les réseaux VPC peuvent se connecter les uns aux autres de manière exclusive via le hub Network Connectivity Center ou via l'appairage de réseaux VPC.
- Vous ne pouvez pas utiliser l'appairage de réseaux VPC entre deux spokes VPC connectés au même hub Network Connectivity Center. Toutefois, tenez compte des points suivants :
- Un spoke VPC de producteur nécessite une connexion d'appairage à un spoke VPC sur le même hub. La connectivité via Network Connectivity Center n'est pas établie entre le spoke VPC du producteur et son spoke VPC associé.
- Vous pouvez disposer d'un spoke VPC connecté à Network Connectivity Center qui est appairé via l'appairage de réseaux VPC avec un VPC distinct qui ne fait pas partie de Network Connectivity Center.
- Les VPC connectés à l'aide de Network Connectivity Center et de l'appairage de réseaux VPC dans une combinaison ne sont pas transitifs.
- L'échange de routes statiques entre les spokes VPC n'est pas accepté.
- Les routes pointant vers des adresses IP virtuelles d'équilibreur de charge réseau passthrough interne dans d'autres spokes VPC ne sont pas acceptées.
- La mise à jour de
export range filters
après la création du spoke VPC n'est plus possible. - Les équilibreurs de charge réseau passthrough internes basés sur IPv6 ne sont pas accessibles entre les spokes VPC.
- L'échange de routes dynamiques IPv6 n'est pas accepté.
- Les réseaux VPC en mode automatique ne sont pas compatibles en tant que rayons VPC. Vous pouvez passer du mode automatique au réseau VPC personnalisé, qui vous permet de définir manuellement les préfixes de sous-réseau pour chaque région de votre réseau VPC. Une fois la mise à jour effectuée, cette action est irréversible.
Limites de l'échange de routes dynamiques
IPv4 uniquement: Network Connectivity Center n'est compatible qu'avec l'échange de routes dynamiques IPv4. L'échange de routes dynamiques IPv6 n'est pas accepté.
Compatibilité des spokes hybrides avec la topologie en étoile: un hub configuré pour utiliser la topologie en étoile applique les limites suivantes à ses spokes hybrides:
- Les spokes hybrides avec le transfert de données de site à site activé ne sont compatibles qu'avec le groupe de spokes central.
- Les spokes hybrides sans transfert de données de site à site activé peuvent appartenir au groupe de spokes central ou au groupe de spokes de périphérie.
Réseaux VPC de routage qui sont également des spokes VPC : Network Connectivity Center n'est compatible avec deux ou plusieurs réseaux VPC de routage sur le même hub que si aucun d'eux n'est également un spoke VPC. Si un hub Network Connectivity Center ne comporte qu'un seul réseau VPC de routage, ce réseau VPC de routage peut également être un spoke VPC:
Si vous devez mettre à la disposition des réseaux sur site des connexions Private Service Connect propagées via les spokes hybrides du hub, le réseau VPC de routage unique du hub doit également être connecté en tant que spoke VPC.
Si vous n'avez pas besoin de rendre les connexions Private Service Connect propagées disponibles pour les réseaux sur site via les spokes hybrides du hub, nous vous recommandons de ne pas configurer de réseau VPC de routage en tant que spoke VPC afin que le hub puisse prendre en charge au moins deux réseaux VPC de routage.
Règles d'interaction des routes dynamiques: dans un réseau VPC de routage, pour chaque destination de route dynamique unique avec un saut suivant dans un spoke hybride, vous devez vous assurer que toutes les autres routes dynamiques, quelle que soit leur priorité, dont les destinations correspondent exactement ou s'inscrivent dans la destination de route dynamique unique, ont des tunnels Cloud VPN ou des rattachements VLAN de saut suivant également dans un spoke hybride. De plus, vous devez vous assurer que ces spokes hybrides utilisent le même paramètre de transfert de données de site à site (activé ou désactivé).
Si seuls certains sauts suivants pour les routes dynamiques avec une destination commune se trouvent dans des spokes hybrides, Network Connectivity Center ne peut pas échanger de manière fiable les routes dynamiques qui utilisent cette destination avec les spokes VPC du hub. Par conséquent, les spokes VPC peuvent ne pas recevoir ces routes dynamiques.
Network Connectivity Center n'effectue pas d'ECMP parmi tous les prochains sauts des routes dynamiques de spoke hybrides si le transfert de données de site à site est activé pour certains spokes hybrides, mais pas pour d'autres. Si des routes dynamiques avec une destination commune se trouvent dans des spokes hybrides sans paramètres de transfert de données de site à site correspondants, les sauts suivants pour le transfert de données de site à site ou pour la connectivité entre les spokes VPC et les réseaux sur site peuvent ne pas correspondre à vos attentes.
Règles d'interaction entre les routes dynamiques et les routes statiques: dans un réseau VPC de routage, pour chaque destination de route dynamique unique qui possède un saut suivant dans un spoke hybride, vous devez vous assurer qu'aucune route statique locale n'existe, quelle que soit la priorité, dont les destinations correspondent exactement ou s'inscrivent dans la destination de la route dynamique.
Si une route statique locale du réseau VPC de routage a la même destination qu'une route dynamique de spoke hybride, les spokes VPC peuvent perdre la connectivité avec la destination de la route dynamique.
Si une route statique locale dans un réseau VPC de routage a une destination qui correspond à celle d'une route dynamique de spoke hybride, les spokes VPC perdent la connectivité avec la destination de la route statique.
Période d'attente après la suppression d'un spoke VPC
Pour un nouveau spoke pour le même réseau VPC associé à un autre hub, la période d'attente à respecter est d'au moins 10 minutes. Si la période d'attente n'est pas respectée, la nouvelle configuration peut ne pas prendre effet. Cette période d'attente n'est pas nécessaire si le réseau VPC est ajouté en tant que spoke au même hub.
Quotas et limites
Lorsque vous utilisez l'échange de routes dynamiques, surveillez attentivement votre utilisation du nombre de routes dynamiques par hub. Ce quota comptabilise l'utilisation par destination (préfixe) uniquement, sans tenir compte de la priorité ni du prochain saut d'une route dynamique. Lorsque l'utilisation de ce quota dépasse sa limite, Network Connectivity Center supprime les routes par destination. Si une destination est supprimée, toutes les routes dynamiques avec cette destination (quelle que soit la priorité ou le saut suivant) ne sont plus envoyées au hub.
Pour obtenir des informations détaillées sur les quotas, consultez la page Quotas et limites.
Facturation
Heures spoke
Les heures spoke sont facturées en fonction du projet dans lequel réside la ressource de spoke et suit les tarifs des heures de spoke standards. Les heures spoke ne sont facturées que lorsque le spoke est à l'état ACTIVE
.
Trafic sortant
Le trafic de sortie est facturé dans le projet de la ressource spoke d'où provient le trafic. Le prix est le même, que le trafic dépasse les limites du projet ou non.
Contrat de niveau de service
Pour en savoir plus sur le contrat de niveau de service de Network Connectivity Center, consultez le Contrat de niveau de service de Network Connectivity Center.
Tarifs
Pour en savoir plus sur les tarifs, consultez la page Tarifs du Network Connectivity Center.
Étapes suivantes
- Apprenez à créer des hubs et des spokes en consultant la section Utiliser des hubs et des spokes.
- 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.