Appairage de réseaux VPC

L'appairage de réseaux VPC Google Cloud connecte deux réseaux de cloud privé virtuel (VPC) afin que les ressources de chaque réseau puissent communiquer entre elles. Les réseaux VPC appairés peuvent appartenir au même projet, à différents projets de la même organisation ou à différents projets de plusieurs organisations.

Spécifications

La fonction d'appairage de réseaux VPC vous permet d'effectuer les opérations suivantes :

Connectivité

  • L'appairage de réseaux VPC accepte la connexion de réseaux VPC, mais pas d'anciens réseaux.
  • L'appairage de réseaux VPC offre une connectivité IPv4 et IPv6 interne entre les paires de réseaux VPC. Le trafic d'appairage (entre réseaux appairés) présente le même temps de latence, le même débit et la même disponibilité que le trafic au sein du même réseau VPC.
    • L'appairage de réseaux VPC n'assure pas de routage transitif. Par exemple, si les réseaux VPC net-a et net-b sont connectés à l'aide de l'appairage de réseaux VPC, et si les réseaux VPC net-a et net-c sont également connectés à l'aide de l'appairage de réseaux VPC, l'appairage de réseaux VPC ne fournit pas de connectivité entre net-b et net-c.
    • Vous ne pouvez pas connecter deux réseaux VPC en mode automatique à l'aide de l'appairage de réseaux VPC. En effet, les réseaux VPC appairés échangent toujours des routes de sous-réseau qui utilisent des adresses IPv4 internes privées et chaque sous-réseau d'un réseau VPC en mode automatique utilise une plage d'adresses IP de sous-réseau située dans le bloc CIDR 10.128.0.0/9.
    • Vous pouvez connecter un réseau VPC en mode personnalisé à un réseau VPC en mode automatique tant que le réseau VPC en mode personnalisé ne comporte aucune plage d'adresses IP de sous-réseau située dans le bloc 10.128.0.0/9.
  • L'appairage de réseaux VPC fournit également une certaine connectivité IPv6 externe avec les plages d'adresses IPv6 externes de destination associées aux ressources suivantes, lorsque les routes vers ces adresses IPv6 externes de destination sont échangées par l'appairage de réseaux VPC :
    • Interfaces réseau d'instances de machines virtuelles (VM) à double pile
    • Règles de transfert pour le transfert de protocole externe
    • Règles de pare-feu pour les équilibreurs de charge réseau passthrough externes
  • L'appairage de réseaux VPC est compatible avec les connectivités IPv4 et IPv6. Vous pouvez configurer l'appairage de réseaux VPC sur un réseau VPC contenant des sous-réseaux à double pile.

Administration

  • Les réseaux VPC appairés restent administrativement distincts. Seules les routes sont échangées, en fonction de la configuration d'appairage.
  • Pour établir une connectivité d'appairage, un administrateur réseau de chaque réseau VPC doit créer une connexion d'appairage à l'autre réseau VPC. Un administrateur réseau de l'un ou l'autre des réseaux VPC peut mettre fin à une connexion d'appairage.
  • Chaque côté d'une association d'appairage est configuré indépendamment. L'appairage ne devient actif que lorsque les configurations des deux côtés correspondent. Chaque côté peut supprimer l'association d'appairage à tout moment.
  • La création d'une connexion d'appairage ne vous attribue aucun rôle IAM (Identity and Access Management) sur l'autre réseau VPC. Par exemple, si vous disposez du rôle "Administrateur de réseaux Compute" ou "Administrateur de sécurité Compute" sur un réseau, vous ne devenez pas administrateur réseau ou administrateur de sécurité sur l'autre réseau.

Autorisations IAM

  • Les autorisations IAM pour la création et la suppression d'appairages de réseaux VPC sont incluses dans le rôle Administrateur de réseaux Compute (roles/compute.networkAdmin).
  • Vous pouvez utiliser un rôle personnalisé s'il inclut les autorisations suivantes :
    • compute.networks.addPeering
    • compute.networks.updatePeering
    • compute.networks.removePeering
    • compute.networks.listPeeringRoutes

Sécurité du réseau

L'appairage de réseaux VPC n'échange pas de règles de pare-feu VPC ni de stratégies de pare-feu.

Pour les règles de pare-feu VPC :

  • Les règles de pare-feu dont les cibles sont définies à l'aide de tags réseau ne sont résolues qu'en instances du réseau VPC de la règle de pare-feu. Même si un administrateur de sécurité d'un réseau VPC appairé peut utiliser le même tag réseau pour définir des cibles de règles de pare-feu dans un réseau VPC appairé, les cibles des règles de pare-feu du VPC appairé n'incluent pas d'instances dans votre réseau VPC. De même, les règles de pare-feu d'entrée dont les sources sont définies à l'aide de tags réseau ne sont résolues qu'en instances du réseau VPC de la règle de pare-feu.

  • Les règles de pare-feu dont les cibles sont définies à l'aide de comptes de service ne sont résolues qu'en instances du réseau VPC de la règle de pare-feu. Sous réserve des autorisations IAM, un administrateur de sécurité d'un réseau VPC appairé pourrait éventuellement utiliser le même compte de service pour définir des cibles de règles de pare-feu dans un réseau VPC appairé, mais les cibles des règles de pare-feu dans le réseau VPC appairé n'incluent pas d'instances de votre réseau VPC. De même, les règles de pare-feu d'entrée dont les sources sont définies à l'aide de comptes de service ne sont résolues qu'en instances du réseau VPC de la règle de pare-feu.

Les règles des stratégies de pare-feu réseau peuvent utiliser des tags sécurisés, différents des tags réseau, pour identifier les cibles et les sources :

  • Lorsqu'il est utilisé pour spécifier une cible pour une règle d'entrée ou de sortie dans une stratégie de pare-feu de réseau, un tag ne peut identifier que les cibles du réseau VPC auquel le tag est associé.

  • Lorsqu'il est utilisé pour spécifier une source pour une règle d'entrée dans une stratégie de pare-feu de réseau, un tag peut identifier des sources dans le réseau VPC auquel le tag est associé, ainsi que dans tous les réseaux VPC appairés connectés sur le réseau VPC auquel le tag est associé. Pour en savoir plus, consultez la section Balises pour les pare-feu.

Chaque réseau VPC contient des règles de pare-feu implicites. En raison de règles de pare-feu implicites interdisant les entrées, les administrateurs de sécurité de chaque réseau VPC doivent créer des règles de pare-feu autorisant les entrées ou des règles dans des stratégies de pare-feu. Les sources de ces règles peuvent inclure des plages d'adresses IP d'un réseau VPC appairé.

En raison des règles de pare-feu implicites autorisant le trafic sortant, vous n'avez pas besoin de créer de règles de pare-feu autorisant le trafic sortant ni de règles dans les stratégies de pare-feu pour autoriser les paquets vers des destinations du réseau VPC appairé, sauf si vos réseaux incluent des règles de refus du trafic sortant.

Compatibilité DNS

Les ressources d'un réseau VPC appairé ne peuvent pas utiliser les noms DNS internes de Compute Engine créés par un réseau VPC local.

Un réseau VPC appairé ne peut pas utiliser de zones privées gérées Cloud DNS qui ne sont autorisées que pour un réseau VPC local. Pour que les noms DNS soient disponibles pour les ressources d'un réseau VPC appairé, utilisez l'une des techniques suivantes :

Compatibilité avec les équilibreurs de charge internes

Les clients d'un réseau VPC local peuvent accéder aux équilibreurs de charge d'application internes dans un réseau VPC appairé. Pour plus d'informations, consultez les sections Utiliser l'appairage de réseaux VPC de la documentation de l'équilibreur de charge suivante :

Les réseaux appairés peuvent échanger des routes statiques qui utilisent des équilibreurs de charge réseau passthrough internes comme prochains sauts. Pour en savoir plus, consultez la section Options d'échange de routes.

Groupe d'appairage et quotas

Les quotas relatifs à l'appairage de VPC dépendent d'un concept appelé groupe d'appairage. Chaque réseau VPC possède son propre groupe d'appairage composé de lui-même et de tous les autres réseaux VPC qui y sont connectés via l'appairage de réseaux VPC. Dans le scénario le plus simple, si deux réseaux VPC net-a et net-b sont appairés, il existe deux groupes d'appairage : l'un du point de vue de net-a et l'autre du point de vue de net-b.

Pour en savoir plus sur les quotas d'appairage de réseaux VPC, consultez les pages suivantes :

Limites

L'appairage de réseaux VPC offre les spécifications suivantes.

Les plages d'adresses IP des sous-réseaux ne peuvent pas se chevaucher sur les réseaux VPC appairés

Aucune plage d'adresses IP de sous-réseau ne peut en chevaucher une autre dans un réseau VPC appairé. Lors de l'appairage, Google Cloud vérifie s'il existe des sous-réseaux comportant des plages d'adresses IP qui se chevauchent. Si oui, l'appairage échoue. Dans le cas d'un réseau appairé, si vous essayez de créer un sous-réseau VPC ou d'étendre une plage d'adresses IP de sous-réseau, Google Cloud vérifie que les nouvelles plages de sous-réseaux ne chevauchent pas les plages existantes.

Avant de créer de nouveaux sous-réseaux, vous pouvez répertorier les routes provenant des connexions d'appairage.

Pour en savoir plus sur les vérifications de chevauchement, consultez les pages suivantes :

Les noms DNS internes ne sont pas résolus dans les réseaux appairés

Les noms de DNS internes à Compute Engine créés dans un réseau ne sont pas accessibles aux réseaux appairés. Pour atteindre les instances de VM dans le réseau appairé, utilisez l'adresse IP de la VM.

Les tags et les comptes de service ne peuvent pas être utilisés sur des réseaux appairés

Vous ne pouvez pas référencer un tag ou un compte de service concernant une VM d'un réseau appairé dans une règle de pare-feu de l'autre réseau appairé. Par exemple, si une règle d'entrée dans un réseau appairé filtre sa source en fonction d'un tag, elle autorise uniquement le trafic de VM provenant de ce réseau, et non de ses pairs, même Si une VM d'un réseau appairé possède ce tag. Cette situation se produit de manière similaire pour les comptes de service.

GKE et appairage de réseaux VPC

L'appairage de réseaux VPC est compatible avec GKE lorsqu'il est utilisé avec des alias d'adresses IP et des routes personnalisées. Les services Kubernetes (s'ils sont exposés via un équilibreur de charge réseau interne passthrough) et les adresses IP de pods sont accessibles sur les réseaux VPC.

Cloud Load Balancing avec appairage de réseaux VPC

Cloud Load Balancing ne permet pas de configurer les interfaces et les backends de l'équilibreur de charge dans différents réseaux VPC, même s'ils sont appairés avec l'appairage de réseaux VPC.

Les équilibreurs de charge réseau internes à stratégie directe et les équilibreurs de charge d'application internes n'acceptent l'appairage de réseaux VPC que pour l'accès client depuis le réseau VPC appairé.

Options d'échange de routes

Lorsqu'un réseau VPC partage des routes locales avec un réseau VPC appairé, il les exporte. Le réseau VPC appairé peut ensuite importer les routes. Les routes de sous-réseau, à l'exception des routes IPv4 utilisant des adresses IPv4 publiques en mode privé, sont toujours échangées.

La configuration de l'appairage de réseaux VPC vous permet de contrôler :

  • si les routes IPv6 sont échangées ;
  • si les routes des sous-réseaux utilisant des adresses IPv4 publiques en mode privé sont exportées ou importées ;
  • si les routes statiques et dynamiques sont exportées ou importées.

Vous pouvez mettre à jour la configuration avant d'effectuer l'appairage ou pendant que la connectivité d'appairage est active.

L'appairage de réseaux VPC n'offre pas :

  • de méthode précise permettant de contrôler l'échange de routes spécifiques (routes de sous-réseau, routes statiques et routes dynamiques) ;
  • la possibilité d'échanger des routes basées sur des règles.

Options d'échange des routes de sous-réseau

Le tableau suivant décrit les options d'échange des routes de sous-réseau :

Type de route Conditions d'exportation des routes Conditions d'importation des routes
Routes de sous-réseau IPv4 (plages de sous-réseaux IPv4 principales et secondaires) utilisant des plages d'adresses IPv4 privées Toujours exportées

Impossible à désactiver		 Toujours importées

Impossible à désactiver
Routes de sous-réseau IPv4 (plages de sous-réseaux IPv4 principales et secondaires) utilisant des plages d'adresses IPv4 publiques utilisées en mode privé Exportées par défaut

L'exportation est contrôlée à l'aide de l'option --export-subnet-routes-with-public-ip 		Non importées par défaut

L'importation est contrôlée à l'aide de l'option --import-subnet-routes-with-public-ip
Plages de sous-réseaux IPv6 internes
(ipv6-access-type=INTERNAL) 		Non exportées par défaut

L'exportation est activée en définissant --stack-type=IPV4_IPV6 		Non importées par défaut

L'importation est activée en définissant --stack-type=IPV4_IPV6
Plages de sous-réseaux IPv6 externes
(ipv6-access-type=EXTERNAL) 		Non exportées par défaut

L'exportation est activée en définissant --stack-type=IPV4_IPV6 		Non importées par défaut

L'importation est activée en définissant --stack-type=IPV4_IPV6

Options d'échange des routes statiques

Le tableau suivant décrit les options d'échange des routes statiques.

Type de route Conditions d'exportation des routes Conditions d'importation des routes
Routes statiques personnalisées avec des tags réseau (tous les types de prochains sauts) Impossible à exporter Impossible à importer
Les routes statiques qui utilisent le prochain saut de la passerelle Internet par défaut Impossible à exporter Impossible à importer
Les routes statiques IPv4, sans tags réseau, qui utilisent un prochain saut différent de la passerelle Internet par défaut Non exportées par défaut

L'exportation est contrôlée à l'aide de l'option --export-custom-routes 		Non importées par défaut

L'importation est contrôlée à l'aide de l'option --import-custom-routes
Routes statiques IPv6 personnalisées (sans tags réseau) utilisant une instance de VM comme prochain saut Non exportées par défaut

L'exportation est contrôlée à l'aide de l'option --export-custom-routes lorsque le type de pile de l'appairage est défini sur --stack-type=IPV4_IPV6 		Non importées par défaut

L'importation est contrôlée à l'aide de l'option --import-custom-routes lorsque le type de pile de l'appairage est défini sur --stack-type=IPV4_IPV6

Options d'échange des routes dynamiques

Le tableau suivant décrit les options d'échange des routes dynamiques :

Type de route Conditions d'exportation des routes Conditions d'importation des routes
Routes IPv4 dynamiques Non exportées par défaut

L'exportation est contrôlée à l'aide de l'option --export-custom-routes 		Non importées par défaut

L'importation est contrôlée à l'aide de l'option --import-custom-routes
Routes IPv6 dynamiques Non exportées par défaut

L'exportation est contrôlée à l'aide de l'option --export-custom-routes lorsque le type de pile de l'appairage est défini sur --stack-type=IPV4_IPV6 		Non importées par défaut

L'importation est contrôlée à l'aide de l'option --import-custom-routes lorsque le type de pile de l'appairage est défini sur --stack-type=IPV4_IPV6

Avantages de l'échange de routes statiques et dynamiques

Lorsqu'un réseau VPC exporte des routes statiques et dynamiques et que l'autre les importe, le réseau d'importation peut envoyer des paquets directement au prochain saut pour chaque route statique ou dynamique importée dont le prochain saut se trouve dans le réseau VPC appairé.

L'administrateur réseau d'un réseau VPC local contrôle l'exportation conjointe des routes statiques et dynamiques de ce réseau à l'aide de l'option --export-custom-routes. Un administrateur réseau du réseau VPC appairé correspondant contrôle l'importation de ces routes statiques et dynamiques à l'aide de l'option --import-custom-routes. Pour en savoir plus, consultez Routes ignorées, Interactions des routes de sous-réseau et des routes d'appairage de sous-réseau et Interactions des routes de sous-réseau et des routes statiques.

L'importation de routes statiques et dynamiques à partir d'un réseau VPC appairé peut être utile dans les scénarios suivants :

  • Si le réseau VPC appairé contient des clusters GKE basés sur des routes et que vous devez envoyer des paquets aux pods de ces clusters. Les adresses IP des pods sont implémentées en tant que plages de destination pour les routes statiques situées dans le réseau VPC appairé.
  • Si vous devez fournir une connectivité entre un réseau sur site et un réseau VPC appairé. Supposons qu'un réseau VPC local contienne des routes dynamiques avec un tunnel Cloud VPN de prochain saut, un rattachement Cloud Interconnect (VLAN) ou un dispositif de routeur qui se connecte à un réseau sur site. Pour fournir un chemin d'accès du réseau VPC appairé vers le réseau sur site, un administrateur réseau du réseau VPC local active l'exportation de routes personnalisées et un administrateur réseau du réseau VPC appairé active l'importation de routes personnalisées. Pour fournir un chemin d'accès du réseau sur site vers le réseau VPC appairé, un administrateur réseau du réseau VPC local doit utiliser des annonces de routage Cloud Router personnalisées sur le routeur Cloud qui gère la session BGP pour le tunnel Cloud VPN, le rattachement Cloud Interconnect (VLAN) ou l'appareil de routeur qui se connecte au réseau sur site. Le contenu de ces annonces de route personnalisées doit inclure les plages d'adresses IP de sous-réseau du réseau VPC appairé.

Routes ignorées

Même lorsqu'un réseau VPC importe une route, il peut ignorer la route importée dans les situations suivantes :

  • Lorsque le réseau VPC local dispose d'une route avec une destination identique ou plus spécifique (masque de sous-réseau plus long), il utilise toujours sa route locale.

  • Lorsque le réseau VPC local ne contient pas la route la plus spécifique pour la destination d'un paquet, mais qu'au moins deux réseaux VPC appairés contiennent la même destination la plus spécifique pour le paquet, Google Cloud utilise un algorithme interne pour sélectionner un saut suivant depuis l'un des réseaux VPC appairés. Cette sélection a lieu avant que la priorité de la route ne soit prise en compte. Vous ne pouvez pas configurer ce comportement. Nous vous recommandons d'éviter cette configuration, car l'ajout ou la suppression de réseaux VPC appairés peut entraîner des modifications inattendues dans l'ordre de routage.

Pour en savoir plus sur les situations précédentes, consultez la section Ordre de routage.

Pour les appairages à double pile, si un réseau VPC local important des routes IPv6 ne possède pas de sous-réseaux à double pile, aucune des routes IPv6 qu'il reçoit de réseaux VPC appairés ne peut être utilisée. En outre, si la contrainte de règle d'administration constraints/compute.disableAllIpv6 a été définie, un administrateur réseau risque de ne pas pouvoir créer de sous-réseaux à double pile.

Interactions des routes de sous-réseau et des routes d'appairage de sous-réseau

Les routes de sous-réseau IPv4 des réseaux VPC appairés ne peuvent pas se chevaucher :

  • L'appairage interdit les routes de sous-réseau IPv4 identiques. Par exemple, deux réseaux VPC appairés ne peuvent pas tous les deux disposer d'une route de sous-réseau IPv4 dont la destination est 100.64.0.0/10.
  • L'appairage interdit qu'une route de sous-réseau se trouve dans une route d'appairage de sous-réseau. Par exemple, si le réseau VPC local dispose d'une route de sous-réseau dont la destination est 100.64.0.0/24, aucun des réseaux VPC appairés ne peut avoir de route de sous-réseau dont la destination est 100.64.0.0/10.

Google Cloud applique les conditions précédentes aux routes de sous-réseau IPv4 dans les cas suivants :

  • Lorsque vous vous connectez à des réseaux VPC pour la première fois à l'aide de l'appairage de réseaux VPC.
  • Pendant l'appairage des réseaux.
  • Lorsque vous modifiez la configuration d'appairage, par exemple en activant l'importation de routes de sous-réseau IPv4 disposant d'adresses IP publiques utilisées en mode privé.

Pendant que vous appairez des réseaux, Google Cloud renvoie une erreur si l'une des opérations suivantes entraîne un chevauchement :

Les routes de sous-réseau IPv6 (internes et externes) sont uniques par définition. Deux réseaux VPC ne peuvent pas utiliser les mêmes plages de sous-réseaux IPv6 internes ou externes. Par exemple, si un réseau VPC utilise fc:1000:1000:1000::/64 comme plage de sous-réseau IPv6, aucun autre réseau VPC dans Google Cloud ne peut utiliser fc:1000:1000:1000::/64, que les réseaux VPC soient connectés via l'appairage de réseaux VPC ou non.

Interactions des routes de sous-réseau et des routes statiques

Google Cloud exige que les routes de sous-réseau et les routes d'appairage de sous-réseau possèdent les plages d'adresses IPv4 ou IPv6 de destination les plus spécifiques. Dans un réseau VPC, une route statique locale ne peut pas avoir de destination correspondant exactement à une route de sous-réseau locale ou comprise dedans. Pour en savoir plus sur ce scénario, consultez la section Interactions avec les routes statiques.

Ce concept est étendu à l'appairage de réseaux VPC selon les deux règles suivantes :

  • Une route statique locale ne peut pas avoir de destination correspondant exactement à une route d'appairage de sous-réseau ou comprise dedans. Si une route statique locale existe, Google Cloud applique les principes suivants :

    • Vous ne pouvez pas établir de nouvelle connexion d'appairage à un réseau VPC qui contient déjà une route de sous-réseau correspondant exactement à la destination de la route statique locale, ou s'inscrivant dans celle-ci, si la configuration d'appairage entraîne l'importation de la route de sous-réseau en conflit. Exemple :

      • S'il existe une route statique locale dont la destination est 10.0.0.0/24, vous ne pouvez pas établir de nouvelle connexion d'appairage à un réseau VPC contenant une route de sous-réseau IPv4 dont la destination correspond exactement à 10.0.0.0/24 ou s'inscrit dans 10.0.0.0/24 (par exemple, 10.0.0.0/8).

      • Lorsque le type de pile d'appairage prévu est IPV4_IPV6, s'il existe une route statique locale dont la destination est 2001:0db8:0a0b:0c0d::/96, vous ne pouvez pas établir de nouvelle connexion d'appairage à un réseau VPC contenant une route de sous-réseau IPv6 dont la destination correspond exactement à2001:0db8:0a0b:0c0d::/96. Dans ce cas, la seule plage d'adresses IPv6 de sous-réseau possible est 2001:0db8:0a0b:0c0d::/64, car les plages d'adresses IPv6 de sous-réseau dans Google Cloud doivent utiliser des longueurs de masque de sous-réseau de 64 bits.

    • Vous ne pouvez pas mettre à jour une connexion d'appairage existante si la configuration d'appairage mise à jour entraîne l'importation de la route de sous-réseau en conflit. Exemple :

      • Supposons que deux réseaux VPC sont déjà appairés, mais qu'ils n'exportent et n'importent pas actuellement des routes de sous-réseau IPv4 à l'aide de plages d'adresses IPv4 publiques utilisées en mode privé. Il existe dans le premier réseau VPC une route statique locale dont la destination est 11.0.0.0/24, et il existe dans le réseau VPC appairé une route de sous-réseau dont la destination est 11.0.0.0/8. Vous ne pouvez pas simultanément configurer le réseau VPC appairé pour exporter les routes de sous-réseau en utilisant des adresses IPv4 publiques utilisées en mode privé, et configurer le premier réseau VPC pour qu'il importe les routes de sous-réseau à l'aide d'adresses IPv4 publiques utilisées en mode privé.

      • Supposons que deux réseaux VPC sont déjà appairés et que le type de pile d'appairage soit exclusivement IPv4. Il existe dans le premier réseau VPC une route statique locale dont la destination est 2001:0db8:0a0b:0c0d::/96, et il existe dans le réseau VPC appairé une route de sous-réseau IPv6 dont la destination est 2001:0db8:0a0b:0c0d::/64. Vous ne pouvez pas remplacer le type de pile d'appairage par IPV4_IPV6.

    • En revanche, si les réseaux VPC sont déjà connectés à l'aide de l'appairage de réseaux VPC, vous ne pouvez pas effectuer les opérations suivantes :

      • Créez une route statique locale dont la destination correspond exactement à une route d'appairage de sous-réseau importée ou est comprise dedans.

      • Créez une plage d'adresses de sous-réseau dans le réseau VPC appairé si cette plage correspond exactement à une route statique locale existante ou en contient une.

  • Une route statique d'appairage ne peut pas avoir de destination correspondant exactement à une route de sous-réseau locale ou comprise dedans. Si une route de sous-réseau locale existe, Google Cloud interdit les opérations suivantes :

    • Vous ne pouvez pas établir une nouvelle connexion d'appairage à un réseau VPC qui contient déjà une route statique correspondant exactement à la destination de la route de sous-réseau du réseau VPC local ou est comprise dans celle-ci, si la configuration d'appairage entraîne l'importation de la route personnalisée à partir du pair. Par exemple :

      • Si une route de sous-réseau locale existe pour 10.0.0.0/8, vous ne pouvez pas établir une connexion d'appairage à un réseau VPC contenant une route statique dont la destination correspond exactement à 10.0.0.0/8 ou contient 10.0.0.0/8 (par exemple, 10.0.0.0/24).

      • Lorsque le type de pile d'appairage prévu est IPV4_IPV6, s'il existe une route de sous-réseau locale pour 2001:0db8:0a0b:0c0d::/64, vous ne pouvez pas établir de connexion d'appairage à un réseau VPC avec une route statique dont la destination correspond exactement à 2001:0db8:0a0b:0c0d::/64 ou contient 2001:0db8:0a0b:0c0d::/64 (par exemple, 2001:0db8:0a0b:0c0d::/96).

    • Vous ne pouvez pas mettre à jour une connexion d'appairage existante si la configuration d'appairage mise à jour entraîne l'importation de la route statique en conflit.

    • En revanche, si les réseaux VPC sont déjà connectés à l'aide de l'appairage de réseaux VPC, vous ne pouvez pas effectuer les opérations suivantes :

      • Créez une route de sous-réseau locale dont la destination correspond exactement à une route d'appairage statique importée ou est comprise dedans.
      • Créez une route statique dans le réseau VPC appairé dont la destination correspond exactement à une route de sous-réseau locale existante ou est comprise dedans.

Effets du mode de routage dynamique

Le mode de routage dynamique d'un réseau VPC détermine les régions dans lesquelles les préfixes appris des routeurs cloud de ce réseau sont appliqués en tant que routes dynamiques locales. Pour en savoir plus sur ce comportement, consultez la section Effets du mode de routage dynamique.

Ce concept est étendu à l'appairage de réseaux VPC. Le mode de routage dynamique du réseau VPC exportateur (le réseau contenant les routeurs cloud qui ont appris les préfixes de ces routes dynamiques) détermine les régions dans lesquelles les routes d'appairage dynamiques peuvent être programmées dans des réseaux appairés :

  • Si le mode de routage dynamique du réseau VPC exportateur est régional, ce réseau exporte les routes dynamiques uniquement dans la même région que ses routeurs cloud qui ont appris les préfixes.

  • Si le mode de routage dynamique du réseau VPC exportateur est global, ce réseau exporte les routes dynamiques dans toutes les régions.

Dans les deux cas, le mode de routage dynamique du réseau VPC importateur n'est pas pertinent.

Pour obtenir un exemple illustrant ce comportement, consultez la section Réseau VPC local et réseau VPC appairé avec une connectivité sur site.

Interactions des routes de sous-réseau et des routes dynamiques

Les conflits entre les routes locales ou les routes d'appairage de sous-réseau et les routes dynamiques sont résolus, comme décrit dans la section Interactions avec les routes dynamiques.

Exemples d'appairage de réseaux VPC

Les exemples suivants illustrent deux scénarios courants d'appairage de réseaux VPC.

Réseau VPC local et réseau VPC appairé avec une connectivité sur site

Dans cet exemple, l'appairage de réseaux suivant est configuré :

  • network-a est appairé à network-b et network-b est appairé à network-a.
  • network-a contient deux sous-réseaux dans lesquels chaque sous-réseau se trouve dans une région distincte. network-b contient un seul sous-réseau.
  • network-b est connecté à un réseau sur site avec des tunnels Cloud VPN utilisant un routage dynamique. (Les mêmes principes s'appliquent si les tunnels sont remplacés par des rattachements de VLAN Cloud Interconnect.)
  • La connexion d'appairage pour network-b est configurée avec l'option --export-custom-routes, et la connexion d'appairage pour network-a est configurée avec l'option --import-custom-routes.

Pour fournir une connectivité sur site aux sous-réseaux de network-a et network-b, le routeur cloud de network-b doit être configuré pour utiliser une annonce de routage personnalisée. Par exemple, Cloud Router n'annonce que le préfixe personnalisé custom-prefix-1 qui inclut les plages de sous-réseau de network-b et les plages de sous-réseaux de network-a.

Cloud Router dans us-west1 apprend on-premises-prefix à partir d'un routeur sur site. on-premises-prefix ne crée aucun conflit, car il est plus large que les routes de sous-réseau et d'appairage de sous-réseau. En d'autres termes, on-premises-prefix ne correspond pas exactement à une route de sous-réseau ou d'appairage de sous-réseau, et n'est compris dans aucune d'elles.

Le tableau suivant récapitule la configuration réseau spécifiée dans l'exemple précédent :

Nom du réseau Composant de mise en réseau Plage IPv4 Plage IPv6 Région

network-a

subnet-a

10.0.0.0/24

fc:1000:1000:1000::/64

us-west1

network-a

subnet-b

10.0.1.0/24

fc:1000:1000:1001::/64

europe-north 1

network-b

subnet-c

10.0.2.0/23

fc:1000:1000:1002::/64

us-west1

network-b

Cloud Router

10.0.0.0/22

fc:1000:1000:1000::/64

us-west1

Réseau sur site

Routeur sur site

10.0.0.0/8

fc:1000:1000:1000::/56

Non disponible

Quel que soit le mode de routage dynamique de network-a, les caractéristiques de routage suivantes s'appliquent :

  • Lorsque le mode de routage dynamique de network-b est global, les On-premises prefix appris par Cloud Router dans network-b sont ajoutés en tant que routes dynamiques dans toutes les régions de network-b et en tant que routes d'appairage dynamiques dans toutes les régions de network-a. Si les règles de pare-feu sont correctement configurées, vm-a1, vm-a2 et vm-b peuvent communiquer avec une ressource sur site avec une adresse IPv4 10.5.6.7 (ou une adresse IPv6 fc:1000:1000:10a0:29b::).

  • Si le mode de routage dynamique de network-b devient régional, les On-premises prefix appris par Cloud Router dans network-b ne sont ajoutés qu'en tant que routes dynamiques dans la région us-west1 de network-b et en tant que routes d'appairage dynamiques dans la région us-west1 de network-a. Si les règles de pare-feu sont correctement configurées, seuls vm-a1 et vm-b peuvent communiquer avec une ressource sur site avec l'adresse IPv4 10.5.6.7 (ou l'adresse IPv6 fc:1000:1000:10a0:29b::), car il s'agit de la seule VM dans la même région que le routeur cloud.

Réseau de transit

Dans l'exemple suivant, network-b agit comme un réseau de transit.

  • network-a est appairé à network-b et network-b est appairé à network-a.
  • network-c est appairé à network-b et network-b est appairé à network-c.
  • network-b est connecté à un réseau sur site avec des tunnels Cloud VPN utilisant un routage dynamique. Les mêmes principes s'appliquent si les tunnels sont remplacés par des rattachements de VLAN Cloud Interconnect.
    • Pour fournir une connectivité entre le réseau sur site et les sous-réseaux de network-a, network-b et network-c, le routeur cloud de network-b est configuré pour utiliser une annonce de routage personnalisée. Par exemple, Cloud Router annonce les routes de sous-réseau provenant de network-b, ainsi que les préfixes personnalisés qui couvrent les routes de sous-réseau dans network-a et network-c.
    • Conformément aux interactions des routes de sous-réseau et des routes dynamiques, Cloud Router dans network-b apprend les préfixes sur site et crée des routes dynamiques dans network-b.
  • Les connexions d'appairage de network-b vers network-a et de network-b vers network-c sont configurées avec l'indicateur --export-custom-routes. Les connexions d'appairage de network-a vers network-b et de network-c vers network-b sont configurées avec l'option --import-custom-routes.

Si les pare-feu sont correctement configurés, les scénarios de connectivité suivants sont possibles :

  • Les instances de VM dans network-a peuvent atteindre d'autres VM dans network-b et dans des systèmes sur site.
  • Les instances de VM dans network-c peuvent atteindre d'autres VM dans network-b et dans des systèmes sur site.
  • Les instances de VM dans la région network-b peuvent atteindre d'autres VM dans network-a et network-c, ainsi que dans les systèmes du réseau sur site.

L'appairage de réseaux VPC n'étant pas transitif, les instances de VM dans network-a et network-c ne peuvent pas communiquer entre elles, sauf si vous connectez également les réseaux network-a et network-c à l'aide de l'appairage de réseaux VPC.

Tarification

Les tarifs réseau standards s'appliquent à l'appairage de réseaux VPC.

Étapes suivantes