Google ACE: VPC-Netzwerke, Konnektivität und Traffic-Management — Lernleitfaden

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

Teil des Google Associate Cloud Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Übersicht

Das Virtual Private Cloud (VPC)-Networking in Google Cloud bietet softwaredefinierte, globale Netzwerkprimitive mit granularer Kontrolle über Adressierung, Routing, Sicherheit und Traffic-Management. Dieser Abschnitt konzentriert sich auf praxisnahe Design- und Betriebsthemen, die Sie zum Aufbau resilienter, sicherer und beobachtbarer Netzwerke benötigen, welche Google Cloud-Dienste, lokale Umgebungen (On-Premises) und das öffentliche Internet miteinander verbinden.

VPC-Kernarchitektur und IP-Planung

VPC-Netzwerke und Subnetze
- Ein VPC ist eine globale Ressource; seine Subnetze sind regional und können sich über Zonen erstrecken. Instanzen in jeder Zone der Region können ein Subnetz nutzen.
- Verwenden Sie für Produktionsumgebungen VPCs im benutzerdefinierten Modus (Custom Mode). Der Auto-Modus erstellt vorab ein Subnetz pro Region unter Verwendung eines vordefinierten Satzes von CIDR-Bereichen und kann zu überlappenden IP-Einschränkungen, verschwendetem Adressraum und schmerzhaftem Refactoring bei Erweiterungen führen.
- Sekundäre IP-Bereiche in Subnetzen ermöglichen GKE Pod/Service-IPs und Alias-IPs für VMs. Planen Sie primäre und sekundäre CIDRs im Voraus, um eine Neunummerierung zu vermeiden.
IP-Adressplanung
- Wählen Sie nicht überlappenden RFC1918-Adressraum für alle gegenwärtigen und zukünftigen VPCs und On-Prem-Netzwerke, die Sie möglicherweise verbinden. Reservieren Sie Wachstumsblöcke für zukünftige Regionen und Dienste.
- Dimensionieren Sie Subnetze passend für zukünftiges Wachstum (z. B. /24 bis /20) und vermeiden Sie übermäßig große Bereiche, die ACLs und die Diagnose erschweren.
- Dokumentieren Sie die IP-Nutzung: primäre Bereiche für Workloads, sekundäre Bereiche für GKE und reservierte Blöcke für NAT-Pools oder Dienstendpunkte.
Beispiel

undefined

Routing, Firewalls und Richtlinienhierarchie

Routen und dynamische Routing-Modi
- Jedes VPC hat eine Routing-Tabelle, die aus systemgenerierten Subnetz-Routen, Standardrouten und benutzerdefinierten statischen oder dynamischen Routen besteht.
- Dynamischer Routing-Modus:
  - Regional: Dynamische (BGP-)Routen, die über Cloud Router gelernt werden, sind nur für Ressourcen in derselben Region nutzbar.
  - Global: Dynamische Routen sind für Ressourcen in allen Regionen des VPC nutzbar. Bevorzugen Sie den globalen Modus für hybride Netzwerke, die von mehreren Regionen aus auf On-Prem-Systeme zugreifen müssen.
- Next Hops: Standard-Internet-Gateway (0.0.0.0/0), VPN-Tunnel, Cloud Router (BGP), Instanz (Routing-Appliance) oder interner Load Balancer als Next Hop für virtuelle Appliances.
- Routenpriorität: Niedrigere Zahlen werden bevorzugt. Falsch konfigurierte Prioritäten können Traffic „blackholen“ (ins Leere leiten) oder an einen unbeabsichtigten Next Hop weiterleiten. Verwenden Sie klare Konventionen (z. B. 1000 für den Standard-Egress, 900 für spezifischere Routen).
Firewall-Hierarchie
- VPC-Firewallregeln sind zustandsbehaftet (stateful) und werden vor der Paketweiterleitung ausgewertet. Sie existieren auf VPC-Ebene und gelten für alle Subnetze.
- Hierarchische Firewall-Richtlinien (angehängt an Organisation, Ordner oder Projekt) erzwingen Erlauben/Verweigern vor den VPC-Regeln. Nutzen Sie sie, um zentrale Leitplanken zu implementieren (z. B. das Sperren von im Internet exponierten Admin-Ports).
- Implizite Regeln: Eine implizite Regel für ausgehenden Traffic (Allow Egress) und eine für eingehenden Traffic (Deny Ingress) existieren mit der niedrigsten Priorität; sie können nicht entfernt werden. Jede Konnektivität erfordert explizite Erlaubnisregeln für eingehenden Traffic (Ingress Allows).
Firewallregeln, Tags, Service-Konten, sichere Tags
- Targeting: Verwenden Sie Netzwerk-Tags oder Service-Konten, um Regeln auf bestimmte VMs anzuwenden; das Targeting über Service-Konten bietet eine engere, identitätsbasierte Kontrolle.
- Sichere Tags (Secure Tags) bieten zentral verwaltete, IAM-geschützte Labels für das Richtlinien-Targeting; sie verhindern, dass Workloads sich selbst Tags zuweisen, und unterstützen eine Zero-Trust-Segmentierung.
- Logging: Aktivieren Sie das Firewall-Logging selektiv für besonders wichtige Regeln, um Sichtbarkeit und Kosten auszugleichen; protokollieren Sie Paket-Samples, nicht die vollständigen Payloads.
- Häufige Fehlerquellen: fehlende Quellbereiche für Health Checks, asymmetrisches Routing, das zum Verwerfen von Antwortpaketen führt, oder zu weit gefasste Quellbereiche, die eine unbeabsichtigte Gefährdung verursachen.
Beispiel

undefined

Beobachtbarkeit und Fehlerbehebung

Konnektivitätstests
- Simulieren und überprüfen Sie die Erreichbarkeit zwischen Quellen und Zielen über VPCs, On-Premises (über Hybrid-Verbindungen) und Load Balancer hinweg. Das Tool wertet Routen, Firewall-Regeln und Konfigurationen aus, um verworfene Pakete oder fehlgeleiteten Traffic vor Produktionsänderungen zu lokalisieren.
- Beispiel:

undefined

VPC Flow Logs
- Auf Subnetz-Ebene aktivieren, um Echtzeit-Einblicke in 5-Tupel-Flows, Bytes, verworfene Pakete und Latenz zu erhalten. Exportieren Sie die Daten zur Analyse nach Cloud Logging, Pub/Sub oder BigQuery. Passen Sie das Sampling und die Metadaten-Ebenen an, um die Kosten zu steuern.
- Anwendungsfälle: Validierung der Firewall-Effektivität, Erkennung von Exfiltration, Kapazitätsplanung und SLO-Überwachung.
Packet Mirroring
- Spiegeln Sie den Traffic von VMs oder GKE an Kollektor-Endpunkte für Deep Packet Inspection oder IDS. Definieren Sie den Geltungsbereich der Spiegelung nach Subnetz, Tag oder Instanz. Berücksichtigen Sie den Performance-Overhead und stellen Sie sicher, dass die Kollektoren das gespiegelte Volumen verarbeiten können. Vermeiden Sie das Spiegeln von Traffic nach der NAT-Übersetzung, wenn Sie die ursprünglichen Header benötigen.
Gängige Diagnosemuster
- Blackhole: Eine Route existiert, aber der Antwortpfad ist durch eine Firewall oder asymmetrisches Routing blockiert; validieren Sie dies mit Konnektivitätstests und Flow Logs auf beiden Seiten.
- Fehlgeschlagene Health Checks: Bestätigen Sie, dass die Firewall Traffic von den Health-Checkern zulässt und die Backends auf den richtigen Ports lauschen; testen Sie lokal von einer VM im selben Subnetz aus.
- NAT-Erschöpfung: Suchen Sie nach abgelehnten Flows mit dem Grund „no available NAT ports“; fügen Sie weitere NAT-IPs hinzu oder reduzieren Sie die Port-Obergrenzen pro VM.

Praktisches Problemszenario

Acme Retail betreibt eine E-Commerce-Plattform über mehrere Regionen mit privaten Backends, einem öffentlichen Web-Zugang und einem On-Premises-ERP. Das Unternehmen muss Workloads segmentieren, privaten Egress zu Google-APIs bereitstellen, hybride Erreichbarkeit aus allen Regionen ermöglichen und die Sicherheit härten, während die Beobachtbarkeit aufrechterhalten wird.

Erstellen einer benutzerdefinierten Shared VPC für zentrale Steuerung

undefined

Begründung: Der benutzerdefinierte Modus vermeidet automatisch zugewiesene CIDRs und ermöglicht eine gezielte IP-Planung. Eine Shared VPC zentralisiert Routing, Firewalls und NAT in einem Host-Projekt, während Service-Projekte sicher bereitgestellt werden können.

Planen und Erstellen von Subnetzen mit sekundären Bereichen für GKE

undefined

Begründung: Nicht überlappende primäre und sekundäre Bereiche verhindern zukünftige Peering-Konflikte und ermöglichen Alias-IPs für GKE ohne IP-Erschöpfung.

Dynamisches VPC-Routing auf global setzen und Cloud Router bereitstellen

undefined

Begründung: Der globale Modus macht über BGP gelernte On-Premises-Routen aus allen Regionen nutzbar, was die hybride Erreichbarkeit und das Failover vereinfacht.

HA VPN zu On-Premises einrichten und Subnetze ankündigen

Erstellen Sie zwei HA VPN-Tunnel über verschiedene On-Premises-Geräte. Verwenden Sie BGP, um Präfixe auszutauschen und ein reibungsloses Failover zu ermöglichen.
Begründung: Zwei Tunnel beseitigen Single Points of Failure; BGP konvergiert Routen bei Wartungsarbeiten oder Ausfällen schnell.

Cloud NAT für privaten Egress und PSC für Google-APIs bereitstellen

undefined

Erstellen Sie Private Service Connect-Endpunkte für Google-APIs und aktualisieren Sie das private DNS, um API-Endpunkte auf PSC abzubilden.
Begründung: NAT ermöglicht Internet-Egress ohne externe VM-IPs; PSC hält den API-Traffic auf privaten IPs und unter expliziter Richtlinienkontrolle, wodurch öffentliche Egress-Pfade eliminiert werden.

Frontend mit globalem externen HTTP(S) Load Balancer; interne Dienste über internen HTTP(S) Load Balancer

Erstellen Sie einen globalen externen HTTP(S) LB mit einem verwalteten Zertifikat und einem Backend-Dienst, der auf NEG-Backends verweist.
Erstellen Sie regionale interne HTTP(S) LBs für Service-zu-Service-Traffic mit mTLS zwischen den Microservices.
Begründung: Der globale Proxy-LB bietet Anycast, Autoscaling und CDN; der interne L7-LB bietet umfangreiches Routing und Sicherheit für Ost-West-Traffic.

Implementieren von hierarchischen Firewall-Richtlinien und Workload-Identity-Targeting

Hängen Sie eine Richtlinie auf Organisationsebene an, die Admin-Ports aus dem Internet verweigert; erlauben Sie nur die Quellen der LB-Health-Checks.
Erstellen Sie VPC-Regeln, die auf Service-Konten abzielen, um Least-Privilege-Zugriff zwischen den Tiers zu gewährleisten; verwenden Sie sichere Tags für die dynamische Segmentierung.
Begründung: Die Hierarchie erzwingt zentral Leitplanken (Guardrails); identitätsbasiertes Targeting ist resistent gegen Tag-Spoofing und vereinfacht die Automatisierung.

Cloud DNS mit Split-Horizon und Weiterleitung konfigurieren

Erstellen Sie eine öffentliche Zone acme.com für die Web-VIP und eine private Zone acme.com für interne Dienstnamen, die auf ILBs abgebildet werden.
Konfigurieren Sie eine ausgehende Weiterleitung zum On-Premises-DNS und eine eingehende Weiterleitung, damit On-Premises private Zonen auflösen kann.
Begründung: Split-Horizon verhindert Datenlecks und stellt die korrekte Namensauflösung basierend auf dem Quellnetzwerk sicher; die Weiterleitung integriert bestehende Namespaces.

Connectivity Tests, Flow Logs und Packet Mirroring für Transparenz nutzen

Erstellen Sie Tests für kritische Pfade (Benutzer zum Web-LB, Web zu internen Diensten, Dienste zum On-Premises-ERP).
Aktivieren Sie Flow Logs auf Subnetzen; exportieren Sie sie zur Trendanalyse nach BigQuery. Aktivieren Sie Packet Mirroring vorübergehend während der Reaktion auf einen Vorfall.
Begründung: Proaktive Validierung und Telemetrie verkürzen die MTTR, decken Fehlkonfigurationen auf und liefern Einblicke in die Kapazität.

Ausfallszenarien dokumentieren und testen

Simulieren Sie den Verlust eines VPN-Tunnels, einer Region und einer Backend-MIG. Überprüfen Sie das BGP-Failover, die Entfernung durch den LB-Health-Check und die Korrektheit des DNS.
Begründung: Regelmäßige „Game Days“ bestätigen Annahmen über Redundanz und decken Konfigurationsabweichungen auf, bevor sie zu Ausfällen führen.

← Container · Alle Domänen · Speicher →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →