Subnetze

VPC-Netzwerke (Virtual Private Cloud) sind globale Ressourcen. Jedes VPC-Netzwerk besteht aus einem oder mehreren IP-Adressbereichen, die als Subnetze bezeichnet werden. Subnetze sind regionale Ressourcen, denen IP-Adressbereiche zugeordnet sind.

In Google Cloud sind die Begriffe Subnetz und Subnetzwerk synonym. Sie sind in der Google Cloud Console, in Befehlen der Google Cloud CLI und in der API-Dokumentation austauschbar.

Netzwerke und Subnetze

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:

  • Beim Erstellen einer Instanz wählen Sie eine Zone für die Instanz aus. Wenn Sie kein Netzwerk für die VM auswählen, wird das Standard-VPC-Netzwerk verwendet, das in jeder Region ein Subnetz hat. Wenn Sie ein Netzwerk für die VM auswählen, müssen Sie ein Netzwerk auswählen, das ein Subnetz in der übergeordneten Region der ausgewählten Zone enthält.

  • Wenn Sie eine verwaltete Instanzgruppe erstellen, wählen Sie je nach Gruppentyp eine Zone oder Region und eine Instanzvorlage aus. Die Instanzvorlage definiert, welches VPC-Netzwerk verwendet werden soll. Wenn Sie eine verwaltete Instanzgruppe erstellen, müssen Sie daher eine Instanzvorlage mit einer geeigneten Konfiguration auswählen. Die Vorlage muss ein VPC-Netzwerk mit Subnetzen in der ausgewählten Zone oder Region auswählen. VPC-Netzwerke im automatischen Modus haben immer ein Subnetz in jeder Region.

  • Zur Erstellung eines Kubernetes-Container-Clusters gehört die Auswahl einer Zone oder Region (abhängig vom Clustertyp), eines Netzwerks und eines Subnetzes. Sie müssen ein Subnetz auswählen, das in der ausgewählten Zone oder Region ausgewählt ist.

Subnetztypen

VPC-Netzwerke unterstützen die folgenden Subnetztypen:

  • Nur-IPv4-Subnetze (Single-Stack) mit nur IPv4-Subnetzbereichen

  • IPv4- und IPv6-Subnetze (Dual-Stack) mit IPv4- und IPv6-Subnetzbereichen

Ein einzelnes VPC-Netzwerk kann eine beliebige Kombination dieser Subnetztypen enthalten.

Beim Erstellen eines Subnetzes geben Sie an, welcher Stack-Typ verwendet werden soll. Sie können auch ein vorhandenes IPv4-Subnetz aktualisieren, um es als Dual-Stack-Subnetz zu konfigurieren.

Dual-Stack-Subnetze werden nur in VPC-Netzwerken im benutzerdefinierten Modus unterstützt. Dual-Stack-Subnetze werden in VPC-Netzwerken im Legacy-Modus oder Legacy-Netzwerken nicht unterstützt.

Geben Sie beim Erstellen eines IPv4-Subnetzbereichs die folgenden Informationen an:

Subnetzeinstellung Zulässige Werte Details
IPv4-Bereich Ein gültiger Bereich, den Sie auswählen Erforderlich
Sekundärer IPv4-Bereich Ein gültiger Bereich, den Sie auswählen Optional

Geben Sie beim Erstellen eines IPv6-Subnetzbereichs die folgenden Informationen an:

Subnetzeinstellung Zulässige Werte Details
IPv6-Zugriffstyp

  • Intern
  • Extern

Dem Subnetz wird automatisch ein IPv6-Adressbereich /64 zugewiesen.

Zwecke von Subnetzen

Subnetze können für verschiedene Zwecke verwendet werden:

  • Reguläre Subnetze: Das ist der Standardsubnetztyp. Reguläre Subnetze werden von Nutzern erstellt oder automatisch in VPC-Netzwerken im automatischen Modus erstellt, um mit VM-Instanzen verwendet zu werden. Reguläre Subnetze haben in der gcloud CLI oder API den Zweck PRIVATE. Der Zweck in der Google Cloud Console ist Keine.
  • Private Service Connect-Subnetze: Ein Subnetz, das zum Veröffentlichen eines verwalteten Dienstes über Private Service Connect verwendet wird.
  • Nur-Proxy-Subnetze: Ein Nur-Proxy-Subnetz, das mit regionalen Envoy-basierten Load-Balancern verwendet wird.
  • Private NAT-Subnetze: Ein Subnetz, das für die Verwendung als Quellbereich für Private NAT reserviert ist. Dieses Subnetz ist auf --purpose=PRIVATE_NAT festgelegt.

In den meisten Fällen können Sie den Zweck eines Subnetzes nicht ändern, nachdem es erstellt wurde. Weitere Informationen finden Sie in der gcloud compute networks subnets update-Befehlsreferenz.

Einschränkungen bei der Benennung von Subnetzen

Für Subnetznamen gelten die folgenden Einschränkungen:

  • Innerhalb eines Google Cloud-Projekts darf ein Subnetz nicht denselben Namen wie ein VPC-Netzwerk haben, sofern es nicht Mitglied dieses Netzwerks ist. Innerhalb eines Projekts dürfen Namen von Subnetzen in derselben Region nur einmal vorkommen. Beispiel: Ein Netzwerk namens production kann mehrere Subnetze haben, die ebenfalls production heißen, solange sich jedes dieser Subnetze in einer eigenen Region befindet.

  • Sie können den Namen oder die Region eines Subnetzes nicht ändern, nachdem Sie das Subnetz erstellt haben. Es ist jedoch möglich, ein Subnetz zu löschen und zu ersetzen, solange es von keiner Ressource verwendet wird.

IPv4-Subnetzbereiche

Subnetze müssen einen primären IPv4-Adressbereich haben. Wenn der Zweck eines Subnetzes PRIVATE oder NONE ist, kann der primäre IPv4-Bereich von Folgendem verwendet werden:

Subnetze können optional einen oder mehrere sekundäre IPv4-Adressbereiche haben, die nur von Alias-IP-Bereichen verwendet werden können. Ein Alias-IP-Bereich kann entweder aus dem primären IPv4-Bereich oder einem sekundären IPv4-Bereich eines Subnetzes stammen.

Ihre IPv4-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. Jedoch kann der primäre Bereich eines Subnetzes 10.0.0.0/24 sein, während der primäre Bereich eines anderen Subnetzes im selben Netzwerk 192.168.0.0/16 sein kann.

Einschränkungen für IPv4-Subnetzbereiche

Für IPv4-Subnetzbereiche gelten die folgenden Einschränkungen:

  • Für alle Subnetze in einem VPC-Netzwerk muss jeder primäre oder sekundäre IPv4-Bereich ein eindeutiger gültiger CIDR-Block sein.

  • Die Anzahl der sekundären IP-Adressbereiche, die Sie definieren können, wird unter Limits pro Netzwerk beschrieben.

  • Nachdem Sie ein Subnetz erstellt haben, kann der primäre IPv4-Bereich für das Subnetz erweitert, aber nicht ersetzt oder verkleinert werden.

  • Sie können den sekundären IPv4-Adressbereich eines Subnetzes nur entfernen und ersetzen, wenn keine Instanzen diesen Bereich verwenden.

  • Die Mindestgröße des primären oder sekundären Bereichs liegt bei acht IPv4-Adressen. Die längste Subnetzmaske, die Sie verwenden können, ist also /29.

  • Die kürzeste Subnetzmaske, die Sie verwenden können, ist /4. Bei den meisten /4-IP-Adressbereichen verhindern jedoch zusätzliche Validierungen, dass Sie ein so großes Subnetz erstellen. Ein Subnetzbereich darf sich beispielsweise nicht mit einem privaten IPv4-Bereich oder einem anderen reservierten Bereich überschneiden. Um die Wahrscheinlichkeit zu minimieren, dass Sie einen ungültigen Subnetzbereich auswählen, empfehlen wir, die maximale Subnetzgröße auf /8 zu begrenzen.

  • Sie können keine primären und sekundären Bereiche für Subnetze erstellen, die sich mit einem zugewiesenen Bereich, einem primären oder sekundären Bereich eines anderen Subnetzes im selben Netzwerk oder IPv4-Bereichen von Subnetzen in Peering-Netzwerken überschneiden. In diesen Fällen verhindert Google Cloud das Erstellen sich überschneidender Subnetzbereiche.

  • Google Cloud erstellt entsprechende Subnetzrouten für primäre und sekundäre IP-Bereiche. Per Definition müssen Subnetzrouten und daher Subnetz-IP-Bereiche die spezifischsten IP-Bereiche haben.

  • 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. Beispiel: 172.0.0.0/10 ist kein gültiger Subnetzbereich, da er sowohl den privaten IP-Adressbereich 172.16.0.0/12 als auch öffentliche IP-Adressen enthält.

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

Gültige IPv4-Bereiche

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

Bereich Beschreibung
Private IPv4-Adressbereiche
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Private IP-Adressen RFC 1918

Informationen zur Verwendung von 172.17.0.0/16 finden Sie unter Zusätzliche Überlegungen.

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-Adressbereiche
Privat genutzte öffentliche IPv4-Adressen Privat genutzte öffentliche IPv4-Adressen:
  • IPv4-Adressen, die normalerweise im Internet geroutet werden können, aber in einem VPC-Netzwerk privat genutzt werden
  • Sie können nicht zu einem unzulässigen Subnetzbereich gehören

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.

Wenn Sie mithilfe von Bring your own IP (BYOIP) öffentliche IP-Adressen bei Google importiert haben, dürfen Ihre BYOIP-Bereiche und privat genutzten öffentlichen IP-Adressbereiche im selben VPC-Netzwerk nicht überlappen.

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.

Unzulässige IPv4-Subnetzbereiche

Unzulässige Subnetzbereiche 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

Nicht verwendbare Adressen in IPv4-Subnetzbereichen

Google Cloud verwendet zum Hosten des Subnetzes die ersten beiden und die letzten beiden IPv4-Adressen in jedem primären IPv4-Adressbereich des Subnetzes. Mit Google Cloud können Sie alle Adressen in sekundären IPv4-Bereichen verwenden.

Nicht verwendbare IPv4-Adresse Beschreibung Beispiel
Netzwerkadresse Erste Adresse im primären IPv4-Bereich 10.1.2.0 aus dem Bereich 10.1.2.0/24
Standard-Gateway-Adresse Zweite Adresse im primären IPv4-Bereich 10.1.2.1 aus dem Bereich 10.1.2.0/24
Vorletzte Adresse Vorletzte Adresse im primären IPv4-Bereich

Dieser Bereich ist von Google Cloud für eine mögliche zukünftige Verwendung reserviert.

 10.1.2.254 aus dem Bereich 10.1.2.0/24
Übertragungsadresse Letzte Adresse im primären IPv4-Bereich 10.1.2.255 aus dem Bereich 10.1.2.0/24

IPv4-Bereiche im automatischen Modus

Diese Tabelle enthält die IPv4-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)
africa-south1 10.218.0.0/20 10.218.0.1 10.218.0.2 bis 10.218.15.253
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
europe-west8 10.198.0.0/20 10.198.0.1 10.198.0.2 bis 10.198.15.253
europe-west9 10.200.0.0/20 10.200.0.1 10.200.0.2 bis 10.200.15.253
europe-west10 10.214.0.0/20 10.214.0.1 10.214.0.2 bis 10.214.15.253
europe-west12 10.210.0.0/20 10.210.0.1 10.210.0.2 bis 10.210.15.253
europe-southwest1 10.204.0.0/20 10.204.0.1 10.204.0.2 bis 10.204.15.253
me-central1 10.212.0.0/20 10.212.0.1 10.212.0.2 bis 10.212.15.253
me-central2 10.216.0.0/20 10.216.0.1 10.216.0.2 bis 10.216.15.253
me-west1 10.208.0.0/20 10.208.0.1 10.208.0.2 bis 10.208.15.253
northamerica-northeast1 10.162.0.0/20 10.162.0.1 10.162.0.2 bis 10.162.15.253
northamerica-northeast2 10.188.0.0/20 10.188.0.1 10.188.0.2 bis 10.188.15.253
northamerica-south1 10.224.0.0/20 10.224.0.1 10.224.0.2 bis 10.224.15.253
southamerica-east1 10.158.0.0/20 10.158.0.1 10.158.0.2 bis 10.158.15.253
southamerica-west1 10.194.0.0/20 10.194.0.1 10.194.0.2 bis 10.194.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-east5 10.202.0.0/20 10.202.0.1 10.202.0.2 bis 10.202.15.253
us-south1 10.206.0.0/20 10.206.0.1 10.206.0.2 bis 10.206.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

Weitere Überlegungen

Achten Sie darauf, dass keine primären und sekundären IPv4-Adressbereiche mit den IPv4-Adressbereichen in Konflikt stehen, die die Software innerhalb Ihrer VMs verwenden muss. Einige Google- und Drittanbieterprodukte verwenden 172.17.0.0/16 für das Routing innerhalb des Gastbetriebssystems. Das Standard-Docker-Bridge-Netzwerk verwendet beispielsweise diesen Bereich. Wenn Sie ein Produkt benötigen, das 172.17.0.0/16 verwendet, verwenden Sie es nicht als primären und sekundären IPv4-Adressbereich des Subnetzes.

IPv6-Subnetzbereiche

Wenn Sie IPv6 in einem Subnetz aktivieren, wird ein IPv6-Zugriffstyp für das Subnetz ausgewählt. Der IPv6-Zugriffstyp bestimmt, ob das Subnetz mit internen IPv6-Adressen oder externen IPv6-Adressen konfiguriert ist. Das Subnetz wird zu einem Dual-Stack-Subnetz.

  • Interne IPv6-Adressen werden für die VM-zu-VM-Kommunikation in VPC-Netzwerken verwendet. Sie können nur im Bereich von VPC-Netzwerken und nicht an das Internet weitergeleitet werden.

  • Externe IPv6-Adressen können für die VM-zu-VM-Kommunikation in VPC-Netzwerken verwendet werden und außerdem im Internet weitergeleitet werden.

Wenn eine VM-Schnittstelle mit einem Subnetz mit einem IPv6-Subnetzbereich verbunden ist, können Sie IPv6-Adressen auf der VM konfigurieren. Der IPv6-Zugriffstyp des Subnetzes bestimmt, ob der VM eine interne IPv6-Adresse oder eine externe IPv6-Adresse zugewiesen wird.

IPv6-Spezifikationen

Dual-Stack-Subnetze sind in allen Regionen verfügbar und unterstützen sowohl interne als auch externe IPv6-Subnetzbereiche:

  • IPv6-Subnetzbereiche werden immer automatisch von Google Cloud zugewiesen.
  • IPv6-Subnetzbereiche sind immer /64-Bereiche.

Für Dual-Stack-Subnetze gelten die folgenden Einschränkungen:

  • Der IPv6-Zugriffstyp (interne oder externe) eines Subnetzes kann nicht geändert werden.
  • Sie können ein Dual-Stack-Subnetz nicht in ein Single-Stack-Subnetz ändern, wenn der IPv6-Zugriffstyp intern ist.

Interne IPv6-Spezifikationen

Interne IPv6-Bereiche sind eindeutige lokale Adressen (ULAs). ULAs für IPv6 entsprechen den RFC 1918-Adressen für IPv4. ULAs können nicht über das Internet erreicht werden und sind nicht öffentlich routingfähig.

Bevor Sie Subnetze mit internen IPv6-Bereichen erstellen können, müssen Sie zuerst dem VPC-Netzwerk einen ULA-IPv6-Bereich /48 zuweisen. Beachten Sie Folgendes, wenn Sie einem VPC-Netzwerk einen ULA-IPv6-Bereich /48 zuweisen:

  • Der ULA-IPv6-Bereich /48 für jedes VPC-Netzwerk muss in Google Cloud eindeutig sein. Dadurch kann es bei Verwendung von VPC-Netzwerk-Peering nicht zu überlappenden IPv6-Subnetzbereichen kommen.

  • Sie können Google Cloud erlauben, dem VPC-Netzwerk automatisch einen /48-ULA-IPv6-Bereich zuzuweisen, oder Sie können einen /48-ULA-IPv6-Bereich angeben, der verwendet werden soll. Wenn der von Ihnen angegebene ULA-IPv6-Bereich /48 bereits von einem anderen Google Cloud-VPC-Netzwerk verwendet wird, erhalten Sie eine Fehlermeldung.

  • Die Option zum Angeben eines /48-ULA-IPv6-Bereichs ist nützlich, um Konflikte zwischen Ihrem VPC-Netzwerk und verbundenen lokalen Netzwerken oder Netzwerken bei anderen Cloud-Anbietern zu vermeiden.

  • Nachdem einem VPC-Netzwerk ein /48-IPv6-ULA-Bereich zugewiesen wurde, können Sie den /48-IPv6-ULA-Bereich nicht mehr entfernen oder ändern.

Wenn Sie ein Subnetz mit einem internen IPv6-Bereich erstellen, wählt Google Cloud automatisch einen nicht verwendeten IPv6-Bereich /64 aus dem ULA-IPv6-Bereich /48 des VPC-Netzwerks aus. Interne /64-IPv6-Bereiche von Subnetzen können für Folgendes verwendet werden:

Sie können auch statische regionale interne IPv6-/96-Adressbereiche reservieren.

Externe IPv6-Spezifikationen

Externe IPv6-Adressbereiche sind globale Unicast-Adressen (GUAs). Externe IPv6-Adressen sind nur in der Premium-Stufe verfügbar.

Wenn Sie ein Subnetz mit einem externen IPv6-Adressbereich erstellen, wählt Google Cloud automatisch einen nicht verwendeten /64-IPv6-Bereich aus. Externe /64-IPv6-Adressbereiche eines Subnetzes können von folgenden Elementen verwendet werden:

Sie können auch statische regionale externe IPv6-Adressbereiche/96 reservieren.

IPv6-Bereichszuweisung

IPv6-Adressbereiche werden Netzwerken, Subnetzen, VM-Instanzen und Weiterleitungsregeln zugewiesen.

Ressourcentyp Bereichsgröße Details
VPC-Netzwerk /48

Damit Sie internes IPv6 in einem Subnetz aktivieren können, müssen Sie zuerst einen internen IPv6-Bereich im VPC-Netzwerk zuweisen.

Dem Netzwerk wird ein /48-ULA-Bereich aus fd20::/20 zugewiesen. Alle internen IPv6-Subnetzbereiche im Netzwerk werden aus diesem /48-Bereich zugewiesen.

Der Bereich /48 kann automatisch zugewiesen werden oder Sie können einen bestimmten Bereich aus fd20::/20 auswählen.
Subnetz /64

Mit der IPv6-Zugriffstypeinstellung wird gesteuert, ob die IPv6-Adressen intern oder extern sind.

Ein Subnetz kann entweder interne oder externe IPv6-Adressen haben, aber nicht beides.

Wenn Sie IPv6 aktivieren, geschieht Folgendes:

  • Wenn Sie internes IPv6 in einem Subnetz aktivieren, wird aus dem /48-Bereich Ihres VPC-Netzwerks ein /64-Bereich interner ULAs zugewiesen.
  • Wenn Sie externe IPv6 in einem Subnetz aktivieren, wird ein /64-Bereich externer GUAs zugewiesen.
VM-Instanz (virtuelle Maschine) oder Weiterleitungsregel /96

Wenn Sie IPv6 auf einer VM aktivieren, wird der VM der Bereich /96 aus dem Subnetz zugewiesen, mit dem sie verbunden ist. Die erste IP-Adresse in diesem Bereich wird der primären Schnittstelle mithilfe von DHCPv6 zugewiesen.

Sie konfigurieren nicht, ob eine VM interne oder externe IPv6-Adressen erhält. Die VM übernimmt den IPv6-Zugriffstyp aus dem Subnetz, mit dem sie verbunden ist.

Nächste Schritte

Überzeugen Sie sich selbst

Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit von Cloud NAT 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.

Cloud NAT kostenlos testen