Présentation du réseau VPC

Un réseau cloud privé virtuel (VPC) est une version virtuelle d'un réseau physique, tel qu'un réseau de centre de données. Il fournit la connectivité pour vos instances de machines virtuelles (VM) Compute Engine, vos clusters Google Kubernetes Engine (GKE), vos instances d'environnement flexible App Engine et d'autres ressources dans votre projet.

Les projets peuvent contenir plusieurs réseaux VPC. Sauf si vous créez une règle d'administration qui l'interdit, les nouveaux projets démarrent avec un réseau par défaut qui possède un sous-réseau dans chaque région (réseau VPC en mode automatique).

Spécifications

Les réseaux VPC ont les propriétés suivantes :

  • Les réseaux VPC, y compris leurs routes et règles de pare-feu associées, sont des ressources globales. Ils ne sont associés à aucune région ou zone particulière.

  • Les sous-réseaux sont des ressources régionales. Chaque sous-réseau définit une plage d'adresses IP.

  • Le trafic à destination et en provenance des instances peut être contrôlé à l'aide de règles de pare-feu de réseau.

  • Les ressources d'un réseau VPC peuvent communiquer entre elles à l'aide d'adresses IPv4 internes (privées) sous réserve des règles de pare-feu de réseau applicables. Pour plus d'informations, consultez la section Communication au sein du réseau.

  • Les instances comportant des adresses IP internes peuvent communiquer avec les API et les services Google. Pour en savoir plus, consultez la page Options d'accès privé pour les services.

  • L'administration réseau peut être sécurisée à l'aide des rôles Cloud Identity and Access Management (Cloud IAM).

  • Une organisation peut utiliser un VPC partagé pour conserver un réseau VPC dans un projet hôte commun. Les membres Cloud IAM autorisés d'autres projets de la même organisation peuvent créer des ressources qui utilisent des sous-réseaux du réseau VPC partagé.

  • Les réseaux VPC peuvent être connectés à d'autres réseaux VPC dans différents projets ou différentes organisations à l'aide de l'appairage de réseaux VPC.

  • Les réseaux VPC peuvent être connectés en toute sécurité dans des environnements hybrides à l'aide de Cloud VPN ou Cloud Interconnect.

  • Les réseaux VPC ne gèrent que le trafic de monodiffusion IPv4. Ils ne gèrent pas le trafic de diffusion, de multidiffusion ou IPv6 au sein du réseau : les VM appartenant au réseau VPC ne peuvent envoyer du trafic qu'à destination d'adresses IPv4 et ne peuvent en recevoir que depuis des sources IPv4. Toutefois, il est possible de créer une adresse IPv6 pour un équilibreur de charge global.

Terminologie associée au réseau et au sous-réseau

Les termes subnet et subnetwork faisant référence au sous-réseau sont synonymes. Ils sont interchangeables dans Google Cloud Console, les commandes gcloud et la documentation de l'API.

Un sous-réseau et un réseau (VPC) sont deux entités distinctes. Les réseaux et les sous-réseaux sont des types d'objets différents dans Google Cloud.

Réseaux et sous-réseaux

Chaque réseau VPC est constitué d'une ou de plusieurs partitions de plage d'adresses IP, appelées sous-réseaux. Chaque sous-réseau est associé à une région. Les réseaux VPC ne sont associés à aucune plage d'adresses IP. Les plages d'adresses IP sont définies pour les sous-réseaux.

Un réseau doit comporter au moins un sous-réseau pour que vous puissiez l'utiliser. Les réseaux VPC en mode automatique créent automatiquement des sous-réseaux dans chaque région. Les réseaux VPC en mode personnalisé démarrent sans sous-réseaux, ce qui vous donne ainsi un contrôle total sur la création de sous-réseaux. Vous pouvez créer plusieurs sous-réseaux par région. Pour plus d'informations sur les différences entre les réseaux VPC en mode automatique et en mode personnalisé, consultez la section Types de réseaux VPC.

Lorsque vous créez une ressource dans Google Cloud, vous choisissez un réseau et un sous-réseau. Pour les ressources autres que les modèles d'instance, vous sélectionnez également une zone ou une région. Lorsque vous sélectionnez une zone, sa région parente est implicitement sélectionnée. Les sous-réseaux sont des objets régionaux ; ainsi, la région que vous sélectionnez pour une ressource détermine les sous-réseaux qu'elle peut utiliser :

  • Le processus de création d'une instance implique la sélection d'une zone, d'un réseau et d'un sous-réseau. Vous ne pouvez sélectionner que les sous-réseaux associés à la région sélectionnée. Google Cloud attribue une adresse IP à l'instance parmi la plage d'adresses disponibles dans le sous-réseau.

  • Le processus de création d'un groupe d'instances géré implique la sélection d'une zone ou d'une région, en fonction du type de groupe, et d'un modèle d'instance. Vous ne pouvez sélectionner que les modèles d'instance dont les sous-réseaux définis se trouvent dans la même région que celle sélectionnée pour le groupe d'instances géré.

    • Les modèles d'instance sont des ressources globales. Le processus de création d'un modèle d'instance implique la sélection d'un réseau et d'un sous-réseau. Si vous sélectionnez un réseau VPC en mode automatique, vous pouvez choisir d'utiliser des sous-réseaux automatiques afin de différer la sélection de sous-réseau disponible dans la région sélectionnée. Les réseaux VPC en mode automatique possèdent, par définition, un sous-réseau dans chaque région.
  • Le processus de création d'un cluster de conteneurs Kubernetes implique la sélection d'une zone ou d'une région (en fonction du type de cluster), d'un réseau et d'un sous-réseau. Vous ne pouvez sélectionner que les sous-réseaux associés à la région sélectionnée.

Mode de création du sous-réseau

Google Cloud propose deux types de réseaux VPC, déterminés par leur mode de création de sous-réseau:

  • Lorsqu'un réseau VPC en mode automatique est créé, un sous-réseau de chaque région y est automatiquement créé. Ces sous-réseaux créés automatiquement utilisent un ensemble de plages d'adresses IP prédéfinies qui correspondent au bloc CIDR 10.128.0.0/9. À mesure que de nouvelles régions Google Cloud deviennent disponibles, de nouveaux sous-réseaux dans ces régions sont automatiquement ajoutés aux réseaux VPC en mode automatique à l'aide d'une plage d'adresses IP de ce bloc. Outre les sous-réseaux créés automatiquement, vous pouvez ajouter manuellement d'autres sous-réseaux aux réseaux VPC en mode automatique dans les régions de votre choix, en utilisant des plages d'adresses IP autres que 10.128.0.0/9.

  • Lorsqu'un réseau VPC en mode personnalisé est créé, aucun sous-réseau n'est créé automatiquement. Ce type de réseau vous offre un contrôle total sur ses sous-réseaux et ses plages d'adresses IP. Vous créez des sous-réseaux dans les régions de votre choix et en utilisant les plages d'adresses IP que vous spécifiez.

Vous pouvez basculer un réseau VPC en mode automatique vers le mode personnalisé. Il s'agit d'une conversion à sens unique : les réseaux VPC en mode personnalisé ne peuvent pas être basculés en mode automatique. Pour savoir quel type de réseau répond à vos besoins, consultez les remarques concernant les réseaux VPC en mode automatique.

Réseau par défaut

Sauf si vous choisissez de désactiver cette fonction, chaque nouveau projet démarre avec un réseau par défaut. Le réseau par défaut est un réseau VPC en mode automatique avec des règles de pare-feu pré-remplies.

Vous pouvez désactiver la création de réseaux par défaut en créant une règle d'administration avec la contrainte compute.skipDefaultNetworkCreation. Les projets qui héritent de cette règle n'ont pas de réseau par défaut.

Remarques sur les réseaux VPC en mode automatique

Les réseaux VPC en mode automatique sont faciles à configurer et à utiliser, et ils sont parfaitement adaptés aux cas d'utilisation présentant les attributs suivants :

  • La création automatique de sous-réseaux dans chaque région vous est utile.

  • Les plages d'adresses IP prédéfinies des sous-réseaux ne chevauchent pas les plages d'adresses IP que vous utilisez à des fins différentes (par exemple, les connexions Cloud VPN aux ressources sur site).

Cependant, les réseaux VPC en mode personnalisé sont plus flexibles et conviennent mieux à la production. Les attributs suivants mettent en évidence les cas d'utilisation où des réseaux VPC en mode personnalisé sont recommandés ou requis :

  • La création automatique de sous-réseaux dans chaque région ne vous est pas nécessaire.

  • Si des sous-réseaux sont créés automatiquement à mesure que de nouvelles régions deviennent disponibles, ceux-ci peuvent chevaucher les adresses IP utilisées par les sous-réseaux créés manuellement ou les routes statiques, ou interférer avec la planification globale de votre réseau.

  • Vous avez besoin d'un contrôle complet des sous-réseaux créés dans votre réseau VPC, y compris des régions et des plages d'adresses IP utilisées.

  • Vous envisagez de connecter des réseaux VPC à l'aide de l'appairage de réseaux VPC ou de Cloud VPN. Étant donné que les sous-réseaux de chaque réseau VPC en mode automatique utilisent la même plage d'adresses IP prédéfinie, vous ne pouvez pas connecter les réseaux VPC en mode automatique les uns aux autres.

Sous-réseaux et plages d'adresses IP

Lorsque vous créez un sous-réseau, vous devez définir une plage d'adresses IP principale. Vous pouvez éventuellement définir des plages d'adresses IP secondaires :

  • Plage d'adresses IP principale : vous pouvez choisir n'importe quel bloc CIDR RFC 1918 privé pour la plage d'adresses IP principale du sous-réseau. Ces adresses IP peuvent être utilisées pour les adresses IP internes principales des VM, les adresses IP d'alias des VM et les adresses IP des équilibreurs de charge internes.

  • Plages d'adresses IP secondaires : vous pouvez définir une ou plusieurs plages d'adresses IP secondaires, qui sont des blocs CIDR RFC 1918 distincts. Ces plages d'adresses IP ne sont utilisées que pour les adresses IP d'alias. Les limites par réseau décrivent le nombre maximal de plages secondaires que vous pouvez définir pour chaque sous-réseau.

Les sous-réseaux n'ont pas besoin de former un bloc CIDR contigu prédéfini, mais cette configuration est possible si vous le souhaitez. Par exemple, les réseaux VPC en mode automatique créent des sous-réseaux qui correspondent à une plage d'adresses IP en mode automatique prédéfinie.

Pour plus d'informations, consultez la section Utiliser des sous-réseaux.

Adresses IP réservées

Chaque sous-réseau possède quatre adresses IP réservées dans sa plage d'adresses IP principale. Il n'y a pas d'adresses IP réservées dans les plages d'adresses IP secondaires.

Adresse IP réservée Description Exemple
Réseau Première adresse dans la plage d'adresses IP principales du sous-réseau 10.1.2.0 dans 10.1.2.0/24
Passerelle par défaut Deuxième adresse dans la plage d'adresses IP principales du sous-réseau 10.1.2.1 dans 10.1.2.0/24
Avant-dernière adresse Avant-dernière adresse dans la plage d'adresses IP principale pour le sous-réseau réservé par Google Cloud en vue d'une utilisation future 10.1.2.254 dans 10.1.2.0/24
Diffusion Dernière adresse dans la plage d'adresses IP principales du sous-réseau 10.1.2.255 dans 10.1.2.0/24

Plages d'adresses IP du mode automatique

Ce tableau répertorie les plages d'adresses IP des sous-réseaux créés automatiquement dans un réseau VPC en mode automatique. Les plages d'adresses IP de ces sous-réseaux entrent dans le bloc CIDR 10.128.0.0/9. Les réseaux VPC en mode automatique sont conçus avec un sous-réseau par région au moment de la création et reçoivent automatiquement les nouveaux sous-réseaux dans les nouvelles régions. Les portions inutilisées de 10.128.0.0/9 sont réservées pour une utilisation future par Google Cloud.

Région Plage d'adresses IP (CIDR) Passerelle par défaut Adresses utilisables (incluses)
asia-east1 10.140.0.0/20 10.140.0.1 de 10.140.0.2 à 10.140.15.253
asia-east2 10.170.0.0/20 10.170.0.1 de 10.170.0.2 à 10.170.15.253
asia-northeast1 10.146.0.0/20 10.146.0.1 de 10.146.0.2 à 10.146.15.253
asia-northeast2 10.174.0.0/20 10.174.0.1 de 10.174.0.2 à 10.174.15.253
asia-northeast3 10.178.0.0/20 10.178.0.1 de 10.178.0.2 à 10.178.15.253
asia-south1 10.160.0.0/20 10.160.0.1 de 10.160.0.2 à 10.160.15.253
asia-southeast1 10.148.0.0/20 10.148.0.1 de 10.148.0.2 à 10.148.15.253
australia-southeast1 10.152.0.0/20 10.152.0.1 de 10.152.0.2 à 10.152.15.253
europe-north1 10.166.0.0/20 10.166.0.1 de 10.166.0.2 à 10.166.15.253
europe-west1 10.132.0.0/20 10.132.0.1 de 10.132.0.2 à 10.132.15.253
europe-west2 10.154.0.0/20 10.154.0.1 de 10.154.0.2 à 10.154.15.253
europe-west3 10.156.0.0/20 10.156.0.1 de 10.156.0.2 à 10.156.15.253
europe-west4 10.164.0.0/20 10.164.0.1 de 10.164.0.2 à 10.164.15.253
europe-west6 10.172.0.0/20 10.172.0.1 de 10.172.0.2 à 10.172.15.253
northamerica-northeast1 10.162.0.0/20 10.162.0.1 de 10.162.0.2 à 10.162.15.253
southamerica-east1 10.158.0.0/20 10.158.0.1 de 10.158.0.2 à 10.158.15.253
us-central1 10.128.0.0/20 10.128.0.1 de 10.128.0.2 à 10.128.15.253
us-east1 10.142.0.0/20 10.142.0.1 de 10.142.0.2 à 10.142.15.253
us-east4 10.150.0.0/20 10.150.0.1 de 10.150.0.2 à 10.150.15.253
us-west1 10.138.0.0/20 10.138.0.1 de 10.138.0.2 à 10.138.15.253
us-west2 10.168.0.0/20 10.168.0.1 de 10.168.0.2 à 10.168.15.253
us-west3 10.180.0.0/20 10.180.0.1 de 10.180.0.2 à 10.180.15.253

Routes et règles de pare-feu

Routes

Les routes représentent des chemins pour les paquets sortant des instances (trafic de sortie). Les routes dans Google Cloud sont divisées en deux catégories : générées par le système et personnalisées.

Chaque nouveau réseau commence par deux types de routes générées par le système :

  • La route par défaut définit un chemin de sortie du réseau VPC utilisé par le trafic. Elle fournit un accès Internet général aux VM répondant aux conditions d'accès à Internet. Elle fournit également le chemin classique pour l'Accès privé à Google.

  • Une route de sous-réseau est créée pour chacune des plages d'adresses IP associées à un sous-réseau. Chaque sous-réseau comporte au moins une route de sous-réseau pour sa plage d'adresses IP principale. Des routes de sous-réseau supplémentaires sont créées pour un sous-réseau si vous lui ajoutez des plages d'adresses IP secondaires. Les routes de sous-réseau définissent des chemins permettant au trafic d'atteindre les VM utilisant les sous-réseaux. Vous ne pouvez pas supprimer les routes de sous-réseau manuellement.

Les routes personnalisées sont soit des routes statiques que vous créez manuellement, soit des routes dynamiques gérées automatiquement par un ou plusieurs routeurs Cloud Router. Pour plus d'informations, reportez-vous à la section Routes personnalisées.

Pour en savoir plus sur le routage dans Google Cloud, consultez la présentation des routes.

Mode de routage dynamique

Chaque réseau VPC est associé à un mode de routage dynamique qui contrôle le comportement de tous les routeurs Cloud Router. Les routeurs Cloud Router partagent des routes vers votre réseau VPC et apprennent des routes dynamiques personnalisées à partir des réseaux connectés lorsque vous connectez votre réseau VPC à un autre réseau via un tunnel Cloud VPN utilisant le routage dynamique, l'interconnexion dédiée ou l'interconnexion partenaire.

  • Le routage dynamique régional est le routage par défaut. Dans ce mode, les routes vers les ressources sur site apprises par un routeur Cloud Router dans le réseau VPC ne s'appliquent qu'aux sous-réseaux de la même région que le routeur. Chaque routeur Cloud Router ne partage les routes vers les sous-réseaux de sa région qu'avec son homologue sur site, sauf si ces routes sont modifiées par des annonces personnalisées.

  • Le routage dynamique global modifie le comportement de tous les routeurs Cloud Router du réseau, de sorte que les routes vers les ressources sur site apprises sont disponibles dans tous les sous-réseaux du réseau VPC, quelle que soit la région. Chaque routeur Cloud Router partage les routes vers tous les sous-réseaux du réseau VPC avec son homologue sur site, sauf si ces routes sont modifiées par des annonces personnalisées.

Pour plus d'informations sur la personnalisation de l'ensemble de routes partagé par un routeur Cloud Router, consultez la page sur les annonces personnalisées.

Le mode de routage dynamique peut être défini lorsque vous créez ou modifiez un réseau VPC. Vous pouvez faire passer le mode de routage dynamique de la valeur "regional" à la valeur "global" et vice-versa sans restriction. Pour obtenir des instructions, consultez la section Changer le mode de routage dynamique.

Règles de pare-feu

Les règles de pare-feu s'appliquent au trafic sortant et entrant du réseau. Les règles de pare-feu contrôlent le trafic même s'il est entièrement intégré au réseau, y compris la communication entre instances de VM.

Chaque réseau VPC a deux règles de pare-feu implicites. Une règle implicite permet d'autoriser la majorité du trafic sortant, et une autre règle permet de refuser tout trafic entrant. Vous ne pouvez pas supprimer les règles implicites, mais vous pouvez les remplacer par les vôtres. Google Cloud bloque toujours une part du trafic, quelles que soient les règles de pare-feu. Pour plus d'informations, consultez la section sur le trafic bloqué.

Pour déterminer quelle règle de pare-feu a autorisé ou refusé une connexion donnée, consultez la page Journalisation des règles de pare-feu.

Communications et accès

Communication au sein du réseau

Les routes de sous-réseau générées par le système définissent les chemins d'envoi du trafic entre les instances du réseau à l'aide d'adresses IP internes (privées). Pour qu'une instance puisse communiquer avec une autre, des règles de pare-feu appropriées doivent également être configurées. En effet, chaque réseau possède une règle implicite de refus de pare-feu pour le trafic entrant.

Sauf pour le réseau par défaut, vous devez explicitement créer des règles de pare-feu pour le trafic entrant ayant une priorité plus élevée afin de permettre aux instances de communiquer entre elles. Le réseau par défaut inclut plusieurs règles de pare-feu, en plus des règles implicites, y compris la règle default-allow-internal, qui autorise la communication entre instances au sein du réseau. Le réseau par défaut propose également des règles d'entrée autorisant des protocoles tels que RDP et SSH.

Les règles fournies avec le réseau par défaut sont également présentées comme des options à appliquer aux réseaux VPC en mode automatique que vous créez à l'aide de Cloud Console.

Conditions d'accès à Internet

Les critères suivants doivent être remplis pour qu'une instance ait un accès Internet sortant :

  • Le réseau doit disposer d'une route de passerelle Internet par défaut valide ou d'une route personnalisée dont la plage d'adresses IP de destination est la plus générale (0.0.0.0/0). Cette route définit le chemin d'accès à Internet. Pour plus d'informations, consultez la section Routes.

  • Les règles de pare-feu doivent autoriser le trafic de sortie de l'instance. Sauf en cas de substitution par une règle de priorité supérieure, la règle implicite d'autorisation pour le trafic de sortie autorise le trafic sortant de toutes les instances.

  • L'une des conditions suivantes doit être remplie :

    • L'instance doit avoir une adresse IP externe. L'adresse IP externe peut être attribuée à une instance lors de sa création ou après sa création.

    • L'instance doit pouvoir utiliser Cloud NAT ou un proxy basé sur une instance, correspondant à la cible d'une route 0.0.0.0/0 statique.

Communications et accès pour App Engine

Les règles de pare-feu VPC s'appliquent aux ressources exécutées sur le réseau VPC, telles que les VM Compute Engine. Pour les instances App Engine, les règles de pare-feu fonctionnent comme suit :

  • Environnement standard App Engine : seules les règles de pare-feu App Engine s'appliquent au trafic entrant. Les instances d'environnement standard App Engine ne s'exécutant pas dans votre réseau VPC, les règles de pare-feu VPC ne leur sont pas applicables.

  • Environnement flexible App Engine : les règles de pare-feu App Engine et VPC s'appliquent au trafic entrant. Le trafic entrant n'est autorisé que si les deux types de règles de pare-feu l'autorisent. Pour le trafic sortant, les règles de pare-feu VPC s'appliquent.

Pour plus d'informations sur le contrôle de l'accès aux instances App Engine, consultez la section Sécurité des applications.

Traceroute vers des destinations Internet

Pour des raisons internes, Google Cloud augmente le compteur TTL des paquets quittant les instances Compute Engine pour Internet. Des outils tels que traceroute peuvent fournir des résultats incomplets, car la valeur TTL n'expire pas sur certains sauts. Les sauts existant à l'intérieur et à l'extérieur du réseau Google peuvent être masqués.

Le nombre de sauts masqués varie en fonction des niveaux de service réseau de l'instance, de la région et d'autres facteurs. Si les sauts sont peu nombreux, il est possible qu'ils soient tous masqués. Des sauts manquants dans un résultat traceroute ne signifient pas que le trafic sortant est supprimé.

Il n'existe aucune solution pour contourner ce problème.

Exemple de réseau VPC

L'exemple suivant illustre un réseau VPC en mode personnalisé avec trois sous-réseaux dans deux régions :

Exemple de réseau VPC (cliquez pour agrandir)
Exemple de réseau VPC (cliquez pour agrandir)
  • Le sous-réseau Subnet1 est défini sur 10.240.0.0/24 dans la région us-west1.
    • Deux instances de VM dans la zone us-west1-a se trouvent dans ce sous-réseau. Leurs adresses IP proviennent de la plage d'adresses disponible dans le sous-réseau subnet1.
  • Le sous-réseau Subnet2 est défini sur 192.168.1.0/24 dans la région us-east1.
    • Deux instances de VM dans la zone us-east1-a se trouvent dans ce sous-réseau. Leurs adresses IP proviennent de la plage d'adresses disponible dans le sous-réseau subnet2.
  • Le sous-réseau Subnet3 est défini sur 10.2.0.0/16, également dans la région us-east1.
    • Une instance de VM dans la zone us-east1-a et une deuxième instance dans la zone us-east1-b appartiennent au sous-réseau subnet3, chacune recevant une adresse IP de sa plage disponible. Les sous-réseaux étant des ressources régionales, les interfaces réseau des instances peuvent être associées à tout sous-réseau de la même région que leurs zones.

Étape suivante