Présentation des spokes VPC

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. Ils exportent et importent les routes de sous-réseau IPv4 vers/depuis d'autres spokes Cela garantit une connectivité IPv4 complète entre toutes les charges de travail qui se trouvent dans ces réseaux VPC. Le trafic réseau inter-VPC reste à l'intérieur du réseau Google Cloud et ne transite 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. Les spokes VPC peuvent être connectés à un 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 sont conçus pour répondre aux exigences de charge de travail moyenne à grande des entreprises pour la connectivité acheminée entre les plages de sous-réseaux IPv4 situées dans de nombreux réseaux VPC distincts.

Un réseau VPC peut être à la fois un spoke Network Connectivity Center et être connecté à d'autres réseaux VPC à l'aide de l'appairage de réseaux VPC. Les routes d'appairage de sous-réseau que le réseau VPC spoke importe à l'aide de l'appairage de réseaux VPC ne sont pas partagées avec d'autres spokes VPC connectés au hub Network Connectivity Center. Par conséquent, les services gérés basés sur l'accès aux services privés ne sont pas accessibles de manière transitoire via les autres spokes VPC d'un hub Network Connectivity Center. Dans ce cas, vous pouvez rendre le service géré accessible à l'aide d'un spoke VPC de producteur (Preview).

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.

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é en spécifiant des plages d'adresses IP à annoncer et en établissant une liste de plages CIDR pouvant être annoncées à partir du réseau VPC. Vous pouvez également limiter la connectivité en spécifiant une liste de plages CIDR autorisées, ce qui bloque toutes les plages, à l'exception des plages autorisées.

Exclure des plages d'exportation

Vous pouvez empêcher l'annonce d'une plage d'adresses IP à l'aide de l'option --exclude-export-ranges dans Google Cloud CLI ou du champ excludeExportRanges dans l'API. Tous les sous-réseaux correspondant à la plage spécifiée sont exclus 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 établir une liste de plages CIDR 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. Une connectivité plus précise est établie lorsque vous l'utilisez avec la plage d'adresses IP du 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 et range 2 sont des plages d'inclusion valides, car elles ne se chevauchent pas. Toutefois, range 3 se trouve sous range 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 et 10.1.100.0/24 et 10.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 de 10.1.0.0/24 à 10.1.99.0/24, de 10.1.101.0/24 à 10.1.199.0/24 et de 10.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 de exclude 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 IPCiderRange semblable à celle-ci :

Invalid IPCidrRange: CIDR_RANGE conflicts with existing subnetwork SUBNET_RANGE in region REGION

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

La topologie en étoile n'est compatible qu'avec les spokes VPC. 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 le cas d'utilisation suivant :

• 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:

1. Un groupe de spokes central qui communiquent entre tous les autres spokes connectés au hub.
2. 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 de 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 IPv4 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.
• Les sous-réseaux qui se chevauchent doivent être masqués par des filtres d'exportation d'exclusion.
• La mise à jour de export range filters après la création du spoke VPC n'est plus possible.
• 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, mais les spokes existants continuent de fonctionner.
• La connectivité en topologie en étoile n'est compatible ni avec les spokes hybrides, ni avec l'échange de routes dynamiques.

Exigences de 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

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.