Google PCNE: Routage, Network Connectivity Center et segmentation — Guide d'étude

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Network 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

Cette section explique le routage, le Network Connectivity Center (NCC) et les modèles de segmentation dans Google Cloud. Elle se concentre sur la manière dont les routes sont créées et sélectionnées, comment interconnecter les VPC et les organisations tout en préservant l’isolation, comment construire des conceptions de transit et d’insertion de services évolutives, et comment valider et contenir les défaillances.

Principes fondamentaux et contrôle du routage

• Types de routes

  • Routes de sous-réseau générées par le système : Une par plage de sous-réseau primaire et secondaire ; toujours les plus prioritaires pour leurs préfixes exacts.
  • Route par défaut vers la passerelle Internet : Créée automatiquement dans les nouveaux VPC ; peut être supprimée ou remplacée.
  • Routes statiques : Préfixes personnalisés avec des sauts suivants (next hops) tels que la passerelle Internet par défaut, une instance spécifique, un équilibreur de charge TCP/UDP interne (ILB) en tant que saut suivant, ou un tunnel Cloud VPN. Les routes basées sur des règles (policy-based routes) ajoutent des conditions de correspondance (tags, comptes de service, protocole/port) et dirigent le trafic vers une instance ou un ILB en tant que saut suivant pour une insertion de services avancée.
  • Routes dynamiques : Apprises via Cloud Router par BGP depuis Cloud VPN ou Cloud Interconnect. Leur portée est contrôlée par le mode de routage dynamique du VPC (régional ou global).

• Sélection de route

  • Correspondance du préfixe le plus long en premier.
  • Si plusieurs routes ont la même longueur de préfixe, la priorité de route numériquement la plus basse l’emporte (1000 par défaut pour les routes personnalisées). Évitez les chevauchements de préfixes égaux entre les chemins statiques/dynamiques ; concevez pour en préférer un sans ambiguïté.
  • Les égalités au-delà de la priorité sont résolues par des mécanismes de départage internes à la plateforme ; ne vous y fiez pas.

• Choix du saut suivant et insertion de services

  • Pour centraliser la sortie (egress) ou insérer des services L3/L7, dirigez une route statique 0.0.0.0/0 ou des routes basées sur des règles vers un ILB en tant que saut suivant dont les backends sont des appliances virtuelles de réseau (NVA).
  • Lorsque les appliances doivent être contournées pour les API Google par des instances sans adresses IP externes, activez l’Accès Privé à Google (Private Google Access) sur les sous-réseaux et ajoutez des routes statiques personnalisées pour les plages VIP des API Google publiées vers la passerelle Internet par défaut. Cela préserve l’accès privé aux services Google tandis que le reste du trafic de sortie suit le chemin du NGFW.

• Mode de routage dynamique et comportement multi-régional

  • Régional : Les routes apprises par un Cloud Router sont installées uniquement pour les sous-réseaux de la même région.
  • Global : Les routes apprises n’importe où sont installées pour toutes les régions du VPC, permettant une connectivité multi-régionale simple et une charge opérationnelle réduite pour les conceptions en étoile (hub-and-spoke). Pour les utilisateurs et les charges de travail proches de us-east1 et europe-west1, un seul VPC avec des sous-réseaux régionaux et un routage dynamique global leur permet de communiquer en privé sur RFC1918 avec une efficacité optimale.

• Contrôle de l’annonce de routes

  • Cloud Router peut annoncer tous les sous-réseaux ou un ensemble personnalisé de préfixes (y compris une route par défaut) vers l’environnement sur site (on-premises). Contrôlez la sélection du chemin entrant depuis l’environnement sur site à l’aide d’outils BGP standard (MED, AS-path prepending, local preference sur site). Pour une configuration actif/passif (active/standby) vers l’environnement sur site, définissez un MED plus bas sur le chemin principal et un MED plus élevé sur le chemin de secours.
  • Évitez d’annoncer le même préfixe depuis différents pairs sur site avec des ASN différents vers le même Cloud Router ; pour un ECMP à double rattachement (dual-homed) ou un basculement propre, utilisez le même ASN de pair sur les routeurs sur site redondants.

Interconnectivité et segmentation des VPC

• VPC Network Peering

  • Permet une connectivité privée RFC1918 entre les VPC avec une faible latence et sans appliances de plan de données. Il échange les routes de sous-réseau par défaut et peut éventuellement importer/exporter des routes personnalisées (statiques et dynamiques) pour étendre la joignabilité aux ressources derrière Cloud VPN/Interconnect. Il n’y a pas de routage transitif : les routes apprises d’un pair ne sont pas ré-exportées vers un autre pair.
  • Modes de défaillance et limites : Pas de CIDR qui se chevauchent ; les règles de pare-feu restent indépendantes pour chaque VPC ; la bande passante est élevée mais ne remplace pas les équilibreurs de charge ; le routage asymétrique à travers un maillage de peerings n’est pas pris en charge. Pour connecter trois VPC en triangle, configurez un maillage complet de paires de peering ; Ventes↔Finance et Marketing↔Finance n’activent pas la connexion Ventes↔Marketing à moins que cette paire ne soit également en peering.
  • Planification des adresses : Lors du peering avec un VPC en mode automatique (qui réserve 10.128.0.0/9), créez le VPC pair en mode personnalisé avec un CIDR qui ne se chevauche pas, tel que 10.0.0.0/9.

• Shared VPC et connectivité multi-projets

  • Un projet hôte possède le VPC ; les projets de service se rattachent à des sous-réseaux sélectionnés. Cela centralise la mise en réseau et la connectivité hybride (Cloud Routers, Cloud NAT, Interconnect) tout en permettant une propriété déléguée des applications par projet. Placez les rattachements VLAN et les Cloud Routers pour Dedicated Interconnect dans le projet hôte afin de fournir une connectivité sur site centralisée et économique à tous les projets de service.
  • Moindre privilège : Les administrateurs réseau (Network Admins) gèrent le routage et les sous-réseaux ; les administrateurs de sécurité (Security Admins) gèrent les règles et les stratégies de pare-feu. Si vous ne pouvez pas mettre à jour les pare-feu avec le rôle Network Admin, demandez le rôle Security Admin dans le périmètre du VPC partagé (Shared VPC).
  • Segmentation : Ne partagez que les sous-réseaux spécifiques requis par un projet de service. Cela correspond aux bonnes pratiques de Google pour contrôler étroitement l’exposition des routes entre la Production et la Pré-production (Staging).

• Contrôles d’isolation du réseau

  • Limites du VPC : Pas de routage entre les VPC sans peering explicite, VPN ou Private Service Connect. Utilisez des VPC distincts pour les départements ou les locataires (tenants) qui doivent être entièrement isolés ; n’effectuez un peering que pour ceux qui ont besoin de connectivité afin de minimiser la charge opérationnelle.
  • Stratégies de pare-feu : Utilisez des stratégies de pare-feu hiérarchiques au niveau de l’organisation/du dossier pour des garde-fous cohérents et des règles par VPC pour les exceptions locales. La configuration par défaut (refus en entrée/autorisation en sortie) peut être renforcée.
  • Périmètres : Utilisez VPC Service Controls pour restreindre l’accès aux API Google et atténuer les risques d’exfiltration de données entre les projets et les réseaux.
  • Exposition IPv6 : Pour un accès public IPv6, assignez une adresse IPv6 à un équilibreur de charge HTTP(S) externe et global en frontal de votre service. Les backends restent privés.

Network Connectivity Center et architectures de transit

• Hub-and-spoke avec NCC

  • Le hub fournit un plan de contrôle pour le routage entre les spokes. Les spokes incluent les rattachements VLAN (Interconnect), les tunnels HA VPN, les spokes d’appliance de routeur et les spokes VPC compatibles pour le transfert de données de site à site. Les tables de routage du NCC contrôlent quels préfixes sont importés/exportés et quels spokes les reçoivent, permettant une segmentation précise.
  • Le transfert de données de site à site permet aux sites sur site (on-premise) de se joindre mutuellement via le réseau backbone de Google en utilisant le hub comme point de transit, réduisant le besoin de transit tiers et simplifiant les opérations.

• Spokes d’appliance de routeur et NVA tierces

  • Les spokes d’appliance de routeur intègrent des routeurs/pare-feu virtuels hébergés sur Compute Engine en tant que services de transit ou en ligne (inline). Utilisez un ILB comme prochain saut (next hop) pour assurer la mise à l’échelle et le basculement avec vérification de l’état sur plusieurs appliances.
  • Conception HA : Déployez au moins deux appliances dans des zones différentes ; placez-les derrière un ILB avec un MIG si possible ; activez le transfert IP (IP forwarding) sur les instances ; utilisez le pilotage symétrique (symmetric steering) avec un ILB comme prochain saut ; répartissez la charge à l’aide de routes basées sur des règles (policy-based routes) fondées sur des tags ou des comptes de service.
  • Compromis entre débit et défaillance : Les NVA sont limitées par le type d’instance et la bande passante de la carte réseau (NIC) ; planifiez une mise à l’échelle horizontale. Une défaillance de l’appliance ou de la vérification de l’état déclenche le retrait de l’ILB et un basculement rapide, mais assurez-vous que les minuteurs de convergence de route et les seuils de l’état de santé sont ajustés pour éviter les instabilités (flaps).

• Compromis des topologies de transit

  • Hub-and-spoke avec NCC : Politique centrale, haute scalabilité, contrôle clair du rayon d’impact (blast-radius) ; nécessite une conception des tables de routage et une intention d’import/export.
  • Peering en maillage complet (full mesh) : Simple pour un petit nombre de VPC, pas de transit central, mais se met mal à l’échelle et ne peut pas fournir de transitivité ou d’insertion de service.
  • Sortie centralisée (egress) : Application simple de la sécurité via un NGFW ou un NAT unique ; peut ajouter de la latence et devenir un goulot d’étranglement ; atténuez avec des points de sortie régionaux et l’autoscaling.
  • VPN en maillage avec des Cloud Routers : Flexible et rapide à déployer ; la charge opérationnelle augmente avec le nombre de pairs ; envisagez d’utiliser NCC pour consolider.

• Considérations sur Cloud VPN

  • Si l’équipement sur site (on-premise) ne prend pas en charge BGP, utilisez un Cloud VPN basé sur des règles (policy-based) avec des routes statiques et des sélecteurs de trafic soigneusement délimités ; planifiez une migration ultérieure vers HA VPN avec BGP pour minimiser la charge administrative à long terme.
  • Pour les tunnels actif/passif (active/standby) vers l’environnement sur site, manipulez le MED ou l’AS-path sur site. Pour deux routeurs sur site se connectant à un seul Cloud Router, préférez des ASN de pairs identiques pour permettre l’installation des deux chemins et l’ECMP ; l’utilisation d’ASN de pairs différents entraîne généralement la sélection d’un seul chemin.

Opérations : validation, analyse et confinement des pannes

• Validation de la connectivité et analyse des routes

  • Utilisez les Connectivity Tests du Network Intelligence Center pour tracer le chemin des données à travers les VM, les équilibreurs de charge, le peering de VPC, Cloud VPN et Interconnect, en validant les règles de pare-feu et les routes.
  • Analysez les routes effectives par VM/sous-réseau pour confirmer les sauts suivants et les préfixes dynamiques ; vérifiez que la portée du mode de routage dynamique correspond à l’intention.
  • Pour les problèmes de performance ou d’expérience utilisateur, préférez l’équilibrage de charge HTTP(S) global pour réduire la latence pour les utilisateurs du monde entier grâce à une entrée anycast et une terminaison en périphérie ; les équilibreurs de charge réseau sont régionaux et n’améliorent pas la latence globale.

• Confinement des pannes et réduction du rayon d’impact

  • Segmentez par VPC, tables de routage NCC et sous-réseaux Shared VPC par projet pour empêcher la propagation involontaire des pannes ou des erreurs de configuration.
  • Évitez les dépendances transitives via le peering ; lorsque le transit est nécessaire, utilisez NCC et un contrôle des importations/exportations pour limiter la joignabilité.
  • Utilisez des politiques de pare-feu centralisées au niveau de l’organisation pour les autorisations/refus de base et des politiques locales pour les exceptions applicatives ; testez les changements avec les Connectivity Tests.
  • Lorsque la sécurité en ligne est requise, déployez un ILB comme saut suivant avec des vérifications de l’état et un routage basé sur des politiques pour un basculement en douceur. Assurez-vous que les API Google critiques sont joignables via Private Google Access ou Cloud NAT sans dépendre d’adresses IP externes.
  • Surveillez les sessions BGP et les changements de routes ; standardisez les métriques (MED, local preference) et les plans d’adressage pour éviter l’oscillation des routes et les flux asymétriques.

• Exemples de configurations courtes

  • Créer une route statique pour diriger le trafic à travers un ILB en ligne :

undefined

• Préférer l’un des deux chemins BGP entrants vers l’environnement sur site en utilisant le MED (sur le routeur sur site) :

undefined

-

undefined

-

undefined

-

undefined

Scénario de problème pratique

Acme Retail opère dans une organisation Google Cloud multi-projets avec deux populations d’utilisateurs près de us-east1 et europe-west1. Ils ont besoin d’une communication privée et à faible coût entre les charges de travail à travers les régions, d’une connectivité centralisée vers l’environnement sur site et d’un filtrage d’URL en ligne pour le trafic sortant vers Internet, tout en gardant le département Finance isolé de l’Ingénierie.

1. Construire un unique Shared VPC dans un projet hôte avec des sous-réseaux régionaux dans us-east1 et europe-west1, et définir le mode de routage dynamique sur global.

• Justification : Un seul VPC permet une communication RFC1918 directe entre les régions sans la surcharge du peering. Le routage dynamique global installe les routes hybrides apprises dans toutes les régions, simplifiant les opérations et assurant des flux intra-VPC efficaces.

2. Partager uniquement les sous-réseaux requis avec chaque projet de service ; placer la Finance et l’Ingénierie dans des projets de service distincts.

• Justification : Le partage au niveau du sous-réseau fournit une segmentation organisationnelle et minimise l’exposition involontaire des routes. La Finance reste isolée simplement en ne partageant pas les sous-réseaux de l’Ingénierie et grâce à des portées de politiques de pare-feu distinctes.

3. Terminer le Dedicated Interconnect dans le projet hôte et y attacher des Cloud Routers ; n’annoncer que les préfixes nécessaires en utilisant des annonces personnalisées.

• Justification : La connectivité hybride centralisée réduit les coûts et la complexité tout en gardant le contrôle sur ce qui atteint l’environnement sur site. Les annonces personnalisées empêchent une surexposition et contiennent le rayon d’impact.

4. Insérer une appliance de filtrage d’URL de couche 7 en ligne derrière un équilibreur de charge interne TCP/UDP régional ; diriger le trafic sortant avec une route statique 0.0.0.0/0 vers le saut suivant ILB dans chaque région.

• Justification : Le saut suivant ILB ainsi que les vérifications de l’état fournissent une insertion de service à haute disponibilité avec des flux symétriques à travers les appliances. Les routes statiques avec une priorité plus élevée que celle par défaut garantissent que tout le trafic sortant est filtré.

5. S’assurer que les instances sans adresses IP externes peuvent atteindre directement les API Google : activer Private Google Access sur tous les sous-réseaux et ajouter des routes statiques pour les plages VIP des API Google vers la passerelle Internet par défaut pour contourner l’appliance.

• Justification : Private Google Access préserve l’accès privé à BigQuery et Pub/Sub ; les routes personnalisées empêchent le hairpinning inutile à travers le filtre, réduisant ainsi les coûts et la latence.

6. Garder la Finance isolée : refuser le trafic inter-projets dans les politiques de pare-feu hiérarchiques et ne pas configurer de peering entre la Finance et l’Ingénierie. Là où une collaboration Ingénierie↔Analytique est nécessaire, créer une paire de VPC en peering dédiée avec des CIDR non superposés.

• Justification : Les frontières des VPC, l’absence de peering et les politiques de pare-feu au niveau de l’organisation renforcent l’isolement. Le peering ciblé offre une faible surcharge opérationnelle pour une connectivité départementale spécifique sans transitivité.

7. Valider et surveiller : utiliser les Connectivity Tests pour vérifier la joignabilité inter-régionale et l’insertion de l’appliance ; surveiller la santé BGP du Cloud Router et les tables de routage ; implémenter le MED sur les routeurs sur site pour un basculement actif/passif si plusieurs tunnels existent.

• Justification : La validation proactive détecte tôt les erreurs de configuration. Les contrôles BGP maintiennent les chemins sur site déterministes pendant la maintenance ou les pannes, tandis que la télémétrie de NCC/Cloud Router accélère le dépannage.

Cette conception répond aux exigences d’Acme Retail avec un coût minimal et une haute efficacité : routage privé multi-régional dans un seul VPC, connectivité hybride centralisée, insertion de service contrôlée et segmentation organisationnelle forte.

← Connectivité privée vers Google et les services gérés · Tous les domaines · GKE →

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

Parcourir Google →