Google ACE: Réseautage VPC, connectivité et gestion du trafic — Guide d'étude

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Fait partie du Google Associate Cloud Engineer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La mise en réseau Virtual Private Cloud (VPC) sur Google Cloud fournit des primitives réseau mondiales, définies par logiciel, avec un contrôle granulaire de l’adressage, du routage, de la sécurité et de la gestion du trafic. Cette section se concentre sur des sujets pratiques de conception et d’exploitation que vous utiliserez pour construire des réseaux résilients, sécurisés et observables qui interconnectent les services Google Cloud, les environnements sur site (on-premises) et l’Internet public.

Architecture VPC de base et planification des adresses IP

Réseaux VPC et sous-réseaux
- Un VPC est une ressource globale ; ses sous-réseaux (subnets) sont régionaux et peuvent s’étendre sur plusieurs zones. Les instances dans n’importe quelle zone de la région peuvent utiliser un sous-réseau.
- Utilisez des VPC en mode personnalisé (custom mode) pour la production. Le mode automatique (auto mode) pré-crée un sous-réseau par région en utilisant un ensemble prédéfini de plages CIDR, ce qui peut entraîner des contraintes d’adresses IP qui se chevauchent, un gaspillage d’espace d’adressage et des difficultés de refactorisation lors de l’expansion.
- Les plages d’adresses IP secondaires sur les sous-réseaux permettent d’attribuer des adresses IP aux Pods/Services GKE et des adresses IP alias aux VM. Planifiez les CIDR primaires et secondaires à l’avance pour éviter d’avoir à renuméroter.
Planification des adresses IP
- Choisissez un espace d’adressage RFC1918 sans chevauchement pour tous les VPC actuels et futurs et les réseaux sur site que vous pourriez connecter. Réservez des blocs pour la croissance future des régions et des services.
- Dimensionnez correctement les sous-réseaux (par ex., /24 à /20) pour la croissance et évitez les plages trop grandes qui compliquent les ACL et les diagnostics.
- Documentez l’utilisation des adresses IP : plages primaires pour les charges de travail (workloads), plages secondaires pour GKE, et blocs réservés pour les pools NAT ou les points de terminaison de service.
Exemple

undefined

Routage, pare-feu et hiérarchie des stratégies

Routes et modes de routage dynamique
- Chaque VPC possède une table de routage composée de routes de sous-réseau générées par le système, de routes par défaut et de routes personnalisées statiques ou dynamiques.
- Mode de routage dynamique :
  - Régional : les routes dynamiques (BGP) apprises via Cloud Router ne sont utilisables que par les ressources de la même région.
  - Global : les routes dynamiques sont utilisables par les ressources de toutes les régions du VPC. Préférez le mode global pour les réseaux hybrides qui doivent atteindre les environnements sur site depuis plusieurs régions.
- Sauts suivants (Next hops) : passerelle Internet par défaut (0.0.0.0/0), tunnel VPN, Cloud Router (BGP), instance (appliance de routage), ou saut suivant de type équilibreur de charge interne pour les appliances virtuelles.
- Priorité des routes : les nombres les plus bas sont préférés. Des priorités mal configurées peuvent créer un trou noir (blackhole) pour le trafic ou le faire fuir vers un saut suivant non intentionnel. Utilisez des conventions claires (par ex., 1000 pour la sortie par défaut, 900 pour les routes plus spécifiques).
Hiérarchie des pare-feu
- Les règles de pare-feu VPC sont avec état (stateful) et évaluées avant la transmission des paquets. Elles existent au niveau du VPC et s’appliquent à tous les sous-réseaux.
- Les stratégies de pare-feu hiérarchiques (rattachées à l’organisation, à un dossier ou à un projet) appliquent des autorisations/refus avant les règles VPC. Utilisez-les pour mettre en œuvre des garde-fous centraux (par ex., refuser les ports d’administration exposés sur Internet).
- Règles implicites : une règle implicite d’autorisation de sortie (allow egress) et une règle implicite de refus d’entrée (deny ingress) existent à la priorité la plus basse ; elles ne peuvent pas être supprimées. Toute connectivité nécessite des autorisations d’entrée explicites.
Règles de pare-feu, tags, comptes de service, tags sécurisés
- Ciblage : utilisez des tags réseau ou des comptes de service pour appliquer des règles à des VM spécifiques ; le ciblage par compte de service offre un contrôle plus strict basé sur l’identité.
- Les tags sécurisés (Secure tags) fournissent des étiquettes gérées de manière centralisée et protégées par IAM pour le ciblage des stratégies ; ils empêchent l’auto-rattachement par les charges de travail et prennent en charge la segmentation zero-trust.
- Journalisation : activez la journalisation du pare-feu de manière sélective pour les règles de grande valeur afin d’équilibrer la visibilité et le coût ; échantillonnez les paquets, pas les charges utiles complètes.
- Modes de défaillance courants : plages sources de vérification de l’état (health check) manquantes, routage asymétrique provoquant la perte de paquets de réponse, plages sources trop larges créant une exposition non intentionnelle.
Exemple

undefined

Équilibrage de charge, adresses IP, DNS et gestion du trafic

Types et comportement de Cloud Load Balancing
- Basés sur un proxy mondial : External HTTP(S), External TCP Proxy, External SSL Proxy. Terminant les connexions client à la périphérie du réseau de Google, ils prennent en charge les VIP mondiales anycast et insèrent des en-têtes (par ex., X-Forwarded-For). L’adresse IP d’origine du client est disponible via les en-têtes ou le protocole PROXY (pour TCP) plutôt que d’être conservée comme source L3.
- Passthrough régional : External Network Load Balancer et Internal TCP/UDP Load Balancer acheminent le trafic au niveau L4 et conservent l’adresse IP du client. À utiliser lorsque vous avez besoin de la visibilité de l’adresse IP source sur les backends sans le protocole PROXY.
- Internal HTTP(S) Load Balancer : proxy L7 régional pour les services internes avec des options de routage avancé et de mTLS.
Services de backend, vérifications de l’état et règles de trafic
- Les services de backend définissent les backends (groupes d’instances, NEG/VM/Endpoint, services GKE), le mode d’équilibrage (UTILIZATION ou RATE), les limites de capacité, l’affinité de session et le drainage des connexions.
- Les vérifications de l’état doivent être autorisées à travers les pare-feu depuis les vérificateurs d’état de Google. Les backends défaillants sont automatiquement supprimés ; des vérifications de l’état mal configurées peuvent provoquer une panne totale.
- Les règles de trafic incluent la localité (région/zone), les backends de débordement et de basculement, et la répartition pondérée du trafic pour les déploiements progressifs sur certains types de LB.
Adresses IP externes et internes, règles de transfert
- Les adresses externes et internes peuvent être éphémères ou statiques réservées. Les adresses externes statiques mondiales sont utilisées par les LB mondiaux ; la plupart des autres sont régionales.
- Les règles de transfert mappent une paire IP:port à une cible (par ex., targetHttpProxy ou service de backend). Choisissez des règles mondiales ou régionales pour correspondre au type de LB ; une incohérence empêche la création.
Cloud DNS
- Zones : les zones publiques se résolvent sur l’internet public ; les zones privées ne sont résolubles qu’à partir des VPC autorisés. Utilisez des enregistrements gérés (A/AAAA, CNAME, TXT, MX, SRV, etc.).
- Split-horizon : créez des zones publiques et privées pour le même domaine afin que les résolveurs internes reçoivent des réponses privées (par ex., l’IP d’un ILB) tandis que les utilisateurs publics obtiennent des adresses IP accessibles depuis internet.
- Transfert DNS privé : utilisez les stratégies Cloud DNS pour le transfert entrant et sortant afin de s’intégrer avec les résolveurs sur site ; utilisez l’appairage DNS entre les VPC pour partager des zones privées sans une connectivité d’appairage complète.
Exemple
- gcloud compute forwarding-rules create web-ilb –region=us-central1 –load-balancing-scheme=INTERNAL_MANAGED –ports=80 –backend-service=web-be

Connectivité hybride et privée

Cloud Router, Cloud NAT et Accès privé à Google
- Cloud Router échange des routes avec les environnements sur site via BGP, annonce les sous-réseaux VPC et importe les préfixes sur site. Utilisez le routage dynamique mondial lorsque plusieurs régions ont besoin d’une accessibilité sur site.
- Cloud NAT fournit une sortie (egress) internet pour les VM privées et les nœuds GKE sans adresses IP externes. Dimensionnez les pools d’adresses IP NAT pour éviter l’épuisement des ports ; surveillez les journaux pour les connexions abandonnées et mettez à l’échelle les adresses en conséquence.
- L’Accès privé à Google (PGA) permet aux VM privées d’atteindre les API Google sans adresses IP externes via le chemin de routage par défaut. Private Service Connect (PSC) pour les API Google fournit des points de terminaison d’adresses IP privées dans votre VPC avec un contrôle par stratégie et évite complètement la sortie publique ; préférez les points de terminaison PSC pour un contrôle de sortie plus strict et un DNS cohérent.
Private Service Connect (services producteur et consommateur)
- Exposez les services internes derrière une pièce jointe de service (service attachment) dans un projet producteur et consommez-les via des points de terminaison privés dans les projets consommateurs. Le mappage DNS et les stratégies d’autorisation explicites contrôlent l’accès. Cela améliore l’isolement par rapport à l’appairage de VPC (VPC Peering) et centralise la publication des services.
Appairage de réseaux VPC (VPC Network Peering), VPC partagé et segmentation
- L’appairage de VPC (VPC Peering) offre une connectivité privée à faible latence entre les VPC. Il est non transitif et n’autorise pas les adresses IP qui se chevauchent. L’importation/exportation facultative de routes personnalisées étend l’accessibilité mais ne crée toujours pas de routage transitif ; planifiez délibérément une architecture en étoile (hub-and-spoke).
- Le VPC partagé (Shared VPC) centralise les sous-réseaux dans un projet hôte pour leur utilisation par les projets de service. Cela permet de centraliser le routage, les pare-feu, le NAT et les LB tout en déléguant l’IAM par application. Combinez avec des pare-feu hiérarchiques et des tags sécurisés pour la segmentation.
- Network Connectivity Center (NCC) fournit un hub pour orchestrer les spokes (VPN, Interconnect, appliance de routeur, spokes VPC) et gérer de manière cohérente les topologies WAN d’entreprise.
Cloud VPN, Cloud Interconnect et BGP
- Cloud VPN : utilisez le VPN haute disponibilité (HA VPN) avec routage dynamique (BGP) pour la disponibilité et le basculement automatique des routes. Construisez deux tunnels par pair sur des interfaces Cloud VPN indépendantes et des appareils/liens sur site distincts lorsque c’est possible.
- Cloud Interconnect : l’interconnexion dédiée (Dedicated Interconnect) fournit des liaisons privées de 10 à 100 Gbit/s ; l’interconnexion partenaire (Partner Interconnect) utilise un fournisseur de services. Pour la résilience, déployez des interconnexions redondantes dans des domaines de disponibilité de périphérie (edge availability domains) diversifiés et utilisez BFD avec BGP là où c’est pris en charge.
- Domaines de défaillance : isolez par région, zone, appareil et fournisseur. Testez régulièrement le basculement ; des chemins asymétriques peuvent perturber les pare-feu stateful sur site.
Exemples
- gcloud compute routers create corp-router –region=us-central1 –network=prod-net –asn=64514
- gcloud compute routers nats create nat-us-central1 –router=corp-router –nat-all-subnet-ip-ranges –auto-allocate-nat-external-ips
- gcloud compute vpn-gateways create ha-gw –region=us-central1 –network=prod-net

Observabilité et Dépannage

Tests de connectivité
- Simuler et vérifier l’accessibilité entre les sources et les destinations à travers les VPC, les environnements sur site (via des liens hybrides) et les équilibreurs de charge. L’outil évalue les routes, les règles de pare-feu et la configuration pour localiser les pertes ou le trafic mal acheminé avant les changements en production.
- Exemple :

undefined

Journaux de flux VPC (VPC Flow Logs)
- Activer au niveau du sous-réseau pour obtenir des informations en temps réel sur les flux à 5-tuples, les octets, les pertes et la latence. Exporter vers Cloud Logging, Pub/Sub ou BigQuery pour l’analyse. Ajuster les niveaux d’échantillonnage et de métadonnées pour contrôler les coûts.
- Cas d’utilisation : valider l’efficacité du pare-feu, détecter l’exfiltration de données, planifier la capacité et surveiller les SLO.
Mise en miroir de paquets (Packet Mirroring)
- Mettre en miroir le trafic des VM ou de GKE vers des points de terminaison collecteurs pour une inspection approfondie des paquets (DPI) ou pour un IDS. Définir la portée de la mise en miroir par sous-réseau, tag ou instance. Comprendre la surcharge de performance et s’assurer que les collecteurs peuvent gérer le volume mis en miroir. Éviter de mettre en miroir le trafic post-NAT lorsque vous avez besoin des en-têtes d’origine.
Patrons de diagnostic courants
- Trou noir (Blackhole) : la route existe mais le chemin de réponse est bloqué par un pare-feu ou un routage asymétrique ; valider avec les Tests de connectivité et les journaux de flux des deux côtés.
- Échecs des vérifications de santé : confirmer que le pare-feu autorise le trafic depuis les vérificateurs de santé et que les backends écoutent sur les bons ports ; tester localement depuis une VM dans le même sous-réseau.
- Épuisement du NAT : rechercher les flux refusés avec le motif « no available NAT ports » ; ajouter plus d’adresses IP NAT ou réduire les limites de ports par VM.

Scénario de problème pratique

Acme Retail exploite une plateforme e-commerce multirégionale avec des backends privés, un point d’entrée web public et un ERP sur site. Ils doivent segmenter les charges de travail, fournir une sortie privée vers les API Google, permettre une accessibilité hybride depuis toutes les régions et renforcer la sécurité tout en maintenant l’observabilité.

Créer un VPC partagé (Shared VPC) en mode personnalisé pour un contrôle centralisé

undefined

Justification : Le mode personnalisé évite les CIDR attribués automatiquement et permet une planification délibérée des adresses IP. Le Shared VPC centralise le routage, les pare-feu et le NAT dans un projet hôte tout en permettant aux projets de service de se déployer en toute sécurité.

Planifier et créer des sous-réseaux avec des plages secondaires pour GKE

undefined

Justification : Des plages primaires et secondaires qui ne se chevauchent pas préviennent les futurs conflits de peering et permettent d’utiliser des adresses IP alias pour GKE sans épuiser les adresses IP.

Définir le routage dynamique du VPC en mode global et déployer Cloud Router

undefined

Justification : Le mode global rend les routes sur site apprises via BGP utilisables depuis toutes les régions, simplifiant l’accessibilité hybride et le basculement (failover).

Établir un HA VPN vers l’environnement sur site et annoncer les sous-réseaux

Créer deux tunnels HA VPN sur des équipements sur site distincts. Utiliser BGP pour échanger les préfixes et permettre un basculement en douceur (graceful failover).
Justification : Les tunnels doubles suppriment les points de défaillance uniques ; BGP fait converger les routes rapidement lors de la maintenance ou des pannes.

Déployer Cloud NAT pour la sortie privée et PSC pour les API Google

undefined

Créer des points de terminaison Private Service Connect pour les API Google et mettre à jour le DNS privé pour mapper les points de terminaison des API vers PSC.
Justification : Le NAT permet une sortie vers Internet sans adresses IP externes pour les VM ; PSC maintient le trafic des API sur des adresses IP privées et sous un contrôle de politique explicite, éliminant les chemins de sortie publics.

Frontend avec un External HTTP(S) Load Balancer global ; services internes via un Internal HTTP(S) Load Balancer

Créer un LB externe global HTTP(S) avec un certificat géré et un service backend pointant vers des backends NEG.
Créer des LB internes régionaux HTTP(S) pour le trafic de service à service avec mTLS entre les microservices.
Justification : Le LB proxy global fournit l’anycast, l’autoscaling et le CDN ; le LB interne de couche 7 (L7) offre un routage riche et une sécurité pour le trafic est-ouest.

Mettre en œuvre des politiques de pare-feu hiérarchiques et un ciblage par identité de charge de travail

Attacher une politique au niveau de l’organisation refusant les ports d’administration depuis Internet ; n’autoriser que les sources des vérifications de santé du LB.
Créer des règles VPC ciblant les comptes de service pour un accès selon le principe de moindre privilège entre les niveaux ; utiliser des tags sécurisés pour la segmentation dynamique.
Justification : La hiérarchie applique des garde-fous de manière centralisée ; le ciblage basé sur l’identité résiste à l’usurpation de tags (tag spoofing) et simplifie l’automatisation.

Configurer Cloud DNS avec un horizon partagé (split-horizon) et le transfert

Créer une zone publique acme.com pour la VIP web, et une zone privée acme.com pour les noms de services internes mappés aux ILB.
Configurer le transfert sortant vers le DNS sur site et le transfert entrant pour que l’environnement sur site puisse résoudre les zones privées.
Justification : L’horizon partagé empêche la fuite de données et assure une résolution de noms correcte en fonction du réseau source ; le transfert intègre les espaces de noms hérités (legacy).

Utiliser les Tests de connectivité, les journaux de flux et la mise en miroir de paquets pour la visibilité

Créer des tests pour les chemins critiques (utilisateur vers le LB web, web vers les services internes, services vers l’ERP sur site).
Activer les journaux de flux sur les sous-réseaux ; exporter vers BigQuery pour l’analyse des tendances. Activer la mise en miroir de paquets temporairement lors de la réponse à un incident.
Justification : La validation proactive et la télémétrie réduisent le MTTR, révèlent les erreurs de configuration et fournissent des informations sur la capacité.

Documenter et tester les scénarios de défaillance

Simuler la perte d’un tunnel VPN, d’une région et d’un MIG backend. Vérifier le basculement BGP, la suppression par la vérification de santé du LB et l’exactitude du DNS.
Justification : Des exercices réguliers (game days) confirment les hypothèses sur la redondance et révèlent la dérive de configuration avant qu’elle ne provoque des pannes.

← Conteneurs · Tous les domaines · Stockage →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →