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 (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 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 (Beta) mit Ausnahme von Traffic über Cloud VPN, Cloud Interconnect und Weiterleitungsregeln für das Load-Balancing und die Protokollweiterleitung: GRE ermöglicht es Ihnen, Dienste wie SASE (Secure Access Service Edge) und SD-WAN zu verwenden.

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

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 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 wiederverwendete ö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, leitet Google Cloud den Traffic nicht öffentlich an sie weiter.

Beim VPC-Netzwerk-Peering werden Subnetzrouten für öffentliche IP-Adressen nicht automatisch ausgetauscht. Die Subnetzrouten werden 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.0.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-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
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

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

Höchstdurchsatz für ausgehenden Traffic

Informationen zum Netzwerkdurchsatz finden Sie im Abschnitt Netzwerkbandbreite.

Paketgröße

Informationen zur Paketgröße finden Sie im Abschnitt Maximale Übertragungseinheit (Maximum transmission unit, MTU).

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 maximale 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. (Siehe: PMTUD).
  • Wenn ein UDP-Paket gesendet wird, das größer ist, als das Ziel empfangen kann, oder das die maximale 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. Führen Sie den folgenden Befehl auf jeder Windows-VM aus, um die MTU festzulegen: netsh interface ipv4 set subinterface NAME mtu=1500 store=persistent

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.

Zur Minimierung nicht vorhersehbarer Netzwerkverbindungen empfiehlt Google Cloud, die MTU eines VPC-Netzwerks folgendermaßen zu ändern:

  1. Beenden Sie alle VMs im VPC-Netzwerk.
  2. Ändern Sie die MTU des VPC-Netzwerks.
  3. Starten Sie alle VMs im VPC-Netzwerk. Linux-VMs mit der Gastumgebung von Google und mit VMs, die die MTU mit DHCP-Option 26 einstellen, legen ihre MTUs beim Start korrekt fest.
  4. Konfigurieren Sie alle Windows-VMs und VMs mit einer festen MTU-Konfiguration so, dass sie den neuen MTU-Wert verwenden.

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. Erstellen Sie neue VMs im neuen Netzwerk. Sie können sie von Grund auf neu sowie aus einem vorhandenen Image erstellen oder durch Erstellen eines Snapshots der vorhandenen VMs und diesen zum Befüllen der neuen nichtflüchtigen Speicher verwenden.
  7. Konfigurieren Sie diese VMs für die Verwendung des operativen Servers.
  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.

Unterschiede bei MTU zwischen Peering-VPC-Netzwerken

Informationen darüber, wie VPC-Netzwerk-Peering mit Unterschieden zwischen den MTUs von Netzwerken umgeht, finden Sie unter Überlegungen zur MTU.

MTU-Unterschiede mit Cloud VPN

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

MTU-Unterschiede mit Cloud Interconnect

Cloud Interconnect hat derzeit eine MTU von 1440.

Wenn die kommunizierenden VMs eine MTU von 1500 haben, 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 das VPC-Netzwerk eine MTU von 1500 hat, werden UDP-Datagrams mit mehr als 1.412 Byte an Daten (1.412 Byte UDP-Daten + 8 Byte UDP-Header + 20 Byte IPv4-Header = 1.440) 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.

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.

Weitere Informationen