Présentation du réseau VPC

Un réseau cloud privé virtuel (VPC) est une version virtuelle d'un réseau physique, mise en œuvre au sein du réseau de production de Google, avec Andromeda. Un réseau VPC fournit les fonctionnalités suivantes :

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 (un réseau VPC en mode automatique) qui possède un sous-réseau dans chaque région.

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 mondiales. 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 règles sont mises en œuvre sur les VM elles-mêmes, de sorte que le trafic ne puisse être contrôlé et consigné que lorsqu'il quitte ou atteint une VM.

  • 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 de rôles Identity and Access Management (IAM).

  • Une organisation peut utiliser un VPC partagé pour conserver un réseau VPC dans un projet hôte commun. Les membres IAM autorisés d'autres projets dans la même organisation peuvent créer des ressources utilisant 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 de Cloud Interconnect.

  • Les réseaux VPC acceptent le trafic GRE (version bêta), à l'exception du trafic sur Cloud VPN, Cloud Interconnect, Cloud NAT, et les règles de transfert pour l'équilibrage de charge et le transfert de protocole. GRE vous permet d'utiliser des services tels que SASE (Secure Service Access Edge) et SD-WAN.

  • 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 pour différer la sélection d'un sous-réseau disponible dans la région sélectionnée de tout groupe d'instances géré utilisant le modèle. 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 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 sur les sous-réseaux créés dans votre réseau VPC, y compris les régions et les 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.

Plages de sous-réseaux

Lorsque vous créez un sous-réseau, vous devez définir sa plage d'adresses IP principale. Les adresses IP internes principales des ressources suivantes proviennent de la plage d'adresses IP principale du sous-réseau : instances de VM, équilibreurs de charge internes et transfert de protocole interne. Vous pouvez éventuellement ajouter des plages d'adresses IP secondaires à un sous-réseau, qui ne sont utilisées que par les plages d'adresses IP d'alias. Cependant, vous pouvez configurer des plages d'adresses IP d'alias pour les instances depuis la plage principale ou secondaire d'un sous-réseau.

Chaque plage d'adresses IP principale ou secondaire de tous les sous-réseaux d'un réseau VPC doit être un bloc CIDR valide unique. Reportez-vous aux limites par réseau pour connaître le nombre de plages d'adresses IP secondaires que vous pouvez définir.

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.

Plages valides

Les plages d'adresses IP principale et secondaire d'un sous-réseau sont des adresses IP internes régionales. Le tableau suivant décrit les plages valides.

Plage Description
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Adresses IP privées RFC 1918
100.64.0.0/10 Espace d'adressage partagé RFC 6598
192.0.0.0/24 Attributions de protocole IETF RFC 6890
192.0.2.0/24 (TEST-NET-1)
198.51.100.0/24 (TEST-NET-2)
203.0.113.0/24 (TEST-NET-3)
Documentation RFC 5737
192.88.99.0/24 Relais IPv6 vers IPv4 (obsolète) RFC 7526
198.18.0.0/15 Série de tests comparatifs RFC 2544
240.0.0.0/4

Réservée pour une utilisation future (classe E), comme décrit dans les normes RFC 5735 et RFC 1112.

Certains systèmes d'exploitation ne sont pas compatibles avec l'utilisation de cette plage. Par conséquent, assurez-vous que votre système d'exploitation est compatible avant de créer des sous-réseaux qui l'utilisent.

Adresses IP publiques réutilisées en mode privé Inclut les adresses IP qui ne font pas partie des plages RFC répertoriées dans ce tableau, ni de l'ensemble restreint. Lorsque vous utilisez ces adresses en tant que plages de sous-réseaux, Google Cloud n'achemine pas publiquement le trafic vers celles-ci.

Pour l'appairage de réseaux VPC, les routes de sous-réseau des adresses IP publiques ne sont pas automatiquement échangées. Les routes de sous-réseau sont automatiquement exportées, mais les réseaux de pairs doivent être explicitement configurés pour importation afin de les utiliser.

Les plages de sous-réseaux présentent les contraintes suivantes :

  • Les plages de sous-réseaux ne peuvent pas être identiques, plus étroites ou plus larges qu'une plage restreinte. Par exemple, 169.0.0.0/8 n'est pas une plage de sous-réseaux valide, car elle chevauche la plage de liaison locale 169.254.0.0/16 (RFC 3927), qui est une plage restreinte.

  • Les plages de sous-réseaux ne peuvent pas s'étendre sur une plage RFC (décrite dans le tableau précédent) et une plage d'adresses IP publiques utilisées en mode privé. Par exemple, 172.16.0.0/10 n'est pas une plage de sous-réseaux valide, car elle chevauche les adresses IP publiques et RFC 1918.

  • Les plages de sous-réseaux ne peuvent pas s'étendre sur plusieurs plages RFC. Par exemple, 192.0.0.0/8 n'est pas une plage de sous-réseaux valide, car elle inclut à la fois 192.168.0.0/16 (RFC 1918) et 192.0.0.0/24 (RFC 6890). Cependant, vous pouvez créer deux sous-réseaux avec différentes plages principales, l'une avec 192.0.0.0/16 et l'autre avec 192.0.0.0/24. Vous pouvez également utiliser ces deux plages sur le même sous-réseau si vous en définissez une comme plage secondaire.

Plages restreintes

Les plages restreintes incluent les adresses IP publiques Google et les plages RFC couramment réservées, comme décrit dans le tableau suivant. Ces plages ne peuvent pas être utilisées pour les plages de sous-réseaux.

Plage Description
Adresses IP publiques pour les API et les services Google, y compris les netblocks Google Cloud. Vous trouverez ces adresses IP ici : https://gstatic.com/ipranges/goog.txt.
199.36.153.4/30 et 199.36.153.8/30 Adresses IP virtuelles spécifiques pour l'accès privé à Google
0.0.0.0/8 Réseau actuel (local) RFC 1122
127.0.0.0/8 Hôte local RFC 1122
169.254.0.0/16 Liaison locale RFC 3927
224.0.0.0/4 Multidiffusion (classe D) RFC 5771
255.255.255.255/32 Adresse de destination de diffusion limitée RFC 8190 et RFC 919

Adresses IP réservées dans un sous-réseau

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
asia-southeast2 10.184.0.0/20 10.184.0.1 de 10.184.0.2 à 10.184.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
us-west4 10.182.0.0/20 10.182.0.1 de 10.182.0.2 à 10.182.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 dans le réseau VPC ne s'appliquent qu'aux sous-réseaux de la même région que le routeur Cloud. Chaque routeur Cloud 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 mondial 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 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 modifier 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 (de sortie) et entrant (d'entrée) 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 possède 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 adresses IP externes

Pour des raisons internes, Google Cloud augmente le compteur TTL des paquets qui traversent les sauts suivants sur le réseau de Google. Des outils tels que traceroute et mtr peuvent fournir des résultats incomplets, car la valeur TTL n'expire pas sur certains sauts. Les sauts internes et externes au réseau de Google peuvent être masqués dans les cas suivants :

  • lorsque vous envoyez des paquets depuis des instances Compute Engine vers des adresses IP externes, y compris les adresses IP externes d'autres ressources ou destinations Google Cloud sur Internet ;

  • lorsque vous envoyez des paquets à l'adresse IP externe associée à une instance Compute Engine ou à une autre ressource Google Cloud.

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. Les sauts manquants dans un résultat traceroute ou mtr ne signifient pas que le trafic sortant est supprimé.

Il n'existe aucune solution pour contourner ce problème. Vous devez en tenir compte si vous configurez une surveillance tierce qui se connecte à une adresse IP externe associée à une VM.

Limites de débit de sortie

Les informations de débit réseau sont disponibles dans la section Bande passante réseau.

Taille des paquets

Vous trouverez des informations sur la taille des paquets dans la section Unité de transmission maximale (MTU).

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, leurs interfaces réseau peuvent être associées à tout sous-réseau de la même région que leurs zones.

Unité de transmission maximale

Les réseaux VPC ont une unité de transmission maximale (MTU) par défaut de 1460 octets. Vous pouvez cependant configurer vos réseaux VPC avec une MTU de 1500 octets.

La MTU correspond à la taille, en octets, du plus grand paquet accepté par un protocole de couche réseau. Elle inclut les en-têtes et les données. Dans Google Cloud, vous définissez la MTU de chaque réseau VPC et les instances de VM qui utilisent ce réseau doivent également être configurées pour utiliser cette MTU pour leurs interfaces. Le paramètre de MTU du réseau est communiqué à une VM lorsque celle-ci demande une adresse IP à l'aide du protocole DHCP. L'option 26 du protocole DHCP contient la MTU du réseau.

La MTU a un impact à la fois sur le trafic UDP et TCP :

  • Si un paquet UDP envoyé est trop volumineux pour la destination ou qu'il dépasse la MTU maximale d'un lien réseau sur le chemin d'accès à la destination, il est supprimé si l'option "Ne pas appliquer de fragment" est définie. En cas de suppression, un paquet ICMP du type Fragmentation-Needed est renvoyé à l'expéditeur. (Consulter : PMTUD.
  • Si un paquet UDP envoyé est trop volumineux pour la destination ou qu'il dépasse la MTU maximale d'un lien réseau sur le chemin d'accès à la destination, il est (généralement) fragmenté si l'option Don't-Fragment n'est pas définie. Cette fragmentation a lieu lorsqu'une erreur de concordance est détectée : elle peut se trouver sur un routeur intermédiaire, ou même au niveau de l'émetteur si la taille du paquet envoyé depasse la MTU.
  • Le protocole TCP négocie la taille du segment maximale (MSS) lors de la configuration de la connexion. Ensuite, les paquets sont segmentés dans la taille de MTU inférieure des deux points de terminaison de la connexion.

Paramètres des VM et MTU

La MTU de l'interface des VM Linux basées sur des images d'OS fournies par Google est automatiquement définie sur la MTU du réseau VPC lors de leur création. Si une VM comporte plusieurs interfaces réseau, chaque interface est définie sur la MTU du réseau associé. Si vous modifiez la MTU d'un VPC comportant des VM en cours d'exécution, vous devez arrêter, puis démarrer ces VM pour récupérer la nouvelle MTU. Lorsque les VM redémarrent, la MTU du réseau modifiée est communiquée au protocole DHCP.

Les VM Windows ne configurent pas automatiquement leurs interfaces de sorte à utiliser la MTU du réseau VPC au démarrage. Au lieu de cela, les VM Windows basées sur des images d'OS fournies par Google sont configurées avec une MTU fixe de 1460. Exécutez la commande suivante sur chaque VM Windows pour définir sa MTU : netsh interface ipv4 set subinterface NAME mtu=1500 store=persistent.

Vérifiez les paramètres de MTU sur les VM utilisant des images personnalisées. Il est possible qu'elles respectent la MTU du réseau VPC, mais il se peut également qu'elles aient été définies sur une valeur fixe.

Pour minimiser les connexions réseau imprévisibles, Google Cloud vous recommande de modifier la MTU d'un réseau VPC en procédant comme suit :

  1. Arrêtez toutes les VM du réseau VPC.
  2. Modifiez la MTU du réseau VPC.
  3. Démarrez toutes les VM du réseau VPC. Les VM Linux utilisant l'environnement invité Google et les VM qui définissent la MTU à l'aide de l'option 26 du protocole DHCP définissent correctement la MTU au démarrage.
  4. Configurez les VM et VM Windows qui utilisent une configuration MTU fixe pour qu'elles utilisent la nouvelle valeur de MTU.

Migrer des services vers un autre réseau de MTU

Vous pouvez décider de migrer des services vers de nouvelles VM dans un nouveau réseau plutôt que de modifier la MTU d'un réseau existant. Dans ce cas, vous disposez peut-être d'un serveur, tel qu'un serveur de base de données, qui doit être accessible à toutes les VM pendant la migration. Si tel est le cas, l'approche générale suivante peut vous aider à effectuer la migration correctement :

  1. Créez le réseau avec la nouvelle MTU.
  2. Créez les règles de pare-feu et les routes nécessaires dans le nouveau réseau.
  3. Créez une VM avec plusieurs interfaces réseau dans l'ancien réseau. Une interface se connecte au nouveau réseau en utilisant la nouvelle MTU, et l'autre se connecte à l'ancien réseau à l'aide de l'ancienne MTU.
  4. Configurez cette nouvelle VM en tant que serveur secondaire pour la VM existante.
  5. Faites basculer le serveur principal vers le serveur secondaire.
  6. Créez des VM dans le nouveau réseau. Vous pouvez les créer de zéro, à partir d'une image existante, ou créer un instantané des VM existantes et l'utiliser pour renseigner les nouveaux disques persistants.
  7. Configurez ces VM pour qu'elles utilisent le serveur opérationnel.
  8. Migrez le trafic vers les nouvelles VM.
  9. Si vous avez l'intention de supprimer l'ancien réseau, créez un nouveau serveur dans le nouveau réseau, synchronisez-le avec le serveur existant et basculez vers celui-ci.
  10. Supprimez l'ancien serveur et l'ancien réseau.

Conséquences des MTU non concordantes

Une MTU non concordante est définie comme deux instances de VM communicantes qui possèdent des paramètres de MTU différents. Dans certains cas, cela peut entraîner des problèmes de connectivité. Les cas spécifiques impliquent l'utilisation d'instances en tant que routeurs et l'utilisation de Kubernetes dans les VM.

Dans la plupart des scénarios, les connexions TCP établies entre des instances avec des MTU différentes réussissent en raison de la négociation MSS, où les deux extrémités d'une connexion acceptent l'utilisation de la MTU inférieure.

Différences de MTU entre réseaux VPC appairés

Pour plus d'informations sur la manière dont l'appairage de réseaux VPC gère les différences entre les MTU des réseaux, consultez la section Considérations relatives aux MTU.

Différences de MTU avec Cloud VPN

Pour plus d'informations sur Cloud VPN et la MTU, consultez la section MTU du tunnel.

Différences de MTU avec Cloud Interconnect

Cloud Interconnect dispose actuellement d'une MTU de 1440.

Si les VM communicantes ont une MTU de 1500, le processus de limitation de la taille MSS réduit la MTU des connexions TCP à 1440, et le trafic TCP se poursuit.

Le processus de limitation de la taille MSS n'affecte pas les paquets UDP. Par conséquent, si le réseau VPC présente une MTU de 1500, les datagrammes UDP qui contiennent plus de 1 412 octets de données (1 412 octets de données UDP + en-tête UDP de 8 octets + en-tête IPv4 de 20 octets = 1440) sont supprimés. Dans ce cas, vous pouvez effectuer l'une des opérations suivantes :

  • Diminuez la MTU du réseau VPC associé à 1 460.
  • Ajustez votre application pour envoyer des paquets UDP plus petits.

Performances du réseau

Latence

Les mesures de latence interrégionale pour les réseaux Google Cloud sont indiquées dans notre tableau de bord en direct. Le tableau de bord présente la méthodologie et les métriques de performances de débit et de latence interrégionale médianes de Google Cloud permettant de reproduire ces résultats à l'aide de PerfKit Benchmarker.

Google Cloud mesure généralement les latences aller-retour inférieures à 55 microsecondes au 50e centile et les latences de queue inférieures à 80 microsecondes au 99e centile entre les instances de VM c2-standard-4 de la même zone.

Google Cloud mesure généralement les latences aller-retour inférieures à 45 microsecondes au 50e centile et les latences de queue inférieures à 60 microsecondes au 99e centile entre les instances de VM c2-standard-4 du même réseau à faible latence (stratégie d'emplacement "compacte"). La stratégie d'emplacement compacte permet de réduire la latence du réseau en garantissant que les VM se trouvent physiquement dans le même réseau à faible latence.

Méthodologie : la latence intrazone est surveillée via un vérificateur de boîte noire qui exécute en permanence un test TCP_RR netperf entre deux VM de type c2 dans chaque zone où ces instances sont disponibles. Le vérificateur collecte les résultats P50 et P99 qui serviront à la configuration avec et sans stratégie d'emplacement compacte. Le test TCP_RR mesure les performances des requêtes/réponses en mesurant le taux de transaction. Si vos applications nécessitent une latence optimale, nous vous recommandons d'utiliser des instances c2.

Perte de paquets

Google Cloud effectue le suivi de la perte de paquets interrégionale en mesurant régulièrement la perte aller-retour entre toutes les régions. Nous visons une moyenne mondiale de ces mesures inférieure à 0,01 %.

Méthodologie : un vérificateur de boîte noire VM à VM surveille la perte de paquets pour chaque paire de zones à l'aide de pings et agrège les résultats dans une seule métrique de perte globale. Cette métrique est suivie sur une période d'un jour.

Étape suivante

  • Consultez la page Utiliser des réseaux VPC pour en savoir plus sur la création, la modification et la suppression des réseaux VPC.