Google PCNE: Routing, Network Connectivity Center und Segmentierung — Lernleitfaden
Teil des Google Professional Cloud Network Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.
Überblick
Dieser Abschnitt erläutert Routing, Network Connectivity Center (NCC) und Segmentierungsmuster in Google Cloud. Er konzentriert sich darauf, wie Routen erstellt und ausgewählt werden, wie VPCs und Organisationen unter Beibehaltung der Isolation miteinander verbunden werden, wie skalierbare Transit- und Service-Insertion-Designs erstellt werden und wie Fehler validiert und eingedämmt werden.
Routing-Grundlagen und -Steuerung
Routentypen
- Systemgenerierte Subnetzrouten: Eine pro primärem und sekundärem Subnetzbereich; werden aufgrund ihrer exakten Präfixe immer am stärksten bevorzugt.
- Standardroute zum Internet-Gateway: Wird in neuen VPCs automatisch erstellt; kann entfernt oder überschrieben werden.
- Statische Routen: Benutzerdefinierte Präfixe mit Next Hops wie dem Standard-Internet-Gateway, einer bestimmten Instanz, einem internen TCP/UDP-Load-Balancer (ILB) als Next Hop oder einem Cloud VPN-Tunnel. Richtlinienbasierte Routen fügen Übereinstimmungsbedingungen (Tags, Dienstkonten, Protokoll/Port) hinzu und leiten den Verkehr für erweiterte Service Insertion zu einer Instanz oder einem ILB-Next-Hop.
- Dynamische Routen: Werden über Cloud Router mittels BGP von Cloud VPN oder Cloud Interconnect gelernt. Ihr Geltungsbereich wird durch den dynamischen Routing-Modus der VPC (regional oder global) gesteuert.
Routenauswahl
- Längstes Präfix hat Vorrang (Longest Prefix Match).
- Wenn mehrere Routen die gleiche Präfixlänge haben, gewinnt die niedrigste numerische Routenpriorität (Standard 1000 für benutzerdefinierte Routen). Vermeiden Sie Überlappungen mit gleichen Präfixen über statische/dynamische Pfade hinweg; entwerfen Sie das System so, dass ein Pfad eindeutig bevorzugt wird.
- Gleichstände jenseits der Priorität werden durch plattforminterne Tie-Breaker aufgelöst; verlassen Sie sich nicht darauf.
Next-Hop-Auswahl und Service Insertion
- Um den Egress-Verkehr zu zentralisieren oder L3/L7-Dienste einzufügen, leiten Sie eine statische 0.0.0.0/0-Route oder richtlinienbasierte Routen auf einen ILB-Next-Hop, dessen Backends Network Virtual Appliances (NVAs) sind.
- Wenn Appliances für Google APIs von Instanzen ohne externe IPs umgangen werden müssen, aktivieren Sie Private Google Access auf den Subnetzen und fügen Sie benutzerdefinierte statische Routen für die veröffentlichten VIP-Bereiche der Google APIs zum Standard-Internet-Gateway hinzu. Dies erhält den privaten Zugriff auf Google-Dienste, während anderer Egress-Verkehr dem NGFW-Pfad folgt.
Dynamischer Routing-Modus und Multi-Region-Verhalten
- Regional: Von einem Cloud Router gelernte Routen werden nur für Subnetze in derselben Region installiert.
- Global: Überall gelernte Routen werden für alle Regionen in der VPC installiert, was eine einfache Multi-Region-Konnektivität und einen reduzierten Betriebsaufwand für Hub-and-Spoke-Designs ermöglicht. Für Benutzer und Workloads in der Nähe von us-east1 und europe-west1 ermöglicht eine einzelne VPC mit regionalen Subnetzen und globalem dynamischem Routing die private Kommunikation über RFC1918 mit optimaler Effizienz.
Steuerung der Routen-Ankündigung (Advertisement)
- Cloud Router kann alle Subnetze oder einen benutzerdefinierten Satz von Präfixen (einschließlich einer Standardroute) an On-Premises-Systeme ankündigen. Steuern Sie die Auswahl des eingehenden On-Prem-Pfades mit Standard-BGP-Tools (MED, AS-Path Prepending, Local Preference on-prem). Für eine Aktiv/Standby-Konfiguration in Richtung On-Premises setzen Sie einen niedrigeren MED auf dem primären Pfad und einen höheren MED auf dem Standby-Pfad.
- Vermeiden Sie es, dasselbe Präfix von verschiedenen On-Prem-Peers mit unterschiedlichen ASNs an denselben Cloud Router anzukündigen; für Dual-Homed ECMP oder sauberes Failover verwenden Sie dieselbe Peer-ASN auf redundanten On-Prem-Routern.
VPC-Verbindungen und Segmentierung
VPC Network Peering
- Ermöglicht private RFC1918-Konnektivität zwischen VPCs mit geringer Latenz und ohne Data-Plane-Appliances. Standardmäßig tauscht es Subnetzrouten aus und kann optional benutzerdefinierte Routen (statisch und dynamisch) importieren/exportieren, um die Erreichbarkeit von Ressourcen hinter Cloud VPN/Interconnect zu erweitern. Es gibt kein transitives Routing: Von einem Peer gelernte Routen werden nicht an einen anderen Peer weiter exportiert.
- Fehlermodi und Grenzen: Keine überlappenden CIDRs; Firewall-Regeln bleiben pro VPC unabhängig; die Bandbreite ist hoch, aber kein Ersatz für Load Balancer; asymmetrisches Routing über Mesh-Peering wird nicht unterstützt. Um drei VPCs in einem Dreieck zu verbinden, konfigurieren Sie ein vollständiges Mesh von Peering-Paaren; Sales↔Finance und Marketing↔Finance ermöglichen keine Verbindung Sales↔Marketing, es sei denn, dieses Paar ist ebenfalls gepeert.
- Adressplanung: Wenn Sie ein Peering mit einer Auto-Mode-VPC (die 10.128.0.0/9 reserviert) durchführen, erstellen Sie den Peer im Custom-Modus mit einem nicht überlappenden CIDR wie z.B. 10.0.0.0/9.
Shared VPC und Multi-Projekt-Konnektivität
- Ein Host-Projekt besitzt die VPC; Dienstprojekte werden an ausgewählte Subnetze angehängt. Dies zentralisiert das Networking und die hybride Konnektivität (Cloud Routers, Cloud NAT, Interconnect) und ermöglicht gleichzeitig die delegierte Anwendungsverantwortung pro Projekt. Platzieren Sie VLAN-Anhänge und Cloud Router für Dedicated Interconnect im Host-Projekt, um allen Dienstprojekten eine kosteneffiziente, zentralisierte On-Prem-Konnektivität bereitzustellen.
- Geringste Rechte (Least Privilege): Netzwerkadministratoren verwalten Routing und Subnetze; Sicherheitsadministratoren verwalten Firewall-Regeln und -Richtlinien. Wenn Sie mit Netzwerkadministrator-Rechten keine Firewalls aktualisieren können, fordern Sie Sicherheitsadministrator-Rechte im Geltungsbereich der Shared VPC an.
- Segmentierung: Geben Sie nur die spezifischen Subnetze frei, die von einem Dienstprojekt benötigt werden. Dies entspricht den Best Practices von Google, die Route Exposure zwischen Produktion und Staging streng zu kontrollieren.
Kontrollen zur Netzwerkisolierung
- VPC-Grenzen: Kein Routing zwischen VPCs ohne explizites Peering, VPN oder Private Service Connect. Verwenden Sie separate VPCs für Abteilungen oder Mandanten, die vollständig isoliert sein müssen; peeren Sie nur diejenigen, die Konnektivität benötigen, um den Betriebsaufwand zu minimieren.
- Firewall-Richtlinien: Verwenden Sie hierarchische Firewall-Richtlinien auf Organisations-/Ordnerebene für konsistente Leitplanken und pro-VPC-Regeln für lokale Ausnahmen. Die Standardeinstellung „Ingress verweigern/Egress erlauben“ kann verschärft werden.
- Perimeter: Verwenden Sie VPC Service Controls, um den Zugriff auf Google APIs einzuschränken und die Risiken der Datenexfiltration über Projekte und Netzwerke hinweg zu mindern.
- IPv6-Exposition: Für den öffentlichen IPv6-Zugriff weisen Sie einem globalen externen HTTP(S)-Load-Balancer, der vor Ihrem Dienst steht, IPv6 zu. Die Backends bleiben privat.
Network Connectivity Center und Transit-Architekturen
NCC Hub-and-Spoke
- Der Hub stellt eine Steuerungsebene (Control Plane) für das Routing zwischen den Spokes bereit. Spokes umfassen VLAN-Anhänge (Interconnect), HA VPN-Tunnel, Router-Appliance-Spokes und unterstützte VPC-Spokes für den Site-to-Site-Datentransfer. NCC-Routentabellen steuern, welche Präfixe importiert/exportiert werden und welche Spokes sie empfangen, was eine präzise Segmentierung ermöglicht.
- Der Site-to-Site-Datentransfer ermöglicht es On-Premises-Standorten, sich gegenseitig über das Backbone von Google zu erreichen, wobei der Hub als Transit fungiert. Dies reduziert den Bedarf an Drittanbieter-Transit und vereinfacht den Betrieb.
Router-Appliance-Spokes und NVAs von Drittanbietern
- Router-Appliance-Spokes binden virtuelle Router/Firewalls, die auf Compute Engine gehostet werden, als Transit- oder Inline-Dienste an. Verwenden Sie ILB als Next Hop, um Skalierbarkeit und ein durch Systemdiagnosen (Health Checks) geprüftes Failover über mehrere Appliances hinweg zu erreichen.
- HA-Design: Stellen Sie mindestens zwei Appliances in verschiedenen Zonen bereit; platzieren Sie diese nach Möglichkeit hinter einem ILB mit einer MIG; aktivieren Sie die IP-Weiterleitung (IP Forwarding) auf den Instanzen; verwenden Sie symmetrisches Steering mit dem ILB als Next Hop; verteilen Sie die Last mithilfe von richtlinienbasierten Routen (Policy-Based Routes), die auf Tags oder Dienstkonten basieren.
- Abwägungen bei Durchsatz und Ausfall: NVAs sind durch den Instanztyp und die NIC-Bandbreite begrenzt; planen Sie für horizontale Skalierung. Ein Ausfall der Appliance oder ein Fehlschlagen der Systemdiagnose löst die Entfernung aus dem ILB und ein schnelles Failover aus. Stellen Sie jedoch sicher, dass die Timer für die Routenkonvergenz und die Schwellenwerte der Systemdiagnosen so abgestimmt sind, dass Flaps (schnelle Routenwechsel) vermieden werden.
Abwägungen bei Transit-Topologien
- Hub-and-Spoke mit NCC: Zentrale Richtlinien, hohe Skalierbarkeit, klare Kontrolle des Blast Radius; erfordert ein durchdachtes Design der Routentabellen und eine klare Absicht für Import/Export.
- Full-Mesh-Peering: Einfach für eine kleine Anzahl von VPCs, kein zentraler Transit, aber schlecht skalierbar und bietet keine Transitivität oder Service Insertion.
- Zentralisierter Egress: Einfache Durchsetzung von Sicherheitsrichtlinien über eine NGFW oder NAT; kann Latenz hinzufügen und zu einem Engpass (Choke Point) werden; Minderung durch regionale Egress-Punkte und Autoscaling.
- Mesh-VPN mit Cloud Routern: Flexibel und schnell bereitzustellen; der Betriebsaufwand steigt mit der Anzahl der Peers; ziehen Sie NCC zur Konsolidierung in Betracht.
Überlegungen zu Cloud VPN
- Wenn das On-Premises-Gerät kein BGP unterstützt, verwenden Sie richtlinienbasiertes (Policy-Based) Cloud VPN mit statischen Routen und sorgfältig eingegrenzten Traffic Selectors; planen Sie eine spätere Migration zu HA VPN mit BGP, um den langfristigen Aufwand zu minimieren.
- Für Aktiv/Standby-Tunnel in Richtung On-Premises manipulieren Sie MED oder den AS-Path auf der On-Premises-Seite. Für zwei On-Premises-Router, die sich mit einem einzigen Cloud Router verbinden, bevorzugen Sie identische Peer-ASNs, um die Installation beider Pfade und ECMP zu ermöglichen; die Verwendung unterschiedlicher Peer-ASNs führt üblicherweise dazu, dass nur ein Pfad ausgewählt wird.
Betrieb: Validierung, Analyse und Eindämmung von Ausfällen
Validierung der Konnektivität und Routenanalyse
- Verwenden Sie die Connectivity Tests des Network Intelligence Center, um den Datenpfad über VMs, Load Balancer, VPC Peering, Cloud VPN und Interconnect zu verfolgen und dabei Firewall-Regeln und Routen zu validieren.
- Analysieren Sie effektive Routen pro VM/Subnetz, um Next Hops und dynamische Präfixe zu bestätigen; überprüfen Sie, ob der Geltungsbereich des dynamischen Routing-Modus mit der Absicht übereinstimmt.
- Bei Leistungs- oder User-Experience-Problemen ist globales HTTP(S) Load Balancing zu bevorzugen, um die Latenz für weltweite Benutzer durch Anycast-Ingress und Edge-Terminierung zu reduzieren; Network Load Balancer sind regional und verbessern nicht die globale Latenz.
Eindämmung von Ausfällen und Reduzierung des Blast Radius
- Segmentieren Sie durch VPCs, NCC-Routentabellen und projektbezogene Shared VPC-Subnetze, um die unbeabsichtigte Ausbreitung von Ausfällen oder Fehlkonfigurationen zu verhindern.
- Vermeiden Sie transitive Abhängigkeiten durch Peering; wo Transit erforderlich ist, verwenden Sie NCC und kontrollierten Import/Export, um die Erreichbarkeit einzuschränken.
- Verwenden Sie zentralisierte Firewall-Richtlinien auf Organisationsebene für grundlegende Deny/Allow-Regeln und lokale Richtlinien für Anwendungs-Ausnahmen; testen Sie Änderungen mit Connectivity Tests.
- Wo Inline-Sicherheit erforderlich ist, stellen Sie einen Next-Hop-ILB mit Health Checks und Policy-Based Routing für ein reibungsloses Failover bereit. Stellen Sie sicher, dass kritische Google APIs über Private Google Access oder Cloud NAT erreichbar sind, ohne auf externe IPs angewiesen zu sein.
- Überwachen Sie BGP-Sitzungen und Routenänderungen; standardisieren Sie Metriken (MED, Local Preference) und Adresspläne, um Routen-Oszillation und asymmetrische Flüsse zu vermeiden.
Kurze Konfigurationsbeispiele
Erstellen einer statischen Route, um den Verkehr durch einen Inline-ILB zu leiten:
undefined
Bevorzugen eines von zwei BGP-Pfaden für eingehenden Verkehr zum On-Prem-Standort mithilfe von MED (On-Prem-Router):
undefined
-
undefined
-
undefined
-
undefined
Praktisches Problemszenario
Acme Retail betreibt eine Google Cloud-Organisation mit mehreren Projekten und zwei Benutzergruppen in der Nähe von us-east1 und europe-west1. Sie benötigen eine private, kostengünstige Kommunikation zwischen Workloads über Regionen hinweg, eine zentralisierte On-Prem-Konnektivität und eine Inline-URL-Filterung für den Internet-Egress, während die Finanzabteilung (Finance) von der Technikabteilung (Engineering) isoliert bleibt.
- Erstellen Sie eine einzelne Shared VPC in einem Host-Projekt mit regionalen Subnetzen in us-east1 und europe-west1 und stellen Sie den dynamischen Routing-Modus auf global ein.
- Begründung: Eine VPC ermöglicht direkte RFC1918-Kommunikation zwischen Regionen ohne Peering-Overhead. Globales dynamisches Routing installiert gelernte hybride Routen in allen Regionen, was den Betrieb vereinfacht und effiziente Intra-VPC-Flüsse sicherstellt.
- Geben Sie nur die erforderlichen Subnetze für jedes Service-Projekt frei; platzieren Sie Finance und Engineering in separaten Service-Projekten.
- Begründung: Die Freigabe auf Subnetz-Ebene ermöglicht eine organisatorische Segmentierung und minimiert die unbeabsichtigte Offenlegung von Routen. Finance bleibt isoliert, indem einfach keine Engineering-Subnetze freigegeben werden und durch separate Geltungsbereiche der Firewall-Richtlinien.
- Terminieren Sie Dedicated Interconnect im Host-Projekt und binden Sie Cloud Router an; kündigen Sie nur die notwendigen Präfixe über Custom Advertisements an.
- Begründung: Zentralisierte hybride Konnektivität reduziert Kosten und Komplexität, während die Kontrolle darüber, was den On-Prem-Standort erreicht, erhalten bleibt. Custom Advertisements verhindern eine übermäßige Offenlegung und begrenzen den Blast Radius.
- Fügen Sie eine Inline-L7-URL-Filter-Appliance hinter einem regionalen internen TCP/UDP Load Balancer ein; leiten Sie den Egress-Verkehr mit einer statischen 0.0.0.0/0-Route zum ILB-Next-Hop in jeder Region.
- Begründung: Der ILB-Next-Hop in Verbindung mit Health Checks bietet eine hochverfügbare Service Insertion mit symmetrischen Flüssen über die Appliances. Statische Routen mit höherer Priorität als die Standardroute stellen sicher, dass der gesamte Egress-Verkehr gefiltert wird.
- Stellen Sie sicher, dass Instanzen ohne externe IPs Google APIs direkt erreichen können: Aktivieren Sie Private Google Access in allen Subnetzen und fügen Sie statische Routen für die VIP-Bereiche der Google APIs zum Standard-Internet-Gateway hinzu, um die Appliance zu umgehen.
- Begründung: Private Google Access erhält den privaten Zugriff auf BigQuery und Pub/Sub; benutzerdefinierte Routen verhindern unnötiges Hairpinning durch den Filter, was Kosten und Latenz reduziert.
- Halten Sie Finance isoliert: Verbieten Sie projektübergreifenden Verkehr in hierarchischen Firewall-Richtlinien und konfigurieren Sie kein Peering zwischen Finance und Engineering. Wo eine Zusammenarbeit zwischen Engineering und Analytics erforderlich ist, erstellen Sie ein dediziertes gepeertes VPC-Paar mit nicht überlappenden CIDRs.
- Begründung: VPC-Grenzen, das Fehlen von Peering und Firewall-Richtlinien auf Organisationsebene erzwingen die Isolation. Gezieltes Peering bietet geringen Betriebsaufwand für spezifische abteilungsübergreifende Konnektivität ohne Transitivität.
- Validieren und überwachen: Verwenden Sie Connectivity Tests, um die Erreichbarkeit zwischen den Regionen und die Appliance-Insertion zu überprüfen; überwachen Sie den BGP-Zustand und die Routentabellen des Cloud Router; implementieren Sie MED auf On-Prem-Routern für ein Aktiv/Standby-Failover, falls mehrere Tunnel existieren.
- Begründung: Proaktive Validierung erkennt Fehlkonfigurationen frühzeitig. BGP-Kontrollen halten On-Prem-Pfade während Wartungsarbeiten oder Ausfällen deterministisch, während die Telemetrie von NCC/Cloud Router die Fehlerbehebung beschleunigt.
Dieses Design erfüllt die Anforderungen von Acme Retail mit minimalen Kosten und hoher Effizienz: privates Multi-Region-Routing in einer VPC, zentralisierte hybride Konnektivität, kontrollierte Service Insertion und starke organisatorische Segmentierung.
← Private Konnektivität zu Google und verwalteten Diensten · Alle Domänen · GKE →
Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Bestehe deine Prüfung →