Présentation de l'appairage de réseaux VPC

L'appairage de réseaux VPC Google Cloud permet une connectivité via des adresses IP internes sur deux réseaux cloud privé virtuel (VPC), qu'ils appartiennent ou non au même projet ou à la même organisation.

L'appairage de réseaux VPC vous permet de connecter des réseaux VPC afin que les charges de travail de différents réseaux VPC puissent communiquer en interne. Le trafic reste à l'intérieur du réseau de Google et ne traverse pas l'Internet public.

L'appairage de réseaux VPC est utile dans les environnements suivants :

  • les écosystèmes SaaS (Software as a Service) dans Google Cloud, en vous permettant de rendre des services disponibles de manière privée sur différents réseaux VPC au sein d'organisations et entre organisations ;
  • les organisations possédant plusieurs domaines d'administration réseau devant communiquer avec des adresses IP internes.

Si vous disposez de plusieurs domaines d'administration réseau au sein de votre organisation, l'appairage de réseaux VPC vous permet de rendre des services disponibles sur des réseaux VPC à l'aide d'adresses IP internes. Si vous proposez des services à d'autres organisations, l'appairage de réseaux VPC vous permet de rendre ces services disponibles en utilisant des adresses IP internes pour ces organisations. La possibilité de desservir plusieurs organisations est utile si vous souhaitez proposer vos services à d'autres entreprises, et si vous possédez ou contrôlez plusieurs organisations.

La fonction d'appairage de réseaux VPC offre plusieurs avantages par rapport à l'utilisation d'adresses IP externes ou de réseaux VPN pour la connexion de réseaux. Par exemple :

  • Latence du réseau : la connectivité au moyen d'adresses internes offre une latence inférieure par rapport aux adresses externes.
  • Sécurité du réseau : les propriétaires de services n'ont pas besoin d'exposer leurs services au réseau Internet public ni, par conséquent, de gérer les risques associés.
  • Coût du réseau : Google Cloud applique la tarification de la bande passante de sortie pour les réseaux qui utilisent des adresses IP externes pour communiquer, même si le trafic se situe dans la même zone. Toutefois, si les réseaux sont appairés, ils peuvent utiliser des adresses IP internes pour communiquer et éviter ces coûts de sortie. Les tarifs réseau standards s'appliquent à tout le trafic.

Pour plus d'informations sur la création de connexions d'appairage, reportez-vous à la page Utiliser l'appairage de réseaux VPC.

Propriétés clés

Les réseaux VPC appairés présentent les propriétés clés suivantes :

  • L'appairage de réseaux VPC fonctionne avec Compute Engine, GKE et l'environnement flexible App Engine.
  • Ils restent administrativement distincts. Les routes, les pare-feu, les VPN et d'autres outils de gestion du trafic sont administrés et appliqués séparément dans chaque réseau VPC.
  • 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.
  • L'appairage et la possibilité d'importer et d'exporter des routes personnalisées peuvent être configurés pour un réseau VPC, même avant la création de l'autre réseau VPC. Néanmoins, l'échange de route ne se produit qu'une fois les deux côtés configurés.
  • Les routes de sous-réseau qui n'utilisent pas d'adresses IP publiques réutilisées en mode privé sont toujours échangées entre les pairs VPC. Les réseaux doivent importer explicitement les routes de sous-réseau qui utilisent des adresses IP publiques réutilisées en mode privé pour les recevoir.
  • Vous pouvez échanger des routes personnalisées (routes statiques et dynamiques), selon que les configurations d'appairage ont été configurées pour les importer ou les exporter. Pour plus d'informations, reportez-vous à la section Importation et exportation de routes personnalisées.
  • Les routes de sous-réseau et statiques sont mondiales. Les routes dynamiques peuvent être régionales ou mondiales, en fonction du mode de routage dynamique du réseau VPC.
  • Il est possible d'appairer un réseau VPC à plusieurs réseaux VPC, mais une limite existe.
  • Les autorisations IAM pour la création et la suppression d'appairages de réseaux VPC sont incluses dans les rôles de propriétaire de projet, d'éditeur de projet et d'administrateur réseau.
  • 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 privé sur le même réseau.
  • La politique de facturation pour le trafic d'appairage est identique à la politique de facturation pour le trafic privé dans un même réseau.
  • Si vous êtes administrateur de règles d'administration, vous pouvez utiliser ces règles pour limiter les réseaux VPC pouvant être appairés à d'autres réseaux VPC au sein de votre organisation. Vous pouvez refuser les connexions d'appairage à des réseaux VPC particuliers ou à des réseaux VPC dans un dossier ou une organisation spécifique. La contrainte s'applique aux nouvelles configurations d'appairage et n'affecte pas les connexions existantes. Une connexion d'appairage existante peut continuer à fonctionner même si une nouvelle règle refuse les nouvelles connexions. Pour plus d'informations, reportez-vous à la documentation sur la contrainte constraints/compute.restrictVpcPeering.

Restrictions

Lors de l'appairage avec des réseaux VPC, prenez en compte les restrictions suivantes :

  • Une plage CIDR de sous-réseau d'un réseau VPC appairé ne peut pas chevaucher une route statique d'un autre réseau VPC appairé. Cette règle concerne les routes de sous-réseau et les routes statiques. Google Cloud vérifie le chevauchement dans les cas suivants et génère une erreur en cas de chevauchement.
    • Vous appairez des réseaux VPC pour la première fois.
    • Vous créez une route statique dans un réseau VPC appairé.
    • Vous créez un sous-réseau dans un réseau VPC appairé.
  • Une route dynamique peut chevaucher une route de sous-réseau dans un réseau appairé. Pour les routes dynamiques, les plages de destination qui chevauchent une route de sous-réseau à partir du réseau appairé sont ignorées. Google Cloud utilise la route de sous-réseau.
  • Seuls les réseaux VPC sont compatibles avec l'appairage de réseaux VPC. Cette fonction n'est PAS disponible pour les anciens réseaux.
  • Vous ne pouvez pas désactiver l'échange de route de sous-réseau ni sélectionner les routes de sous-réseau à échanger. Une fois l'appairage établi, toutes les ressources des adresses IP du sous-réseau sont accessibles sur les réseaux directement appairés. L'appairage de réseaux VPC ne fournit pas de contrôles de routage précis permettant de filtrer les plages CIDR de sous-réseau accessibles via des réseaux appairés. Vous devez utiliser des règles de pare-feu pour filtrer le trafic si nécessaire. Les types de points de terminaison et de ressources suivants sont accessibles via n'importe quel réseau directement appairé :
    • Adresses IP internes de machine virtuelle (VM) dans tous les sous-réseaux
    • Adresses IP à équilibrage de charge interne dans tous les sous-réseaux
  • Seuls les réseaux directement appairés peuvent communiquer. L'appairage transitif n'est pas disponible. En d'autres termes, si le réseau VPC N1 est appairé à N2 et N3, mais si N2 et N3 ne sont pas directement connectés, le réseau VPC N2 ne peut pas communiquer avec le réseau VPC N3 via l'appairage de réseaux VPC.
  • Vous ne pouvez pas utiliser de tag ni de compte de service entre réseaux appairés.
  • Les noms DNS internes de Compute Engine créés sur un réseau ne sont pas accessibles aux réseaux appairés. Utilisez l'adresse IP pour atteindre les instances de VM dans un réseau appairé.
  • Par défaut, l'appairage de réseaux VPC avec GKE est possible lorsqu'il est utilisé avec des alias d'adresses IP. Si vous n'utilisez pas d'alias IP, vous pouvez exporter des routes personnalisées afin que les conteneurs GKE soient accessibles à partir de réseaux appairés.

Ordre de routage

Examinez attentivement l'ordre de routage pour savoir comment Google Cloud résout les conflits de routage entre les réseaux d'un groupe d'appairage.

Importation et exportation de routes personnalisées

Les routes de sous-réseau qui n'exploitent pas d'adresses IP publiques réutilisées en mode privé sont toujours échangées entre des réseaux appairés. Vous pouvez également échanger des routes personnalisées, qui incluent des routes statiques et dynamiques, ainsi que des routes de sous-réseau qui emploient des adresses IP publiques réutilisées en mode privé si les administrateurs des deux réseaux disposent des configurations d'appairage appropriées.

Lorsque vous importez des routes personnalisées, votre réseau VPC peut recevoir des routes personnalisées du réseau appairé uniquement si ce réseau les exporte. De même, si vous exportez des routes personnalisées, le réseau appairé ne peut recevoir des routes personnalisées que si ce réseau les importe.

Lorsque vous importez ou exportez des routes personnalisées, les réseaux n'échangent des routes personnalisées qu'avec des pairs directs. Par exemple, si votre réseau VPC est appairé avec plusieurs réseaux, les routes importées par votre réseau depuis un réseau appairé ne sont pas exportées vers les autres réseaux appairés.

Lorsque vous créez ou modifiez une configuration d'appairage, vous pouvez choisir d'importer ou d'exporter des routes, ou les deux. L'administrateur du réseau appairé doit également configurer son appairage avant que les routes ne soient échangées. Ce processus garantit que les deux administrateurs réseau acceptent explicitement d'échanger des routes personnalisées avant l'échange.

Avantages de l'échange de routes personnalisées

Le partage de routes personnalisées avec des réseaux VPC appairés permet aux réseaux d'apprendre des routes directement à partir de leurs réseaux appairés. Par exemple, si une route personnalisée dans un réseau appairé est mise à jour, votre réseau VPC apprend et utilise automatiquement la route personnalisée mise à jour sans aucune intervention nécessaire de votre part.

L'échange de routes personnalisées peut être utile dans les scénarios suivants :

  • Si vous possédez des clusters GKE sans adressage natif VPC, vous pouvez disposer de plusieurs routes statiques pour diriger le trafic vers des instances de VM hébergeant vos conteneurs. Vous pouvez exporter ces routes statiques afin que les conteneurs soient accessibles à partir de réseaux appairés.
  • Si vous disposez d'un tunnel VPN ou d'une interconnexion, vous pouvez partager des routes personnalisées afin que les réseaux appairés puissent atteindre votre réseau sur site. Pour les routes dynamiques, vous devez ajouter des annonces de routage personnalisées Cloud Router sur votre réseau VPC pour annoncer les sous-réseaux de réseau appairés sur votre réseau sur site.

Remarques

Lorsque vous configurez l'importation ou l'exportation de routes personnalisées, prenez en compte les comportements suivants :

  • Lors de l'appairage, Google Cloud vérifie s'il existe des plages d'adresses IP de sous-réseau qui chevauchent celles de l'autre réseau. En cas de chevauchement, l'appairage n'est pas effectué. Cette vérification du chevauchement ne s'applique qu'aux plages de sous-réseaux VPC. Les routes statiques et dynamiques ne sont pas vérifiées. Si l'appairage est établi, ces routes sont exportées telles quelles.
  • Les routes statiques et dynamiques sont exportées ou importées simultanément. Vous ne pouvez pas choisir d'importer ou d'exporter un seul type de route.
  • Les routes personnalisées importées depuis un réseau VPC ne peuvent pas être exportées vers un autre réseau VPC appairé de manière transitoire.
  • Les routes suivantes ne peuvent être ni importées, ni exportées :
    • Les routes avec tag ne sont jamais échangées entre des réseaux pairs. Les routes avec tag sont des routes statiques personnalisées qui sont limitées à des instances de VM spécifiques à l'aide de tags réseau. Les tags réseau ne peuvent être résolus que dans le réseau VPC dans lequel ils sont créés.
    • Les routes statiques avec un saut suivant vers la passerelle Internet par défaut ne sont jamais échangées. Par exemple, la route par défaut (0.0.0.0/0) avec un saut suivant vers la passerelle Internet par défaut n'est pas échangée entre les réseaux pairs.
  • Les routes importées peuvent entraîner des modifications inattendues du flux de trafic, telles que des modifications de l'ordre de routage. Pour plus d'informations, reportez-vous à la section Ordre de routage.
  • Lorsqu'un réseau VPC importe des routes personnalisées à partir d'un réseau appairé, les plages de destination sont importées telles quelles. Toutefois, le saut suivant pour une route importée est défini sur le nom de la connexion d'appairage. Le trafic est acheminé vers le réseau appairé où le saut suivant est défini.

Fonctions réseau dans des scénarios d'appairage de réseaux VPC

Les sections suivantes présentent le comportement de l'appairage de réseaux VPC dans certains scénarios.

Chevauchement de sous-réseaux au moment de l'appairage

Lors de l'appairage, Google Cloud vérifie s'il existe des sous-réseaux avec des plages d'adresses IP qui se chevauchent entre les deux réseaux VPC ou l'un de leurs réseaux appairés. En cas de chevauchement, l'appairage n'est pas effectué. Étant donné qu'une connectivité maillée complète est créée entre les instances de VM, les sous-réseaux des réseaux VPC appairés n'acceptent pas les plages d'adresses IP qui se chevauchent afin d'éviter les problèmes de routage.

Chevauchement de plages d'adresses IP de sous-réseau entre deux pairs (cliquez pour agrandir)
Chevauchement de plages d'adresses IP de sous-réseau entre deux pairs (cliquez pour agrandir)

La présence de sous-réseaux comportant des plages d'adresses IP qui se chevauchent entre les pairs d'un réseau VPC donné risque de provoquer un conflit de routage. Par exemple, supposons que le réseau VPC N1 ait déjà été appairé au réseau VPC N2, puis que le réseau VPC N3 tente de s'appairer à N2. Il s'agit d'un appairage non valide, car N3 possède un sous-réseau Subnet_5 dont la plage d'adresses IP chevauche Subnet_1 dans le réseau N1.

Chevauchement de plages d'adresses IP de sous-réseau avec trois pairs (cliquez pour agrandir)
Chevauchement de plages d'adresses IP de sous-réseau avec trois pairs (cliquez pour agrandir)

Chevauchement de sous-réseaux lors de la création ou de l'extension de sous-réseaux

Lors de la création d'un sous-réseau VPC ou de l'extension d'une plage d'adresses IP de sous-réseau, Google Cloud vérifie que la nouvelle plage d'adresses IP de sous-réseau ne chevauche pas les plages d'adresses IP des sous-réseaux du même réseau VPC ou des réseaux VPC directement appairés. Si c'est le cas, l'action de création ou d'extension échoue. Par exemple, lorsqu'un nouveau sous-réseau Subnet_3 est créé dans le réseau N2 (voir la figure suivante), les plages d'adresses IP ne doivent pas chevaucher les plages d'adresses IP définies dans le réseau N1 directement appairé.

Vérification lors de la création de sous-réseau (cliquez pour agrandir)
Vérification lors de la création de sous-réseau (cliquez pour agrandir)

Google Cloud garantit également qu'aucune plage d'adresses IP de sous-réseau se chevauchant n'est admise sur les réseaux VPC ayant un réseau appairé en commun. Si c'est le cas, l'action de création ou d'extension échoue. Par exemple, lorsqu'un nouveau sous-réseau Subnet_5 est créé dans le réseau N3 (voir la figure suivante), les plages d'adresses IP ne doivent pas chevaucher les plages d'adresses IP définies dans le réseau N2 directement appairé, ni dans le réseau N1, car celui-ci est déjà appairé à N2.

Vérification lors de la création de sous-réseau avec trois pairs (cliquez pour agrandir)
Vérification lors de la création de sous-réseau avec trois pairs (cliquez pour agrandir)

Accès sur site à partir d'un réseau appairé

Vous pouvez utiliser Cloud VPN ou Cloud Interconnect pour connecter de manière sécurisée votre réseau sur site à votre réseau VPC. Si vous exportez des routes personnalisées, les réseaux VPC appairés peuvent également se connecter à votre réseau sur site. Du côté sur site, vous devez créer des routes afin que le trafic allant vers les réseaux VPC soit dirigé vers le tunnel VPN.

Les VPN haute disponibilité et Cloud Interconnect requièrent un routage dynamique. Les tunnels VPN classiques peuvent utiliser un routage statique ou dynamique. Toutefois, certains cas d'utilisation de tunnels VPN classiques sont obsolètes.

Pour un routage dynamique, utilisez Cloud Router pour mettre à jour de manière dynamique les routes entre votre réseau VPC et votre réseau sur site à l'aide du protocole BGP (Border Gateway Protocol). Les routeurs Cloud peuvent apprendre et propager des routes dans leur région ou pour toutes les régions d'un réseau VPC. Ce comportement dépend du mode de routage dynamique du réseau VPC, qui peut être régional ou mondial.

Les cas d'utilisation suivants montrent comment les ressources des réseaux VPC appairés sont accessibles après avoir importé et exporté des routes personnalisées. Chaque exemple montre deux réseaux (network-a et network-b) qui sont appairés l'un à l'autre. Dans un exemple, le mode de routage dynamique pour network-b est régional. Dans l'autre exemple, il est mondial.

Routage dynamique régional

Si vous utilisez le routage dynamique régional, seules les ressources de la même région que le routeur cloud peuvent accéder au réseau sur site. Cette restriction s'applique au réseau VPC du routeur cloud et à tous les réseaux VPC appairés, quel que soit le mode de routage dynamique du réseau VPC appairé. Dans l'exemple suivant, network-b contient un tunnel VPN (qui peut également être une interconnexion) et un routeur Cloud Router. Le mode de routage dynamique de network-b est régional. Dans le réseau appairé, subnet-a se trouve dans la même région que le routeur Cloud Router dans network-b.

Une fois la connexion d'appairage établie, network-a peut accéder au tunnel VPN dans network-b. Cet accès est limité aux sous-réseaux qui se trouvent dans la même région que le routeur cloud. Par exemple, l'instance de VM vm-a peut atteindre le tunnel VPN, car elle se trouve dans la même région que le routeur Cloud Router. Les instances de VM d'autres régions ne peuvent pas atteindre le tunnel.

Cloud Router n'apprend pas les routes et ne les propage pas à partir de réseaux VPC mis en réseau. Par conséquent, vous devez disposer d'une annonce de routage personnalisée sur le routeur Cloud Router qui propage la plage 10.8.1.0/24 sur le réseau sur site sur la session BGP.

Le tableau suivant récapitule les routes résultantes pour network-a et network-b s'ils importent et exportent des routes personnalisées :

Réseau Destination Saut suivant Origine
network-a 0.0.0.0/0 Passerelle Internet local
10.8.1.0/24 network-a local
10.30.0.0/16 vm-a1 local
10.8.2.0/24 appairage a à b pair
10.10.0.0/16
(route dynamique limitée à us-west1)
appairage a à b pair
network-b 0.0.0.0/0 Passerelle Internet local
10.8.2.0/24 network-b local
10.10.0.0/16
(route dynamique limitée à us-west1)
vpn-b local
10.8.1.0/24 appairage b à a pair
10.30.0.0/16 appairage b à a pair

Routage dynamique mondial

Si network-b active le routage dynamique mondial, les ressources de toutes les régions peuvent accéder au réseau sur site. Ceci s'applique au réseau VPC du routeur cloud et à tous les réseaux VPC appairés, quel que soit le mode de routage dynamique du réseau VPC appairé.

Dans l'exemple suivant, les ressources de network-a peuvent accéder au tunnel VPN de network-b, quelle que soit leur région. Par exemple, les instances de VM vm-a1 et vm-a2 peuvent atteindre le réseau sur site même si vm-a2 se trouve dans une autre région que celle du tunnel VPN.

Cloud Router doit également inclure une annonce de routage personnalisée pour annoncer les plages 10.8.1.0/24 et 10.9.1.0/24 au réseau sur site sur la session BGP.

Le tableau suivant récapitule les routes résultantes pour network-a et network-b s'ils importent et exportent des routes personnalisées :

Réseau Destination Saut suivant Origine
network-a 0.0.0.0/0 Passerelle Internet local
10.8.1.0/24 network-a local
10.9.1.0/24 network-a local
10.30.0.0/16 vm-a1 local
10.8.2.0/24 appairage a à b pair
10.10.0.0/16
(route dynamique mondiale)
appairage a à b pair
network-b 0.0.0.0/0 Passerelle Internet local
10.8.2.0/24 network-b local
10.10.0.0/16
(route dynamique mondiale)
vpn-b local
10.8.1.0/24 appairage b à a pair
10.9.1.0/24 appairage b à a pair
10.30.0.0/16 appairage b à a pair

Réseau VPC en tant que réseau de transit

Imaginons que vous disposiez d'une seule connexion sur site, par exemple un tunnel VPN ou une interconnexion, entre votre réseau VPC et votre réseau sur site. Vous souhaitez partager cette connexion avec d'autres réseaux VPC afin de ne pas avoir à recréer une connexion sur site pour tous les autres réseaux VPC.

Vous pouvez appairer d'autres réseaux VPC au vôtre, également appelé réseau de transit, afin que les autres réseaux puissent utiliser la connexion sur site. Tous les réseaux appairés peuvent exploiter la connexion sur site, mais ils ne peuvent pas acheminer le trafic vers un autre pair via le réseau de transit.

L'exemple suivant comporte trois réseaux VPC. network-b est appairé avec network-a et network-c. Tous les réseaux exportent et importent des routes personnalisées. network-b agit comme réseau de transit, où se trouve le tunnel VPN.

  • Par défaut, le routeur Cloud Router gèrant les routes pour les tunnels connectés à la passerelle Cloud VPN dans network-b annonce automatiquement les plages d'adresses IP du sous-réseau des sous-réseaux de network-b.

  • Les routes vers des destinations sur site sont installées en tant que routes dynamiques personnalisées dans network-b par le routeur Cloud Router qui gère les routes pour les tunnels connectés à la passerelle Cloud VPN dans network-b.

  • Vous devez ajouter les plages d'adresses IP de sous-réseau pour les sous-réseaux dans network-a et network-c en configurant des annonces de routage personnalisées sur le routeur Cloud Router qui gère les routes pour les tunnels connectés à la passerelle Cloud VPN dans network-b.

  • Les routes dynamiques personnalisées (vers des destinations sur site) sont échangées à l'aide de l'appairage de réseaux VPC vers network-a et network-c, car network-b a été configuré pour exporter les routes personnalisées, et les deux autres réseaux ont été configurés pour les importer.

  • Cet exemple fournit la joignabilité suivante :

    • Les instances de VM dans la région network-a peuvent atteindre d'autres VM dans la région network-b et des systèmes du réseau 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.
    • Les instances de VM dans la région network-c peuvent atteindre d'autres VM dans la région network-b et des 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 appairez également le réseau network-a avec network-c.

Équilibreurs de charge internes

Les instances de VM des réseaux appairés peuvent accéder aux adresses IP internes des équilibreurs de charge TCP/UDP internes de votre réseau VPC si les conditions suivantes sont remplies :

  • Si l'accès mondial est désactivé sur un équilibreur de charge TCP/UDP interne, les clients doivent se trouver dans la même région que l'équilibreur de charge. Ils doivent également se trouver sur le même réseau VPC que l'équilibreur de charge ou sur un réseau VPC connecté au réseau VPC de l'équilibreur de charge via l'appairage de réseaux VPC.

  • Si l'accès mondial est activé sur un équilibreur de charge TCP/UDP interne, les clients peuvent se trouver dans n'importe quelle région. Ils doivent toujours se trouver sur le même réseau VPC que l'équilibreur de charge ou sur un réseau VPC connecté au réseau VPC de l'équilibreur de charge via l'appairage de réseaux VPC.

  • Les règles de pare-feu d'entrée qui s'appliquent aux machines virtuelles du backend de l'équilibreur de charge autorisent le trafic depuis des sources situées dans des réseaux appairés. Ces règles de pare-feu d'entrée doivent être créées sur le réseau VPC où demeure l'équilibreur de charge.

Pour en savoir plus, consultez les pages suivantes :

Règles de pare-feu

Lorsque vous connectez des réseaux par appairage de réseaux VPC, les règles de pare-feu ne sont pas échangées. Pour autoriser le trafic entrant provenant d'instances de machines virtuelles dans un réseau appairé, vous devez créer des règles d'autorisation de pare-feu d'entrée. Par défaut, le trafic entrant sur les VM est bloqué par la règle implicite d'entrée interdite.

Si vous devez restreindre l'accès aux VM de manière à n'accorder l'accès qu'aux autres VM de votre réseau VPC, assurez-vous que les sources de votre entrée n'autorisent les règles de pare-feu que pour identifier les VM de votre réseau VPC, et non celles de réseaux appairés. Par exemple, vous pouvez spécifier des plages d'adresses IP sources uniquement pour les sous-réseaux de votre réseau VPC.

Pour limiter l'accès à un équilibreur de charge TCP/UDP interne, créez des règles de pare-feu d'entrée qui s'appliquent aux machines virtuelles du backend de l'équilibreur de charge.

VPC partagé

La fonction d'appairage de réseaux VPC autorise l'appairage à un VPC partagé. Un projet hôte VPC partagé est un projet qui permet à d'autres projets d'utiliser l'un de ses réseaux. Le schéma suivant illustre cette configuration.

VPC partagé avec appairage de réseaux (cliquez pour agrandir)
VPC partagé avec appairage de réseaux (cliquez pour agrandir)

Network-SVPC se trouve dans un réseau VPC partagé, dans le projet hôte P1. Les projets de service P3 et P4 peuvent connecter des instances de VM à Network-SVPC. Network-SVPC est appairé à Network-A. Résultat :

  • Les instances de VM des projets de service VPC partagé utilisant Network-SVPC (VM3 et VM4) ont une connectivité IP interne privée avec tous les points de terminaison associés à Network-A.
  • Les instances de machine virtuelle associées à network-A auront une connectivité IP interne et privée avec tous les points de terminaison associés à Network-SVPC et ce, que ces points de terminaison résident dans le projet hôte ou dans un projet de service.

L'appairage de réseaux VPC peut être configuré entre deux réseaux VPC partagés.

Plusieurs interfaces réseau par instance de VM

Une instance de VM peut comprendre plusieurs interfaces réseau, une par réseau VPC. Pour ces instances, Google Cloud attribue des routes IP basées sur les destinations, où chaque interface obtient une route à partir du sous-réseau dans lequel elle se trouve. En outre, Google Cloud fournit une route par défaut à l'interface réseau principale. Avec le routage basé sur les destinations, tout trafic qui n'est pas destiné aux sous-réseaux de l'instance sort de l'interface réseau principale. Pour plus d'informations, consultez la section Comportement DHCP avec plusieurs interfaces réseau.

Lorsque des réseaux pairs incluent des instances de VM avec plusieurs interfaces réseau, vous devrez peut-être remplacer la règle de routage par défaut basée sur la destination par une règle de routage basée sur la source. Pour plus d'informations, consultez la section Configurer une liaison de règle.

Les scénarios suivants indiquent dans quels cas une instance de VM peut ou non nécessiter une règle de routage basée sur la source.

Règles de routage requises

Dans l'exemple suivant, la vm1 nécessite une règle de routage basée sur la source pour que les vm1 et vm2 puissent communiquer. Sans règle de routage, tout le trafic sort de vm1-nic0 pour être envoyé vers network-a, sauf si le trafic est destiné à subnet-b où se trouve nic1. Cela signifie que le trafic de vm1 destiné à network-c est ignoré ou envoyé à la mauvaise destination, car l'instance de VM envoie toujours du trafic hors de son interface principale.

Les exigences concernant les règles de routage dépendent des plages d'adresses IP de sous-réseaux

Dans l'exemple suivant, l'interface réseau principale de vm1 se trouve dans un réseau qui est appairé à un autre réseau. Vous n'avez pas besoin de configurer la liaison de règles sur vm1.

Dans l'exemple suivant, vm1-nic1 et vm2-nic0 se trouvent dans des sous-réseaux qui se chevauchent. Une fois l'appairage établi, Google Cloud recherche les plages d'adresses IP qui se chevauchent uniquement entre les pairs et non entre les autres réseaux où les instances contiennent des interfaces réseau. Pour vous assurer que la communication entre vm1 et vm2 fonctionne, vous devez ajouter une règle de routage basée sur la source sur vm1-nic0.

Appairage entre les interfaces

L'exemple suivant présente une instance de VM avec plusieurs interfaces réseau, chacune d'entre elles se trouvant dans un réseau appairé avec les autres. Dans ce cas, vm1 ne nécessite pas de règle de routage basée sur la source. Le trafic quittant l'instance de VM vers chaque sous-réseau utilise l'interface réseau correspondante.

Si vm1 envoie du trafic vers l'adresse IP de vm2-nic1, le trafic est dirigé vers nic1, mais sort de nic0. De même, si vm3 envoie du trafic vers l'adresse IP de vm2-nic0, le trafic est dirigé vers nic0, mais sort de nic1.

Plages secondaires de sous-réseaux

Un sous-réseau possède une plage d'adresses IP principale unique et, éventuellement, une ou plusieurs plages d'adresses IP secondaires. Pour chaque plage d'adresses IP de sous-réseau, Google Cloud crée une route de sous-réseau. Lorsque vous utilisez l'appairage de réseaux VPC, Google Cloud échange toujours les routes de sous-réseau qui n'utilisent pas d'adresses IP publiques réutilisées entre les deux réseaux appairés. Si les règles de pare-feu de chaque réseau autorisent la communication, les instances de VM d'un réseau peuvent communiquer avec les instances du réseau appairé.

Lorsque vous établissez une relation d'appairage, Google Cloud vérifie que les plages principale et secondaires d'un sous-réseau ne chevauchent pas les autres plages des réseaux appairés.

Étape suivante