VPC-Netzwerke

Ein VPC-Netzwerk (Virtual Private Cloud) ist eine virtuelle Version eines physischen Netzwerks, das mithilfe von Andromeda im Google-Produktionsnetzwerk implementiert wird. Ein VPC-Netzwerk bietet Folgendes:

Projekte können mehrere VPC-Netzwerke enthalten. Sofern Sie keine Organisationsrichtlinie erstellen, die dies verbietet, beginnen neue Projekte mit einem Standardnetzwerk (einem VPC-Netzwerk im automatischen Modus), das in jeder Region ein Subnetzwerk (Subnetz) hat.

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.

  • Der Traffic zu und von den Instanzen kann mit Firewallregeln für Netzwerke gesteuert werden. Regeln werden auf den VMs selbst umgesetzt, sodass der Traffic nur beim Verlassen oder Erreichen einer VM gesteuert und protokolliert werden kann.

  • Die Ressourcen in einem VPC-Netzwerk können abhängig von den geltenden Firewallregeln über interne 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 Private Zugriffsoptionen für Dienste.

  • Die Netzwerkverwaltung kann über IAM-Rollen (Identity and Access Management) 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 GRE-Traffic, einschließlich Traffic in Cloud VPN und Cloud Interconnect. VPC-Netzwerke unterstützen GRE für Cloud NAT und Weiterleitungsregeln für Load-Balancing und Protokollweiterleitung nicht. Dank der Unterstützung für GRE können Sie den GRE-Traffic auf einer VM aus dem Internet (externe IP-Adresse) und Cloud VPN oder Cloud Interconnect (interne IP-Adresse) beenden. Der gekapselte Traffic kann dann an ein erreichbares Ziel weitergeleitet werden. GRE ermöglicht es Ihnen, Dienste wie SASE (Secure Access Service Edge) und SD-WAN zu verwenden.

  • VPC-Netzwerke unterstützen IPv4-Unicast-Adressen. VPC-Netzwerke unterstützen auch externe IPv6-Unicast-Adressen in einigen Regionen. Weitere Informationen zur Unterstützung von IPv6 finden Sie unter IPv6-Adressen. VPC-Netzwerke unterstützen keine Broadcast- oder Multicast-Adressen innerhalb des Netzwerks.

Netzwerk- und Subnetzterminologie

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

Ein Subnetz ist nicht dasselbe wie ein (VPC-)Netzwerk. Netzwerke und Subnetze sind unterschiedliche Objekttypen in Google Cloud.

Netzwerke und Subnetze

Jedes VPC-Netzwerk besteht aus mindestens einer verwendbaren IP-Bereichspartition, die als Subnetz bezeichnet wird. Jedes Subnetz ist einer Region zugeordnet. VPC-Netzwerken sind keine IP-Adressbereiche zugeordnet. Für die Subnetze sind IP-Bereiche definiert.

Ein Netzwerk kann erst verwendet werden, wenn es mindestens ein Subnetz hat. Von VPC-Netzwerken im automatischen Modus werden automatisch Subnetze in den einzelnen Regionen erstellt. Benutzerdefinierte VPC-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. Weitere Informationen zu den Unterschieden zwischen VPC-Netzwerken im automatischen Modus und im benutzerdefinierten Modus finden Sie unter VPC-Netzwerktypen.

Wenn Sie eine Ressource in Google Cloud erstellen, wählen Sie ein Netzwerk und ein Subnetz aus. 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. Google Cloud 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 VPC-Netzwerk im automatischen Modus auswählen, können Sie automatische Subnetze verwenden. Bei dieser Einstellung wird die Subnetzauswahl auf die verfügbaren Subnetze in der ausgewählten Region aller verwalteten Instanzgruppen ausgedehnt, die die Vorlage verwenden. VPC-Netzwerke im automatischen Modus haben per Definition ein Subnetz in jeder Region.
  • Zur Erstellung eines Kubernetes-Containerclusters 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.

Modus für Subnetzerstellung

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

Sie können ein VPC-Netzwerk vom automatischen Modus in den benutzerdefinierten Modus konvertieren. Diese Konvertierung ist nur in eine Richtung möglich. VPC-Netzwerke im benutzerdefinierten Modus können nicht in VPC-Netzwerke im automatischen Modus umgewandelt werden. Wenn Sie Hilfe bei der Entscheidung benötigen, welcher Netzwerktyp Ihren Anforderungen entspricht, lesen Sie sich den Abschnitt Überlegungen zu VPC-Netzwerken im automatischen Modus durch.

Standardnetzwerk

Sofern Sie diese Option nicht deaktivieren, beginnt jedes neue Projekt mit einem Standardnetzwerk. Das Standardnetzwerk ist ein VPC-Netzwerk im automatischen Modus mit vorkonfigurierten IPv4-Firewallregeln. Das Standardnetzwerk hat keine voreingestellten IPv6-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 VPC-Netzwerken im automatischen Modus

VPC-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. VPC-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.

Subnetzbereiche

Beim Erstellen eines Subnetzes müssen Sie seinen primären IP-Adressbereich definieren. Die primären internen Adressen folgender Ressourcen stammen aus dem primären Bereich des Subnetzes: VM-Instanzen, interne Load-Balancer und interne Protokollweiterleitung. Optional können Sie zu einem Subnetz sekundäre IP-Adressbereiche hinzufügen, die nur von Alias-IP-Bereichen verwendet werden. Sie können jedoch Alias-IP-Bereiche für Instanzen aus dem primären oder sekundären Bereich eines Subnetzes konfigurieren.

Für alle Subnetze in einem VPC-Netzwerk muss jeder primäre oder sekundäre IP-Bereich ein eindeutiger gültiger CIDR-Block sein. Informationen zur Anzahl der sekundären IP-Bereiche, die Sie definieren können, finden Sie im Abschnitt zu Limits pro Netzwerk.

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 unter Mit Subnetzen arbeiten.

Gültige Bereiche

Die primären und sekundären IP-Adressbereiche eines Subnetzes sind regionale interne IP-Adressen. In der folgenden Tabelle werden gültige Bereiche beschrieben.

Bereich Beschreibung
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Private IP-Adressen RFC 1918
100.64.0.0/10 Gemeinsamer Adressbereich RFC 6598
192.0.0.0/24 IETF-Protokollzuweisungen RFC 6890
192.0.2.0/24 (TEST-NET-1)
198.51.100.0/24 (TEST-NET-2)
203.0.113.0/24 (TEST-NET-3)
Dokumentation RFC 5737
192.88.99.0/24 IPv6-zu-IPv4-Relay (verworfen) RFC 7526
198.18.0.0/15 Benchmarktests RFC 2544
240.0.0.0/4

Für die spätere Verwendung (Klasse E) reserviert, wie in RFC 5735 und RFC 1112 vermerkt.

Einige Betriebssysteme unterstützen die Verwendung dieses Bereichs nicht. Prüfen Sie daher, ob Ihr Betriebssystem diese unterstützt, bevor Sie Subnetze erstellen, die diesen Bereich verwenden.

Privat verwendete öffentliche IP-Adressen

Dazu gehören IP-Adressen, die nicht Bestandteil der in dieser Tabelle aufgeführten RFC-Bereiche und der eingeschränkten Gruppe sind. Wenn Sie diese Adressen als Subnetzbereiche verwenden, gibt Google Cloud diese Routen nicht an das Internet weiter und leitet keinen Traffic vom Internet an diese weiter.

Beim VPC-Netzwerk-Peering werden Subnetzrouten für öffentliche IP-Adressen nicht automatisch ausgetauscht. Die Subnetzrouten werden standardmässig automatisch exportiert. Peer-Netzwerke müssen jedoch explizit für ihren Import konfiguriert werden, damit sie verwendet werden.

Für Subnetzbereiche gelten die folgenden Einschränkungen:

  • Subnetzbereiche dürfen nicht kleiner oder größer als ein eingeschränkter Bereich sein oder mit diesem übereinstimmen. 169.0.0.0/8 ist beispielsweise kein gültiger Subnetzbereich, da er sich mit dem Link-Local-Bereich 169.254.0.0/16 (RFC 3927) überschneidet, der ein eingeschränkter Bereich ist.

  • Subnetzbereiche dürfen weder einen RFC-Bereich (wie in der Tabelle oben beschrieben) noch einen privat genutzten öffentlichen IP-Adressbereich umfassen. 172.16.0.0/10 ist beispielsweise kein gültiger Subnetzbereich, da er sich mit RFC 1918 und öffentlichen IP-Adressen überschneidet.

  • Subnetzbereiche können nicht mehrere RFC-Bereiche umfassen. Beispielsweise ist 192.0.0.0/8 kein gültiger Subnetzbereich, da er sowohl 192.168.0.0/16 (aus RFC 1918) als auch 192.0.0.0/24 (aus RFC 6890) enthält. Sie können jedoch zwei Subnetze mit unterschiedlichen primären Bereichen erstellen, eines mit 192.168.0.0/16 und eines mit 192.0.0.0/24. Alternativ können Sie beide Bereiche im selben Subnetz verwenden, wenn Sie einen davon als sekundären Bereich festlegen.

Eingeschränkte Bereiche

Eingeschränkte Bereiche umfassen öffentliche IP-Adressen von Google und häufig reservierte RFC-Bereiche, wie in der folgenden Tabelle beschrieben. Diese Bereiche können nicht für Subnetzbereiche verwendet werden.

Bereich Beschreibung
Öffentliche IP-Adressen für Google APIs und -Dienste, einschließlich Google Cloud-Netblocks Sie finden diese IP-Adressen unter https://gstatic.com/ipranges/goog.txt.
199.36.153.4/30 und 199.36.153.8/30 Virtuelle IP-Adressen für den privaten Google-Zugriff
0.0.0.0/8 Aktuelles (lokales) Netzwerk RFC 1122
127.0.0.0/8 Lokaler Host RFC 1122
169.254.0.0/16 Link-Local RFC 3927
224.0.0.0/4 Multicast (Klasse D) RFC 5771
255.255.255.255/32 Eingeschränkte Übertragungszieladresse RFC 8190 und RFC 919

Reservierte IP-Adressen in einem Subnetz

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 IP-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 Google Cloud 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 VPC-Netzwerk im automatischen Modus. IP-Bereiche für diese Subnetze befinden sich innerhalb des CIDR-Blocks 10.128.0.0/9. VPC-Netzwerke im automatischen Modus werden mit einem Subnetz pro Region erstellt und in neuen Regionen werden ihnen automatisch neue Subnetze hinzugefügt. Nicht verwendete Teile von 10.128.0.0/9 sind für zukünftige Nutzung durch Google Cloud 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-northeast3 10.178.0.0/20 10.178.0.1 10.178.0.2 bis 10.178.15.253
asia-south1 10.160.0.0/20 10.160.0.1 10.160.0.2 bis 10.160.15.253
asia-south2 10.190.0.0/20 10.190.0.1 10.190.0.2 nach 10.190.15.253
asia-southeast1 10.148.0.0/20 10.148.0.1 10.148.0.2 bis 10.148.15.253
asia-southeast2 10.184.0.0/20 10.184.0.1 10.184.0.2 bis 10.184.15.253
australia-southeast1 10.152.0.0/20 10.152.0.1 10.152.0.2 bis 10.152.15.253
australia-southeast2 10.192.0.0/20 10.192.0.1 10.192.0.2 bis 10.192.15.253
europe-central2 10.186.0.0/20 10.186.0.1 10.186.0.2 bis 10.186.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
us-west3 10.180.0.0/20 10.180.0.1 10.180.0.2 bis 10.180.15.253
us-west4 10.182.0.0/20 10.182.0.1 10.182.0.2 bis 10.182.15.253

IPv6-Adressen

Sie können IPv6 in den folgenden Arten von Subnetzen in einem VPC-Netzwerk aktivieren: Sie können IPv6 in einem Legacy-Netzwerk nicht aktivieren.

  • Sie können IPv6 für neue oder vorhandene Subnetze in einem VPC-Netzwerk im benutzerdefinierten Modus aktivieren.

  • Sie können IPv6 für Subnetze aktivieren, die Sie einem VPC-Netzwerk im automatischen Modus hinzugefügt haben (einschließlich des Standardnetzwerks).

  • Sie können IPv6 nicht für Subnetze aktivieren, die automatisch in einem VPC-Netzwerk im automatischen Modus erstellt werden (einschließlich des Standardnetzwerks).

  • Wenn Sie ein Netzwerk im automatischen Modus in den benutzerdefinierten Modus konvertieren, können Sie IPv6 in jedem der Subnetze in diesem Netzwerk aktivieren.

Wenn Sie IPv6 aktivieren, wird zusätzlich zum IPv4-Bereich ein eindeutiger globaler Unicast-Adressbereich mit der Subnetzlänge /64 zugewiesen.

Wenn Sie IPv6 für eine VM aktivieren, wird der VM der IPv6-Adressbereich /96 zugewiesen. Die erste IP-Adresse in diesem Bereich wird der primären Schnittstelle mithilfe von DHCPv6 zugewiesen.

Die IPv6-Adressen, die Subnetzen und VMs zugewiesen sind, sind externe Adressen. Sie können für die VM-zu-VM-Kommunikation verwendet und außerdem im Internet weitergeleitet werden. Wenn Sie den ausgehenden Traffic aus dem Internet steuern möchten, konfigurieren Sie Firewallregeln oder hierarchische Firewallrichtlinien. Wenn Sie das IPv6-Routing im Internet vollständig deaktivieren möchten, löschen Sie die IPv6-Standardroute im VPC-Netzwerk.

Die folgenden Ressourcen unterstützen IPv6-Adressen, wenn sie mit einem Subnetz mit aktiviertem IPv6 verbunden sind:

Außerdem unterstützt das externe HTTP(S)-Load-Balancing globale externe IPv6-Adressen, wenn es in der Premium-Stufe konfiguriert ist. Sie können keine IPv6-Adresse verwenden, die einem Subnetz für das HTTP(S)-Load-Balancing zugewiesen ist. Stattdessen reservieren Sie eine IP-Adresse.

Regionen mit Unterstützung für IPv6

IPv6-Unterstützung für Subnetze und VM-Instanzen ist in den folgenden Regionen verfügbar:

  • asia-east1
  • asia-south1
  • europe-west2
  • us-west2

Routen und Firewallregeln

Routen

Routen definieren Pfade für Pakete, die Instanzen verlassen (ausgehender Traffic). Routen in Google Cloud werden in zwei Kategorien unterteilt: systemgeneriert und benutzerdefiniert.

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 VMs, die den Anforderungen für den Internetzugriff entsprechen, allgemeinen Internetzugang. Außerdem gibt sie den typischen Pfad für privaten Google-Zugriff an.

  • Eine Subnetzroute wird für jeden der IP-Bereiche erstellt, die mit einem Subnetz verbunden sind. Jedes Subnetz hat mindestens eine Subnetzroute für seinen primären IP-Bereich. Zusätzliche Subnetzrouten werden für ein Subnetz 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. Sie können Subnetzrouten nicht manuell entfernen.

Benutzerdefinierte Routen sind entweder statische Routen, die Sie manuell erstellen, oder dynamische Routen, die automatisch von einem oder mehreren Ihrer Cloud Router verwaltet werden. Weitere Informationen finden Sie unter Benutzerdefinierte Routen.

Ausführliche Informationen zum Routing in Google Cloud erhalten Sie in der Routenübersicht.

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 VPC-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.

Informationen darüber, wie die von einem Cloud Router freigegebenen Routen angepasst werden können, finden Sie unter benutzerdefinierte Advertisements.

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 dynamischen Routingmodus wechseln. Eine Anleitung finden Sie unter Modus für dynamisches Routing ändern.

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 implizierte Firewallregeln, zwei implizierte IPv4-Firewallregeln sowie, falls IPv6 aktiviert ist, zwei implizierte IPv6-Firewallregeln. Die implizierten Regeln für ausgehenden Traffic lassen den meisten ausgehenden Traffic zu und die implizierten Regeln für eingehenden Traffic lehnen den gesamten eingehenden Traffic ab. Sie können die implizierten Regeln nicht löschen, aber Sie können sie mit Ihren eigenen überschreiben. Google Cloud blockiert immer etwas Traffic, unabhängig von den Firewallregeln. Weitere Informationen finden Sie unter Permanent blockierter Traffic.

Wenn Sie überwachen möchten, welche Firewallregel eine bestimmte Verbindung erlaubt oder abgelehnt hat, finden Sie weitere Informationen unter Logging von Firewallregeln.

Kommunikation und Zugriff

Kommunikation im Netzwerk

Die systemgenerierten Subnetzrouten definieren die Pfade zum Senden von Traffic zwischen Instanzen im Netzwerk über interne 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 Standardnetzwerk müssen Sie explizit Firewallregeln für eingehenden Traffic mit einer höheren Priorität erstellen, damit Instanzen miteinander kommunizieren können. Das Standardnetzwerk umfasst verschiedene Firewallregeln zusätzlich zu den implizierten Regeln, z. B. die Regel default-allow-internal, die die Kommunikation zwischen den Instanzen im Netzwerk zulässt. Das Standardnetzwerk enthält auch Eingangsregeln, die Protokolle wie RDP und SSH zulassen.

Regeln, die im Standardnetzwerk enthalten sind, können auch auf neue VPC-Netzwerke im automatischen Modus angewendet werden, die Sie über die Cloud 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 der Pfad zum Internet definiert. Weitere Informationen 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. Eine externe IP-Adresse 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.

Kommunikation und Zugriff für App Engine

VPC-Firewallregeln gelten für Ressourcen, die im VPC-Netzwerk ausgeführt werden, z. B. Compute Engine-VMs. Für App Engine-Instanzen funktionieren Firewallregeln so:

  • App Engine-Standardumgebung: Für eingehenden Traffic gelten nur App Engine-Firewallregeln. Da App Engine-Instanzen der Standardumgebung nicht innerhalb Ihres VPC-Netzwerks ausgeführt werden, gelten VPC-Firewallregeln nicht für sie.

  • Flexible App Engine-Umgebung: Für eingehenden Traffic gelten sowohl App Engine- als auch VPC-Firewallregeln. Eingehender Traffic ist nur zulässig, wenn er von beiden Arten von Firewallregeln erlaubt wird. Für ausgehenden Traffic gelten VPC-Firewallregeln.

Weitere Informationen zur Steuerung des Zugriffs auf App Engine-Instanzen finden Sie unter Anwendungssicherheit.

Traceroute zu externen IP-Adressen

Aus internen Gründen erhöht Google Cloud den TTL-Zähler von Paketen, die nächste Hops im Google-Netzwerk durchlaufen. Tools wie traceroute und mtr liefern dann möglicherweise unvollständige Ergebnisse, da die TTL bei einigen Hops nicht abläuft. Hops innerhalb und außerhalb des Google-Netzwerks sind unter folgenden Umständen möglicherweise ausgeblendet.

  • Wenn Sie Pakete von Compute Engine-Instanzen an externe IP-Adressen senden, einschließlich der externen IP-Adressen anderer Google Cloud-Ressourcen oder -Ziele im Internet.

  • Wenn Sie Pakete an die externe IP-Adresse senden, die einer Compute Engine-Instanz oder einer anderen Google Cloud-Ressource zugeordnet ist.

Die Anzahl der ausgeblendeten Hops variiert je nach den Netzwerkdienststufen der Instanz, der Region und anderen Faktoren. Wenn es nur wenige Hops gibt, ist es möglich, dass alle ausgeblendet sind. Wenn im Ergebnis von traceroute oder mtr Hops fehlen, bedeutet dies nicht, dass ausgehender Traffic verworfen wird.

Es gibt für dieses Verhalten keine Problemumgehung. Sie müssen dies berücksichtigen, wenn Sie Monitoring von Drittanbietern einrichten, das eine Verbindung zu einer externen IP-Adresse herstellt, die mit einer VM verbunden ist.

Durchsatzlimits für ausgehenden Traffic

Informationen zum Netzwerkdurchsatz finden Sie auf der Seite Netzwerkbandbreite in der Compute Engine-Dokumentation.

Paketgröße

Informationen zur Paketgröße finden Sie im Abschnitt Maximale Übertragungseinheit.

Beispiel für ein VPC-Netzwerk

Das folgende Beispiel zeigt ein VPC-Netzwerk im benutzerdefinierten Modus mit drei Subnetzen in zwei Regionen:

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.
    • In subnet3 befinden sich eine VM-Instanz in der Zone us-east1-a und eine zweite Instanz in der Zone us-east1-b. Beide erhalten jeweils eine IP-Adresse aus dem 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.

Maximale Übertragungseinheit

VPC-Netzwerke haben die standardmäßige maximale Übertragungseinheit (MTU) von 1460 Byte. Sie können die VPC-Netzwerke jedoch so konfigurieren, dass sie eine MTU von 1500 Byte haben.

Die MTU gibt die Bytezahl des größten Pakets an, das von einem Netzwerkschichtprotokoll unterstützt wird, einschließlich Header und Daten. In Google Cloud legen Sie die MTU für jedes VPC-Netzwerk fest. VM-Instanzen, die dieses Netzwerk verwenden, müssen ebenfalls so konfiguriert werden, dass sie diese MTU für ihre Schnittstellen verwenden. Die MTU-Einstellung des Netzwerks wird an eine VM mitgeteilt, wenn diese VM eine IP-Adresse mithilfe von DHCP anfordert. DHCP-Option 26 enthält die MTU des Netzwerks.

Die MTU wirkt sich sowohl auf den UDP- als auch den TCP-Traffic aus:

  • Wenn ein UDP-Paket gesendet wird, das größer ist, als das Ziel empfangen kann, oder das die MTU in einem Netzwerk-Link auf dem Pfad zum Ziel überschreitet, wird das Paket verworfen, wenn das Flag „Nicht fragmentieren“ festgelegt ist. Wenn es verworfen wird, wird ein ICMP-Paket des Typs Fragmentation-Needed an den Absender gesendet. Weitere Informationen zur Pfaderkennung finden Sie unter PMTUD.
  • Wenn ein UDP-Paket gesendet wird, das größer ist, als das Ziel empfangen kann, oder das die MTU in einem Netzwerk-Link zum Ziel überschreitet, dann wird es (im Allgemeinen) fragmentiert, wenn das Flag Don't-Fragment nicht festgelegt ist. Diese Fragmentierung wird durchgeführt, wenn eine Diskrepanz erkannt wird: Dies kann an einem zwischengeschalteten Router oder auch beim Absender selbst liegen, wenn ein Paket gesendet wird, das größer als die MTU ist.
  • TCP handelt die maximale Segmentgröße (MSS) während der Verbindungsaufbauzeit aus. Anschließend werden Pakete in die kleinere MTU-Größe beider Endpunkte der Verbindung segmentiert.

Einstellungen für VMs und MTU

Bei Linux-VMs, die auf von Google bereitgestellten Betriebssystem-Images basieren, wird deren Schnittstellen-MTU bei der Erstellung automatisch auf die MTU des VPC-Netzwerks festgelegt. Wenn eine VM mehrere Netzwerkschnittstellen hat, wird jede Schnittstelle auf die MTU des angehängten Netzwerks gesetzt. Wenn Sie die MTU einer VPC ändern, in der VMs ausgeführt werden, müssen Sie diese VMs beenden und anschließend starten, um die neue MTU zu übernehmen. Wenn die VMs wieder gestartet werden, wird ihnen die geänderte Netzwerk-MTU von DHCP mitgeteilt.

Windows-VMs konfigurieren ihre Schnittstellen beim Start nicht automatisch so, dass sie die MTU des VPC-Netzwerks verwenden. Stattdessen werden Windows-VMs, die auf von Google bereitgestellten Betriebssystem-Images basieren, mit einer festen MTU von 1460 konfiguriert. Gehen Sie auf jeder Windows-VM so vor, um Windows-VMs basierend auf von Google bereitgestellten Betriebssystemabbildern auf eine MTU von 1500 festzulegen:

Eingabeaufforderung

  1. Öffnen Sie die Eingabeaufforderung (cmd.exe) als Administrator.
  2. Führen Sie den folgenden Befehl aus, um den Index der Schnittstelle zu ermitteln, die Sie aktualisieren möchten:

    netsh interface ipv4 show interface 
  3. Aktualisieren Sie die Schnittstelle:

    netsh interface ipv4 set interface INTERFACE_INDEX mtu=1500 store=persistent 
  4. Starten Sie den Server neu, damit die Änderungen wirksam werden:

     shutdown /r /t 0 

PowerShell

  1. Öffnen Sie PowerShell als Administrator.
  2. Führen Sie dazu diesen Befehl aus:

    Set-NetIPInterface -InterfaceAlias INTERFACE_NAME -AddressFamily IPv4 -NlMtu 1500 
  3. Starten Sie den Server neu, damit die Änderungen wirksam werden:

    Restart-Computer -Force 

Sie können dieses Verfahren auch verwenden, um die MTU von benutzerdefinierten Windows-VMs entsprechend dem Netzwerk auf 1460 oder 1500 festzulegen.

Prüfen Sie die MTU-Einstellungen auf allen VMs, die benutzerdefinierte Images verwenden. Es ist möglich, dass die MTU des VPC-Netzwerks berücksichtigt wird. Es ist jedoch auch möglich, dass ihre MTUs auf einen festen Wert gesetzt sind.

Eine Anleitung dazu finden Sie unter MTU eines Netzwerks ändern.

Dienste zu einem anderen MTU-Netzwerk migrieren

Vielleicht möchten Sie Ihre Dienste zu neuen VMs in einem neuen Netzwerk migrieren, anstatt die MTU Ihres bestehenden Netzwerks zu ändern. In einem solchen Fall könnte es bei Ihnen einen Server geben, z. B. einen Datenbankserver, der während der Migration für alle VMs zugänglich sein muss. Wenn dies der Fall ist, kann Ihnen der folgende allgemeine Ansatz bei der ordnungsgemäßen Migration helfen:

  1. Erstellen Sie das neue Netzwerk mit der neuen MTU.
  2. Erstellen Sie alle erforderlichen Firewallregeln und -routen im neuen Netzwerk.
  3. Erstellen Sie eine VM mit mehreren Netzwerkschnittstellen im alten Netzwerk. Eine Schnittstelle stellt eine Verbindung zum neuen Netzwerk über die neue MTU und die andere über das alte MTU mit dem alten Netzwerk her.
  4. Konfigurieren Sie diese neue VM als sekundären Server für den vorhandenen Server.
  5. Führen Sie für den primären Server ein Failover auf den sekundären Server durch.
  6. Migrieren Sie VMs zum neuen Netzwerk oder erstellen Sie neue VMs im neuen Netzwerk. Wenn Sie neue VMs erstellen, können Sie diese von Grund auf neu erstellen oder aus einem vorhandenen Image erstellen. Sie können aber auch einen Snapshot der vorhandenen VMs erstellen und diesen zum Auffüllen der neuen nichtflüchtigen Speicher verwenden.
  7. Konfigurieren Sie diese VMs so, dass der operative Server in diesem Netzwerk verwendet wird.
  8. Migrieren Sie den Traffic zu den neuen VMs.
  9. Wenn Sie das alte Netzwerk löschen möchten, erstellen Sie einen neuen Server im neuen Netzwerk, synchronisieren Sie ihn mit dem vorhandenen Server und führen Sie ein Failover durch.
  10. Löschen Sie den alten Server und das alte Netzwerk.

Folgen von nicht übereinstimmenden MTUs

Eine nicht übereinstimmende MTU wird als zwei miteinander kommunizierende VM-Instanzen mit unterschiedlichen MTU-Einstellungen definiert. Dies kann in einer begrenzten Anzahl von Fällen zu Verbindungsproblemen führen. Spezifische Fälle umfassen die Verwendung von Instanzen als Router und die Verwendung von Kubernetes in VMs.

In den meisten gängigen Szenarien sind TCP-Verbindungen, die zwischen Instanzen mit unterschiedlichen MTUs aufgebaut werden, aufgrund der MSS-Verhandlung erfolgreich, bei der beide Enden einer Verbindung sich darauf einigen, die niedrigere der beiden MTUs zu verwenden.

Dies gilt unabhängig davon, ob sich die beiden VMs im selben Netzwerk oder in Peering-Netzwerken befinden.

MTU-Unterschiede mit Cloud VPN

Informationen zu Cloud VPN und MTU finden Sie unter Tunnel-MTU.

MTU-Unterschiede mit Cloud Interconnect

Cloud Interconnect kann eine MTU von 1440 oder 1500 haben.

Wenn die kommunizierenden VMs eine MTU von 1500 haben und die Interconnect-Verbindung eine MTU von 1440 hat, reduziert MSS Clamping die MTU von TCP-Verbindungen auf 1440 und der TCP-Traffic wird fortgesetzt.

MSS-Clamping wirkt sich nicht auf UDP-Pakete aus. Wenn also das VPC-Netzwerk eine MTU von 1500 und die Interconnect-Verbindung eine MTU von 1440 hat, dann werden UDP-Datagramme mit mehr als 1412 Datenbytes (1412 Byte UDP-Daten + 8 Byte UDP-Header + 20 Byte IPv4-Header = 1440) gelöscht. In einem solchen Fall haben Sie folgende Möglichkeiten:

  • Verringern Sie die MTU des zugehörigen VPC-Netzwerks auf 1.460.
  • Passen Sie Ihre Anwendung so an, dass kleinere UDP-Pakete gesendet werden.
  • Neue Interconnect-Verbindung mit 1500 Byte erstellen

Weitere Informationen zu Cloud Interconnect und MTU finden Sie unter Cloud Interconnect-MTU.

Netzwerkleistung

Latenz

Die gemessene Latenz zwischen den Regionen für Google Cloud-Netzwerke finden Sie in unserem Live-Dashboard. Das Dashboard zeigt Google Clouds durchschnittliche interregionale Leistungsmesswerte zu Latenz und Durchsatz und die Methodik zur Reproduktion dieser Ergebnisse mit PerfKit Benchmarker.

Google Cloud misst normalerweise Umlaufzeitlatenzen von weniger als 55 μs beim 50. Perzentil und Extremwertlatenzen von weniger als 80 μs beim 99. Perzentil zwischen c2-standard-4-VM-Instanzen in derselben Zone.

Google Cloud misst in der Regel Umlaufzeitlatenzen unter 45 μs beim 50. Perzentil und Extremwertlatenzen von weniger als 60 μs beim 99. Perzentil zwischen c2-standard-4-VM-Instanzen im selben Netzwerk mit geringer Latenz (Richtlinie für „kompakte“ Platzierung). Mit einer Richtlinie für kompakte Platzierung verringern Sie die Netzwerklatenz, da damit sichergestellt wird, dass sich die VMs innerhalb desselben Netzwerks mit geringer Latenz befinden.

Methodik: Die zoneninterne Latenz wird über einen Blackbox-Prober überwacht, der in jeder Zone, in der c2-Instanzen verfügbar sind, ständig die TCP_RR-Benchmark netperf zwischen zwei c2-Typ-VMs ausführt. Es werden P50- und P99-Ergebnisse für die Einrichtung mit und ohne Richtlinie für kompakte Platzierung erfasst. Die TCP_RR-Benchmark misst durch Messung der Transaktionsrate die Anfrage/Antwort-Leistung. Wenn Ihre Anwendungen die bestmögliche Latenz erfordern, sind c2-Instanzen zu empfehlen.

Paketverlust

Google Cloud verfolgt den regionenübergreifenden Paketverlust, indem regelmäßig der Umlaufverlust zwischen allen Regionen gemessen wird. Der globale Durchschnitt dieser Messwerte liegt unter 0,01 %.

Methodik: Ein VM-zu-VM-Blackbox-Prober überwacht den Paketverlust für jedes Zonenpaar mithilfe von Pings und fasst die Ergebnisse in einem globalen Verlustmesswert zusammen. Dieser Messwert wird für einen Zeitraum von einem Tag erfasst.

Nächste Schritte

Jetzt testen

Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit von VPC in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

VPC kostenlos testen