Virtual Private Cloud(VPC)-Netzwerk – Übersicht

Ein VPC-Netzwerk, manchmal auch nur als "Netzwerk" bezeichnet, ist eine virtuelle Version eines physischen Netzwerks, z. B. eines Netzwerks in einem Rechenzentrum. Es stellt die Verbindung für Ihre Compute Engine-VM-Instanzen, Kubernetes Engine-Cluster, App Engine Flex-Instanzen und andere Projektressourcen her.

Projekte können mehrere VPC-Netzwerke enthalten. Neue Projekte beginnen mit einem default-Netzwerk mit einem Subnetz in jeder Region (Netzwerk im automatischen Modus), es sei denn, Sie haben eine Organisationsrichtlinie erstellt, die dies verhindert.

Spezifikationen

VPC-Netzwerke haben folgende Eigenschaften:

  • VPC-Netzwerke und die damit verknüpften Routen und Firewallregeln sind globale Ressourcen. Sie sind nicht mit einer bestimmten Region oder Zone verknüpft.

  • Subnetze sind regionale Ressourcen. Von jedem Subnetz wird ein Bereich von IP-Adressen definiert. Weitere Informationen zu Netzwerken und Subnetzen finden Sie unter Netzwerke und Subnetze.

  • Der Traffic zu und von den Instanzen kann mit Firewallregeln für Netzwerke gesteuert werden.

  • Die Ressourcen in einem VPC-Netzwerk können abhängig von den geltenden Firewallregeln über interne (private) IPv4-Adressen miteinander kommunizieren. Weitere Informationen finden Sie unter Kommunikation im Netzwerk.

  • Instanzen mit internen IP-Adressen können mit APIs und Diensten von Google kommunizieren. Weitere Informationen finden Sie unter Optionen für den privaten Zugriff.

  • Die Netzwerkverwaltung kann mit IAM-Rollen (IAM = Identitäts- und Zugriffsverwaltung) gesichert werden.

  • Eine Organisation kann eine freigegebene VPC verwenden, um ein VPC-Netzwerk als Teil eines gemeinsamen Hostprojekts zu nutzen. Autorisierte IAM-Mitglieder aus anderen Projekten in derselben Organisation können Ressourcen erstellen, für die Subnetze des freigegebenen VPC-Netzwerks genutzt werden.

  • VPC-Netzwerke können über VPC-Netzwerk-Peering mit anderen VPC-Netzwerken aus anderen Projekten oder Organisationen verbunden werden.

  • VPC-Netzwerke können in Hybridumgebungen über Cloud VPN oder Cloud Interconnect sicher verbunden werden.

  • VPC-Netzwerke unterstützen ausschließlich IPv4-Unicast-Traffic. Sie unterstützen keinen Broadcast-, Multicast- oder IPv6-Traffic innerhalb des Netzwerks: VMs im VPC-Netzwerk können nur an IPv4-Ziele senden und nur Traffic von IPv4-Quellen empfangen. Es ist aber möglich, eine IPv6-Adresse für einen globalen Load-Balancer zu erstellen.

Netzwerke und Subnetze

Jedes VPC-Netzwerk besteht aus mindestens einer verwendbaren IP-Bereichspartition, die als Subnetzwerk oder Subnetz bezeichnet wird. Jedes Subnetz ist einer Region zugeordnet. VPC-Netzwerke selbst haben keine IP-Adressbereiche, die mit ihnen verknüpft sind. Für die Subnetze sind IP-Bereiche definiert.

Ein Netzwerk kann erst verwendet werden, wenn es mindestens ein Subnetz hat. Von Netzwerken im automatischen Modus werden Subnetze in den einzelnen Regionen automatisch erstellt. Benutzerdefinierte Netzwerke enthalten zuerst keine Subnetze, sodass Sie selbst bestimmen können, welche Subnetze erstellt werden sollen. Sie können mehr als ein Subnetz pro Region erstellen. Informationen zu den Unterschieden zwischen Netzwerken im automatischen und benutzerdefinierten Modus finden Sie unter VPC-Netzwerktypen.

Wenn Sie eine Ressource in der GCP erstellen, wählen Sie ein Netzwerk und Subnetz. Für andere Ressourcen als Instanzvorlagen können Sie auch eine Zone oder Region auswählen. Bei der Auswahl einer Zone wird implizit auch die zugehörige übergeordnete Region ausgewählt. Da Subnetze regionale Objekte sind, wird durch die Auswahl der Region für eine Ressource auch festgelegt, für welche Subnetze sie verwendet werden kann:

  • Zur Erstellung einer Instanz gehört die Auswahl einer Zone, eines Netzwerks und eines Subnetzes. Es können nur die in der ausgewählten Region vorhandenen Subnetze ausgewählt werden. Die GCP weist der Instanz aus dem Bereich der verfügbaren Adressen im Subnetz eine IP-Adresse zu.

  • Zur Erstellung einer verwalteten Instanzgruppe gehört die Auswahl einer Zone oder Region (abhängig vom Gruppentyp) und einer Instanzvorlage. Es können nur Instanzvorlagen ausgewählt werden, in denen Subnetze in der ausgewählten Region für die verwaltete Instanzgruppe definiert wurden.

    • Instanzvorlagen sind globale Ressourcen. Zur Erstellung einer Instanzvorlage gehört die Auswahl eines Netzwerks und eines Subnetzes. Wenn Sie ein Netzwerk im automatischen Modus erstellen, können Sie "Automatisches Subnetz" auswählen. Bei dieser Einstellung wird die Subnetzauswahl auf die verfügbaren Subnetze in der ausgewählten Region aller verwalteten Instanzgruppen ausgedehnt, die die Vorlage verwenden, da Netzwerke im automatischen Modus per Definition ein Subnetz in jeder Region haben.
  • Zur Erstellung eines Kubernetes-Container-Clusters gehört die Auswahl einer Zone oder Region (abhängig vom Clustertyp), eines Netzwerks und eines Subnetzes. Es können nur die in der ausgewählten Region vorhandenen Subnetze ausgewählt werden.

Netzwerk- und Subnetzterminologie

Die Begriffe "Subnetz" und "Subnetzwerk" werden synonym verwendet. Sie sind in der GCP Console, in gcloud-Befehlen und in der API-Dokumentation austauschbar.

Modus für Subnetzerstellung

Die GCP bietet zwei Arten von VPC-Netzwerken, die durch ihren Modus für die Subnetzerstellung bestimmt werden:

  • Wenn ein Netzwerk im automatischen Modus erstellt wird, wird darin automatisch ein Subnetz aus jeder Region angelegt. Diese Subnetze verwenden eine Reihe vordefinierter IP-Adressbereiche, die sich innerhalb des CIDR-Blocks 10.128.0.0/9 befinden. Sobald neue GCP-Regionen verfügbar sind, werden mithilfe eines IP-Bereichs aus diesem Block automatisch neue Subnetze in diesen Regionen zu den Netzwerken im automatischen Modus hinzugefügt. Zusätzlich zu den automatisch erstellten Subnetzen können Sie in Regionen, die Sie selbst auswählen, manuell weitere Subnetze zu Netzwerken im automatischen Modus hinzufügen. Dazu verwenden Sie IP-Bereiche außerhalb des Blocks 10.128.0.0/9.

  • Wenn ein Netzwerk im benutzerdefinierten Modus erstellt wird, werden keine Subnetze automatisch erstellt. Diese Art von Netzwerk bietet Ihnen vollständige Kontrolle über die zugehörigen Subnetze und IP-Bereiche. Sie entscheiden, welche Subnetze in den von Ihnen ausgewählten Regionen erstellt werden sollen und welche IP-Bereiche Sie verwenden.

Sie können ein Netzwerk im automatischen Modus in ein Netzwerk im benutzerdefinierten Modus umwandeln. Diese Änderung ist nur in eine Richtung möglich. Netzwerke im benutzerdefinierten Modus können nicht in Netzwerke im automatischen Modus umgewandelt werden. Wenn Sie entscheiden müssen, welcher Netzwerktyp Ihren Anforderungen entspricht, sollten Sie den Abschnitt Überlegungen zu Netzwerken im automatischen Modus durchlesen.

Standardnetzwerk

Sofern Sie diese Option nicht deaktivieren, beginnt jedes neue Projekt mit einem default-Netzwerk. Das default-Netzwerk ist ein Netzwerk im automatischen Modus mit vorkonfigurierten Firewallregeln.

Sie können die Erstellung von Standardnetzwerken deaktivieren, indem Sie eine Organisationsrichtlinie erstellen, für die die Einschränkung compute.skipDefaultNetworkCreation gilt. Projekte, die diese Richtlinie übernehmen, haben kein Standardnetzwerk.

Überlegungen zu Netzwerken im automatischen Modus

Netzwerke im automatischen Modus sind einfach einzurichten, zu verwenden und eignen sich gut für Anwendungsfälle mit diesen Anforderungen:

  • Das automatische Erstellen von Subnetzen in jeder Region ist sinnvoll.

  • Die vordefinierten IP-Bereiche der Subnetze überschneiden sich nicht mit IP-Bereichen, die Sie für andere Zwecke verwenden, z. B. für Cloud VPN-Verbindungen zu lokalen Ressourcen.

Netzwerke im benutzerdefinierten Modus sind flexibler und besser für die Produktion geeignet. Netzwerke im benutzerdefinierten Modus eignen sich gut für Anwendungsfälle mit diesen Anforderungen:

  • Das automatische Erstellen von Subnetzen in jeder Region ist nicht erforderlich.

  • Das automatische Erstellen neuer Subnetze bei Verfügbarkeit neuer Regionen führt zu Überschneidungen mit IP-Adressen, die von manuell erstellten Subnetzen oder statischen Routen verwendet werden. Dieser Vorgang kann auch die gesamte Netzwerkplanung beeinträchtigen.

  • Sie benötigen vollständige Kontrolle über die in Ihrem VPC-Netzwerk erstellten Subnetze, einschließlich der verwendeten Regionen und IP-Adressbereiche.

  • Sie planen, VPC-Netzwerke über VPC-Netzwerk-Peering oder Cloud VPN zu verbinden. Da die Subnetze jedes Netzwerks im automatischen Modus denselben vordefinierten Bereich von IP-Adressen verwenden, können Sie Netzwerke im automatischen Modus nicht miteinander verbinden.

Subnetze und IP-Bereiche

Beim Erstellen eines Subnetzes müssen Sie einen primären IP-Adressbereich definieren. Sie können bis zu fünf sekundäre IP-Adressbereiche definieren:

  • Primärer IP-Adressbereich: Sie können einen beliebigen privaten CIDR-Block gemäß RFC 1918 für den primären IP-Adressbereich des Subnetzes auswählen. Diese IP-Adressen können für primäre interne IP-Adressen der VM, Alias-IP-Adressen der VM und die IP-Adressen interner Load-Balancer verwendet werden.

  • Sekundäre IP-Adressbereiche: Sie können bis zu fünf sekundäre IP-Adressbereiche definieren, die separate CIDR-Blöcke nach RFC 1918 sind. Diese IP-Adressbereiche werden nur für Alias-IP-Adressen verwendet.

Ihre Subnetze müssen keinen vordefinierten zusammenhängenden CIDR-Block bilden, bei Bedarf können Sie dies aber festlegen. In Netzwerken im automatischen Modus werden z. B. Subnetze erstellt, die sich in einen für den automatischen Modus vordefinierten IP-Bereich einfügen lassen.

Weitere Informationen finden Sie auf der Seite VPC-Netzwerke verwenden unter Mit Subnetzen arbeiten.

Reservierte IP-Adressen

Für jedes Subnetz sind vier IP-Adressen im primären IP-Bereich reserviert. In den sekundären IP-Bereichen gibt es keine reservierten IP-Adressen.

Reservierte Adresse Beschreibung Beispiel
Netz Erste Adresse im primären IP-Bereich für das Subnetz 10.1.2.0 in 10.1.2.0/24
Standardgateway Zweite Adresse im primären IP-Bereich für das Subnetz 10.1.2.1 in 10.1.2.0/24
Vorletzte Adresse Vorletzte Adresse im primären IP-Bereich für das Subnetz, das von der GCP für eine mögliche zukünftige Verwendung reserviert ist 10.1.2.254 in 10.1.2.0/24
Broadcast Letzte Adresse im primären IP-Bereich für das Subnetz 10.1.2.255 in 10.1.2.0/24

IP-Bereiche im automatischen Modus

Diese Tabelle enthält die IP-Bereiche für die automatisch erstellten Subnetze in einem Netzwerk im automatischen Modus. IP-Bereiche für diese Subnetze befinden sich innerhalb des CIDR-Blocks 10.128.0.0/9. Netzwerke im automatischen Modus werden mit einem Subnetz pro Region erstellt, in neuen Regionen werden ihnen automatisch neue Subnetze hinzugefügt. Deshalb werden nicht verwendete Teile von 10.128.0.0/9 für die zukünftige Nutzung durch GCP reserviert.

Region IP-Bereich (CIDR) Standardgateway Verwendbare Adressen (von/bis einschließlich)
asia-east1 10.140.0.0/20 10.140.0.1 10.140.0.2 bis 10.140.15.253
asia-east2 10.170.0.0/20 10.170.0.1 10.170.0.2 bis 10.170.15.253
asia-northeast1 10.146.0.0/20 10.146.0.1 10.146.0.2 bis 10.146.15.253
asia-northeast2 10.174.0.0/20 10.174.0.1 10.174.0.2 bis 10.174.15.253
asia-south1 10.160.0.0/20 10.160.0.1 10.160.0.2 bis 10.160.15.253
asia-southeast1 10.148.0.0/20 10.148.0.1 10.148.0.2 bis 10.148.15.253
australia-southeast1 10.152.0.0/20 10.152.0.1 10.152.0.2 bis 10.152.15.253
europe-north1 10.166.0.0/20 10.166.0.1 10.166.0.2 bis 10.166.15.253
europe-west1 10.132.0.0/20 10.132.0.1 10.132.0.2 bis 10.132.15.253
europe-west2 10.154.0.0/20 10.154.0.1 10.154.0.2 bis 10.154.15.253
europe-west3 10.156.0.0/20 10.156.0.1 10.156.0.2 bis 10.156.15.253
europe-west4 10.164.0.0/20 10.164.0.1 10.164.0.2 bis 10.164.15.253
europe-west6 10.172.0.0/20 10.172.0.1 10.172.0.2 bis 10.172.15.253
northamerica-northeast1 10.162.0.0/20 10.162.0.1 10.162.0.2 bis 10.162.15.253
southamerica-east1 10.158.0.0/20 10.158.0.1 10.158.0.2 bis 10.158.15.253
us-central1 10.128.0.0/20 10.128.0.1 10.128.0.2 bis 10.128.15.253
us-east1 10.142.0.0/20 10.142.0.1 10.142.0.2 bis 10.142.15.253
us-east4 10.150.0.0/20 10.150.0.1 10.150.0.2 bis 10.150.15.253
us-west1 10.138.0.0/20 10.138.0.1 10.138.0.2 bis 10.138.15.253
us-west2 10.168.0.0/20 10.168.0.1 10.168.0.2 bis 10.168.15.253

Routen und Firewallregeln

Routen

Routen definieren Pfade für Pakete, die Instanzen verlassen (ausgehender Traffic). Routen in GCP sind in zwei Kategorien unterteilt: systemgeneriert und benutzerdefiniert. Dieser Abschnitt beschreibt kurz die beiden Arten von systemgenerierten Routen. Sie können auch benutzerdefinierte Routen in Ihrem Netzwerk erstellen. Die Routenübersicht enthält weitere Informationen zum Routing in GCP.

Jedes neue Netzwerk beginnt mit zwei Arten von systemgenerierten Routen:

  • Die Standardroute definiert einen Pfad für den Traffic zum Verlassen des VPC-Netzwerks. Sie ermöglicht allgemeinen Internetzugang zu VMs, die den Anforderungen für den Internetzugriff entsprechen. Außerdem gibt sie den typischen Pfad für privaten Google-Zugriff an.

  • Ein Subnetzroute wird für jeden der IP-Bereiche erstellt, die mit einem Subnetz verbunden sind. Jedes Subnetz verfügt über mindestens eine Subnetzroute für seinen primären IP-Bereich und für ein Subnetz werden zusätzliche Subnetzrouten erstellt, wenn Sie ihm sekundäre IP-Bereiche hinzufügen. Subnetzrouten definieren Pfade für den Traffic, damit VMs erreicht werden, die die Subnetze verwenden.

Modus für dynamisches Routing

Jedem VPC-Netzwerk ist ein Modus für dynamisches Routing zugeordnet, der das Verhalten aller Cloud Router im Netzwerk steuert. Cloud Router teilen Ihrem VPC-Netzwerk Routen zu und ermitteln benutzerdefinierte dynamische Routen von verbundenen Netzwerken, wenn Sie Ihr VPC-Netzwerk über einen Cloud VPN-Tunnel mithilfe von dynamischem Routing, über Dedicated Interconnect oder über Partner Interconnect mit einem anderen Netzwerk verbinden.

  • Regionales dynamisches Routing ist die Standardeinstellung. In diesem Modus gelten Routen zu lokalen Ressourcen, die von einem bestimmten Cloud Router im Netzwerk ermittelt wurden, nur für die Subnetze, die sich in derselben Region wie der Cloud Router befinden. Cloud Router geben nur die Routen zu Subnetzen in der zugehörigen Region für ihre lokalen Gegenstücke frei, wenn dies nicht durch benutzerdefinierte Ankündigungen geändert wurde.

  • Durch globales dynamisches Routing wird das Verhalten aller Cloud Router im Netzwerk so verändert, dass die Routen zu lokalen Ressourcen, die sie ermitteln, unabhängig von der Region von allen Subnetzen im Netzwerk verwendet werden können. Jeder Cloud Router gibt Routen zu allen Subnetzen im VPC-Netzwerk mit seinem lokalen Gegenstück frei, wenn dies nicht durch benutzerdefinierte Ankündigungen geändert wurde.

In benutzerdefinierten Ankündigungen erfahren Sie, wie die von einem Cloud Router freigegebenen Routen angepasst werden können.

Der Modus für dynamisches Routing kann beim Erstellen oder Ändern eines VPC-Netzwerks festgelegt werden. Sie können ohne Einschränkung zwischen dem regionalen und globalen Modus für dynamisches Routing wechseln. Weitere Anleitungen dazu finden Sie unter VPC-Netzwerke verwenden.

Firewallregeln

Firewallregeln gelten sowohl für ausgehenden als auch für eingehenden Traffic im Netzwerk. Firewallregeln steuern den Traffic auch dann, wenn er vollständig innerhalb des Netzwerks liegt, einschließlich der Kommunikation zwischen Instanzen.

Jedes VPC-Netzwerk hat zwei implizierte Firewallregeln. Eine implizierte Regel lässt den meisten ausgehenden Traffic zu, während die andere den gesamten eingehenden Traffic ablehnt. Sie können die implizierten Regeln nicht löschen, aber Sie können sie mit Ihren eigenen überschreiben. Die GCP blockiert immer etwas Traffic, unabhängig von den Firewallregeln. Weitere Informationen finden Sie unter Blockierter Traffic.

Weitere Informationen finden Sie in der Übersicht über Firewallregeln.

Sie können überwachen, welche Firewallregel eine bestimmte Verbindung erlaubt oder abgelehnt hat. Weitere Informationen finden Sie unter Logging für Firewallregeln.

Kommunikation im Netzwerk

Die systemgenerierten Subnetzrouten definieren die Pfade zum Senden von Traffic zwischen Instanzen im Netzwerk über interne (private) IP-Adressen. Damit eine Instanz mit einer anderen Instanz kommunizieren kann, müssen auch entsprechende Firewallregeln konfiguriert werden, da jedes Netzwerk über eine implizierte Firewallregel zur Ablehnung von eingehendem Traffic verfügt.

Außer im default-Netzwerk müssen Sie explizit Firewallregeln für eingehenden Traffic mit einer höheren Priorität erstellen, damit Instanzen miteinander kommunizieren können. Das default-Netzwerk umfasst verschiedene Firewallregeln zusätzlich zu den implizierten Regeln, z. B. die Regel default-allow-internal, um die Kommunikation zwischen den Instanzen im Netzwerk zuzulassen. Das default-Netzwerk enthält auch Eingangsregeln, die Protokolle wie RDP und SSH zulassen.

Regeln, die im default-Netzwerk enthalten sind, können auch auf Netzwerke im automatischen Modus angewendet werden, die Sie über die GCP Console erstellen.

Anforderungen für den Internetzugriff

Damit für eine Instanz ausgehende Internetverbindungen möglich sind, müssen folgende Kriterien erfüllt sein:

  • Das Netzwerk benötigt eine gültige Route für das Standard-Internetgateway oder eine benutzerdefinierte Route mit ganz allgemeinem IP-Zielbereich (0.0.0.0/0). Mit dieser Route wird einfach der Pfad zum Internet definiert. Weitere Informationen über Routen finden Sie unter Routen.

  • Firewallregeln müssen ausgehenden Traffic von der Instanz zulassen. Die implizierte Regel zum Zulassen von ausgehendem Traffic gilt für alle Instanzen im Netzwerk, wenn sie nicht von einer Regel mit einer höheren Priorität überschrieben wird.

  • Eine der folgenden Bedingungen muss zutreffen:

    • Die Instanz muss eine externe IP-Adresse haben. Diese kann einer Instanz bei der Erstellung oder nach der Erstellung zugewiesen werden.

    • Die Instanz muss in der Lage sein, Cloud NAT oder einen instanzbasierten Proxy zu verwenden, der das Ziel für eine statische 0.0.0.0/0-Route ist.

Beispiel für ein VPC-Netzwerk

Im folgenden Beispiel wird ein Netzwerk im benutzerdefinierten Modus mit drei Subnetzen in zwei Regionen dargestellt:

Beispiel für ein VPC-Netzwerk (zum Vergrößern klicken)
Beispiel für ein VPC-Netzwerk (zum Vergrößern klicken)
  • Subnet1 ist als 10.240.0.0/24 in der Region us-west1 definiert.
    • In diesem Subnetz befinden sich zwei VM-Instanzen in der Zone us-west1-a. Die zugehörigen IP-Adressen stammen beide aus dem verfügbaren Adressbereich in subnet1.
  • Subnet2 ist als 192.168.1.0/24 in der Region us-east1 definiert.
    • In diesem Subnetz befinden sich zwei VM-Instanzen in der Zone us-east1-a. Die zugehörigen IP-Adressen stammen beide aus dem verfügbaren Adressbereich in subnet2.
  • Subnet3 ist als 10.2.0.0/16 in der Region us-east1 definiert.
    • Eine VM-Instanz in der Zone us-east1-a und eine zweite Instanz in der Zone us-east1-b befinden sich in subnet3. Jede dieser Instanzen erhält eine IP-Adresse aus dem zugehörigen verfügbaren Bereich. Da es sich bei Subnetzen um regionale Ressourcen handelt, können die Netzwerkschnittstellen von Instanzen mit einem beliebigen Subnetz in der Region mit ihren Zonen verknüpft werden.

Weitere Informationen

  • Anleitungen zum Erstellen und Ändern von VPC-Netzwerken finden Sie unter VPC verwenden
Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...