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-Befehlszeile 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 folgende 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

Jedes Subnetz hat einen primären IPv4-Adressbereich. 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.

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 zusätzliche Validierungen jedoch, ein solches Subnetz zu erstellen. Ein Subnetzbereich darf sich beispielsweise nicht mit einem privaten IPv4-Bereich oder einem anderen reservierten Bereich überschneiden. Um die Wahrscheinlichkeit zu minimieren, dass ein ungültiger Subnetzbereich ausgewählt wird, 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 überschneiden } von Subnetzen in Peering-Netzwerken. Google Cloud verhindert in diesen Szenarien die Erstellung überlappender 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
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.

  • 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

  • IPv6-Subnetzbereiche sind regionale Ressourcen.

  • Interne und externe IPv6-Subnetzbereiche sind in allen Regionen verfügbar.

  • IPv6-Subnetzbereiche werden automatisch /64-Bereichen zugewiesen.

  • Der IPv6-Zugriffstyp (interne oder externe) eines Subnetzes kann nicht geändert werden.

  • Sie können ein Dual-Stack-Subnetz nicht in Single-Stack-Subnetz ändern, wenn der IPv6-Zugriffstyp intern ist.

Interne IPv6-Spezifikationen

  • Interne IPv6-Bereiche verwenden 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.

  • Weisen Sie dem VPC-Netzwerk zuerst einen internen IPv6-Bereich zu, um Subnetze mit internen IPv6-Bereichen zu erstellen. Ein IPv6-Bereich /48 ist zugewiesen. Wenn Sie ein Subnetz mit einem internen IPv6-Bereich erstellen, wird der Bereich /64 des Subnetzes aus dem Bereich des VPC-Netzwerks zugewiesen.

    • Der interne IPv6-Bereich eines VPC-Netzwerks ist in Google Cloud eindeutig.

    • Sie können Google den VPC-Netzwerk internen IPv6-Bereich zuweisen lassen oder einen bestimmten Bereich auswählen. Wenn Ihr VPC-Netzwerk eine Verbindung zu Netzwerken außerhalb von Google Cloud herstellt, können Sie einen Bereich auswählen, der sich nicht mit den Bereichen in diesen Umgebungen überschneidet.

  • Die Zuweisung des internen IPv6-Bereichs /48 eines VPC-Netzwerks ist permanent. Sie können sie nicht deaktivieren oder später ändern.

  • Sie können statische regionale interne IPv6-Adressen reservieren.

Kein anderes VPC-Netzwerk kann denselben Bereich verwenden. Dadurch kann es bei Verwendung von VPC-Netzwerk-Peering nicht zu überlappenden IPv6-Subnetzbereichen kommen.

Externe IPv6-Spezifikationen

IPv6-Bereichszuweisung

IPv6-Bereiche können Netzwerken, Subnetzen und VM-Instanzen zugewiesen werden.

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 (VM) /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