Subnetze und IP-Adressen in GDC

Auf dieser Übersichtsseite wird das Betriebsmodell für IP-Adressen in einer Air-Gap-Umgebung von Google Distributed Cloud (GDC) erläutert. IP-Adressen werden in Subnetze unterteilt, um überschaubare Segmente zu schaffen, die Sie Ihren Diensten zuweisen können. Sie können Subnetze mit bestimmten IP-Adressbereichen definieren oder für die dynamische Zuweisung konfigurieren.

Diese Seite richtet sich an Netzwerkadministratoren in der Gruppe „Plattformadministrator“ und Anwendungsentwickler in der Gruppe „Anwendungsoperator“, die für die Verwaltung des Netzwerkverkehrs für ihre Dienste in einem GDC-Universum verantwortlich sind. Weitere Informationen finden Sie unter Zielgruppen für die GDC-Dokumentation für Air-Gap-Umgebungen.

Netzwerke in GDC

In einer GDC-Organisation sind zwei verschiedene Netzwerktypen verfügbar, für die Sie IP-Adressen zuweisen können:

  • Virtual Private Cloud (VPC): Ein Netzwerk, dem interne IP-Adressen zugewiesen sind, auf die nur von Arbeitslasten innerhalb Ihrer Organisation zugegriffen werden kann.
  • Externes Netzwerksegment: Ein Netzwerk, dem externe IP-Adressen zugewiesen sind, auf die externe Netzwerke zugreifen können, die mit Ihrer Organisation verbunden sind.

Sie können Subnetze innerhalb der einzelnen Netzwerktypen zuweisen, um bestimmte Ziele zu erreichen. Ein Subnetz ist eine logische Unterteilung eines IP-Adressnetzwerks, das durch CIDR-Bereiche (Classless Inter-Domain Routing) definiert wird. Mit CIDR-Bereichen können Sie IP-Adressen und die entsprechenden Netzwerke für einen Dienst darstellen. Jedes Netzwerk dieser Netzwerktypen hat einen unabhängigen Subnetzbaum.

Subnetze innerhalb einer VPC sind über das GDC-Netzwerk zugänglich und können nicht außerhalb von GDC erreicht werden. VPC-Subnetze sind verfügbar, um interne IP-Adressen in Ihrer Organisation zuzuweisen. Subnetze für Netzwerksegmente sind für externe Netzwerke verfügbar, die mit einer Organisation verbunden sind. So können Sie externe IP-Adressen für Netzwerke außerhalb Ihrer Organisation bereitstellen.

VPC-Netzwerk

Ein VPC-Netzwerk verwendet interne IP-Adressen, auf die nur innerhalb Ihrer Organisation zugegriffen werden kann und die von Netzwerken außerhalb Ihrer Organisation nicht erreicht werden können.

In Ihrem GDC-Universum sind zwei VPC-Netzwerke verfügbar:

  • Standard-VPC: Eine VPC, der IP-Adressen für interne Arbeitslasten wie Container und virtuelle Maschinen (VMs) innerhalb und über mehrere Zonen hinweg zugewiesen werden.
  • Infra-VPC: Eine vom System verwaltete VPC, in der GDC-Air-Gap-Dienste von Google gehostet werden, z. B. Vertex AI, Observability APIs und die GDC-Konsole. Sie definieren IP-Adressen in dieser VPC nur, wenn Sie die IP-Adressarchitektur Ihrer Organisation planen.

IP-Adressen in der Standard-VPC und der Infra-VPC dürfen sich innerhalb derselben Organisation nicht überschneiden. Weitere Informationen finden Sie unter IPv4-Nutzung und ‑Einschränkungen.

Erstellen Sie ein Subnetz in einem VPC-Netzwerk, um zusätzliche IP-Adressen für interne Arbeitslasten zuzuweisen.

Externes Netzwerksegment

Einem externen Netzwerksegment werden externe IP-Adressen zugewiesen, auf die externe Netzwerke zugreifen können, die mit Ihrer Organisation verbunden sind. Netzwerksegmenten in GDC werden nur externe IP-Adressen zugewiesen.

GDC bietet die folgenden logisch isolierten Netzwerksegmente:

Sie können separate Interconnects verwenden, um Netzwerksegmente mit anderen externen Netzwerken zu verbinden. IP-Adressen in den Netzwerksegmenten dürfen sich nicht überschneiden. Weitere Informationen finden Sie unter IPv4-Nutzung und ‑Einschränkungen.

Erstellen Sie ein Subnetz in einem Netzwerksegment, um zusätzliche externe IP-Adressen für Dienste zuzuweisen, die eine Verbindung zu Netzwerken außerhalb Ihrer GDC-Organisation herstellen müssen.

Subnetz-Hierarchie

Subnetze werden nach ihrem Typ kategorisiert:

  • Root: Subnetze der obersten Ebene, aus denen andere Subnetze abgeleitet werden können. Bei der Bereitstellung Ihrer Organisation wird in jedem Netzwerk ein globales Stamm-Subnetz erstellt.
  • Branch (Zweig): Subnetze, die von einem Stamm- oder einem anderen Zweigsubnetz abgeleitet werden und zum weiteren Unterteilen des IP-Adressraums verwendet werden.
  • Leaf: Die kleinste Unterteilung, die in der Regel zum Zuweisen von IP-Adressen für einen bestimmten Dienst oder eine bestimmte Ressource verwendet wird.

Sie können Ihre Subnetze unterteilen, um Ihren Netzwerken IP-Adressen zuzuweisen.

Das folgende Diagramm veranschaulicht, wie die verschiedenen Subnetztypen miteinander verbunden sind:

  • Ein Stamm-Subnetz von 10.0.0.0/16, das als übergeordneter Block für wichtige IP-Adresszuweisungen dient.
  • Aus dem Stamm-Subnetz werden zwei untergeordnete Subnetze mit den Werten 10.0.1.0/24 und 10.0.2.0/24 abgeleitet. Diese Zweig-Subnetze stellen Unterteilungen des Adressbereichs des Root-Subnetzes dar, die für spezifischere Zwecke vorgesehen sind.
  • Die Zweigsubnetze werden weiter in Blattsubnetze mit Werten wie 10.0.1.10/32, 10.0.1.11/32 und 10.0.2.12/24 unterteilt. Diese untergeordneten Subnetze sind in der Regel die kleinsten Unterteilungen, wobei oft einzelne IP-Adressen für bestimmte Dienste oder Ressourcen zugewiesen werden.

Mit dieser hierarchischen Subnetzstruktur können Sie Ihr Netzwerk effizient auf die Arbeitslasten und Dienste verteilen und organisieren, die auf die IP-Adressen in Ihrem Netzwerk angewiesen sind.

Globale und zonale Subnetze

In GDC können Sie Subnetze in zwei verschiedenen Bereichen bereitstellen: zonal und global. Zonale und globale Subnetze werden auf separaten API-Servern definiert und ausgeführt und bieten unterschiedliche Funktionen.

Nachdem Ihre Organisation bereitgestellt wurde, hat jedes Netzwerk ein globales Stamm-Subnetz, das auf dem globalen API-Server Ihrer Organisation gehostet wird. Wenn Sie IP-Adressen aus dem globalen Stamm-Subnetz bereitstellen möchten, müssen Sie eine globale Subnet-Ressource auf dem globalen API-Server erstellen, mit der ein CIDR-Block für eine Zone oder für mehrere Zonen bereitgestellt wird. Im globalen Subnetz definieren Sie das Feld propagationStrategy, um anzugeben, wie Sie Ihren CIDR-Block auf Zonen verteilen möchten. Dieser IP-Adressbereich wird einer Zone als zonales Root-Subnetz zugewiesen.

Nachdem eine Zone über ein eigenes zonales Stamm-Subnetz verfügt, können Sie zonale Subnet-Ressourcen auf dem Management-API-Server der Zone erstellen, um den IP-Adressbereich des Subnetzes in zusätzliche Zweig-Subnetze innerhalb der Zone oder in Blatt-Subnetze zu unterteilen, die für einzelne Arbeitslasten und Dienste innerhalb der Zone verfügbar sind.

Globale Subnetze

Sie müssen ein globales Subnetz erstellen, um IP-Adressen aus dem im globalen API-Server gehosteten Stamm-Subnetz einer oder mehreren Zonen in Ihrem GDC-Universum zuzuweisen.

Globale Subnetze werden auf dem globalen API-Server mit der API-Gruppe ipam.global.gdc.goog/v1 erstellt und enthalten optionale Felder wie zone und propagationStrategy, um ihre Interaktion mit bestimmten Zonen zu definieren.

Globale Subnetze enthalten einen CIDR-Block als Branch-Subnetzbereich, der von Zonen in einem GDC-Universum verwendet wird. Weitere Informationen dazu, wo Sie Ihre globalen Subnetze erstellen können, finden Sie unter Netzwerke in GDC.

Zonale Subnetze

Ein zonales Subnetz ist mit einer bestimmten Betriebszone verknüpft und enthält oft direkte Netzwerkkonfigurationen. Zonale Subnetze funktionieren ausschließlich innerhalb einer einzelnen Zone und sind hauptsächlich für virtuelle Maschinen und Container-Arbeitslasten in dieser Zone vorgesehen. In einem zonalen Subnetz werden IP-Adressen, die bereits für die Zone bereitgestellt wurden, für die Verwendung durch ein globales Subnetz zugewiesen.

Damit die VPC-zu-VPC-Kommunikation über Zonen hinweg ordnungsgemäß funktioniert, müssen in jeder Zone nicht überlappende Subnetze verwendet werden.

Zonale Subnetze werden auf dem Management-API-Server mit der API-Gruppe ipam.gdc.goog/v1 erstellt und enthalten in ihrer Spezifikation ein optionales Feld networkSpec, sodass Sie zonenspezifische Netzwerkelemente wie Gateways und VLAN-IDs definieren können.

Regeln für die Subnetzgruppierung

Subnetze werden in der benutzerdefinierten Ressource Subnet anhand von Labels in verschiedene Kategorien gruppiert:

Netzwerk Label
Standard-VPC ipam.gdc.goog/vpc: default-vpc
Infra-VPC ipam.gdc.goog/vpc: infra-vpc
Admin-Netzwerksegment ipam.gdc.goog/network-segment: admin
Datensegment für das Netzwerk ipam.gdc.goog/network-segment: data

Die vier CIDR-Bereiche wurden im Rahmen des Bootstrap-Vorgangs in Ihrer Organisation festgelegt. Die vier entsprechenden globalen Subnetze befinden sich auf dem globalen API-Server. Diese globalen Subnetze sind der CIDR-Bereich auf Stammebene für jedes Netzwerk in allen Zonen einer Organisation. Alle globalen Subnetze auf Stammebene haben das Label ipam.gdc.goog/usage: network-root-range.

Für jede Zone ist anfangs ein zonales Netzwerk-Root-Subnetz auf dem globalen API-Server verfügbar, das aus der Organisationsbereitstellung stammt. Sie können zusätzliche Stamm-Subnetze erstellen, um Ihren IP-Adressraum zu erweitern. Jedes Stamm-Subnetz enthält einen CIDR-Bereich für ein Netzwerk in der jeweiligen Zone und dient logisch als zonenbezogenes Stamm-Subnetz mit dem Label ipam.gdc.goog/usage: zone-network-root-range. Dieses Stamm-Subnetz muss zuerst auf dem globalen API-Server erstellt werden und wird automatisch in eine angegebene Zone übertragen. Weitere Informationen zu Subnetzbereichen finden Sie unter Globale und zonale Subnetze.

Sie müssen die definierten Labels verwenden, wenn Sie eine benutzerdefinierte Subnet-Ressource erstellen, um sie auf das entsprechende GDC-Netzwerk anzuwenden. Das folgende Diagramm veranschaulicht globale und zonale Netzwerke in einem GDC-Universum:

Subnetze befinden sich in einer Zone und auf dem globalen API-Server.

In diesem Diagramm sind zwei Organisationen dargestellt, die sich über ein Universum mit mehreren Zonen erstrecken. Jede Organisation definiert die VPC-Netzwerke und externen Netzwerksegmente. In diesem Beispiel werden Anycast-IP-Adressen verwendet, um den Traffic zwischen den zonenbasierten externen Netzwerksegmenten weiterzuleiten. So kann die Anfrage an die Zone mit der besten Leistung gesendet werden. Weitere Informationen zu Anycast-IP-Adressen finden Sie unter IP-Adressen in GDC.

Statische und dynamische CIDR-Konfiguration

Beim Definieren von Subnetzen können Sie eine statische oder dynamische Konfiguration für die Zuweisung der CIDR-Blöcke verwenden.

Mit der statischen CIDR-Konfiguration können Sie den genauen CIDR-Block für Ihr Subnetz explizit angeben. Weisen Sie Ihren CIDR-Block statisch zu, wenn Sie genaue Kontrolle über Ihren IP-Adressbereich benötigen. Verwenden Sie das Feld spec.ipv4Request.cidr in der benutzerdefinierten Ressource Subnet, um den genauen, vordefinierten IP-Adressbereich anzugeben.

Die dynamische CIDR-Konfiguration bietet mehr Flexibilität, da das System automatisch einen CIDR-Block für Ihr Subnetz zuweisen kann. Anstatt eine vollständige CIDR anzugeben, geben Sie die erforderliche Präfixlänge im Feld spec.ipv4Request.prefixLength an. Weisen Sie Ihren CIDR-Block dynamisch zu, wenn das System IP-Adressen automatisch an Ihre Subnetze delegieren soll. Dadurch wird die Netzwerkplanung vereinfacht und das Risiko von IP-Adresskonflikten verringert. Das System wählt einen verfügbaren CIDR-Block der angegebenen Größe aus dem übergeordneten Netzwerk aus.

Weitere Informationen finden Sie in der SubnetRequest API.

IP-Adressen in GDC

Ressourcen wie VMs und Load-Balancer haben IP-Adressen in GDC. Mit diesen IP-Adressen können GDC-Ressourcen mit anderen Ressourcen innerhalb einer Organisation oder mit externen Netzwerken kommunizieren, die mit Ihrer Organisation verbunden sind. Die folgenden IP-Adresstypen sind in einem GDC-Universum verfügbar:

Externe IP-Adresse

Externe IP-Adressen werden für externe Netzwerke beworben, die mit einer Organisation verbunden sind. Ressourcen mit externen IP-Adressen, z. B. Load Balancer und NAT, können mit externen Netzwerken kommunizieren. Mit GDC können Sie private oder öffentliche IP-Adressen als externe Adressen verwenden. Sie können externe IPv4-Adressen für Ressourcen auf folgende Weise bereitstellen:

  • Eigene externe IP-Adressen verwenden (Bring your own IP, BYOIP): Sie stellen diese externen IP-Adressen für Ihre Organisation bereit. Externe BYOIP-IP-Adressen können sich mit anderen Organisationen überschneiden, sofern sie nicht mit demselben externen Netzwerk verbunden sind.
  • Von IO bereitgestellte externe IP-Adressen: Organisationen können die von der Infrastrukturbetreibergruppe bereitgestellten externen IP-Adressen verwenden, wenn sie eine Verbindung zu einem externen Netzwerk herstellen. Die Infrastrukturbetreibergruppe ist der Anbieter der Konnektivität für dieses Netzwerk.
Interne IP-Adresse

Interne IP-Adressen sind nicht direkt von außerhalb von GDC erreichbar und können nicht öffentlich weitergeleitet werden. Interne IP-Adressen sind lokal in einem VPC-Netzwerk, in einem VPC-Netzwerk, das über VPC-Netzwerk-Peering verbunden ist, oder in einem lokalen Netzwerk, das über Cloud VPN mit einem VPC-Netzwerk verbunden ist. Ressourcen mit internen IP-Adressen kommunizieren mit anderen Ressourcen, als befänden sie sich alle im selben privaten Netzwerk.

Anycast-IP-Adresse

Anycast-IP-Adressen sind eine spezielle Art von externen Adressen, die immer auf das gesamte GDC-Universum beschränkt sind. GDC verwendet Anycast-IP-Adressen zusammen mit dem Border Gateway Protocol (BGP), um den Traffic an die nächstgelegene oder leistungsstärkste Zone weiterzuleiten. Jeder globalen Layer 4-Dienst, der in zwei oder mehr Zonen ausgeführt wird, erhält eine Anycast-IP-Adresse aus dem Anycast-Subnetz, einem externen Subnetz. In jeder Zone wird dieselbe Anycast-IP-Adresse beworben, aber Ihr Netzwerk wählt die beste anhand seiner Routingregeln aus. Wenn eine Zone ausfällt, wird ihre IP-Adresse zurückgezogen und Ihr Netzwerk leitet den Traffic automatisch an eine andere Zone weiter. Dieses automatische Routing sorgt für eine nahtlose Verbindung, auch bei Ausfällen.

Private IP-Adresse

Private IP-Adressen sind Adressen, die nicht im Internet weitergeleitet werden können. Eine Liste der privaten IPv4-Adressbereiche finden Sie in der Tabelle Gültige IPv4-Bereiche.

Öffentliche IP-Adresse

Öffentliche IP-Adressen können über das Internet weitergeleitet werden. In GDC können externe IP-Adressen öffentlich oder privat sein. Sie können öffentliche IPv4-Adressen auch als interne Adressen verwenden, wenn Sie den primären IPv4-Adressbereich eines Subnetzes in Ihrem VPC-Netzwerk konfigurieren. Diese Adressen werden als privat verwendete öffentliche IP-Adressen bezeichnet.

IPv4-Nutzung und ‑Einschränkungen

Für jedes Netzwerk in Ihrem GDC-Universum gelten einige Einschränkungen bei der Verwendung von IPv4-Adressbereichen, die Sie bei der Zuweisung von IP-Adressen berücksichtigen müssen. IPv6-Adressbereiche werden in der Standard-VPC und im Datensegment des Netzwerks nicht unterstützt. Wenden Sie sich an Ihre Infrastrukturbetreibergruppe, um Informationen zu IPv6-Bereichen in anderen Netzwerken zu erhalten.

Einschränkungen für alle IPv4-Subnetze

Diese Einschränkungen gelten für VPC-Netzwerk-Subnetze und Subnetze für externe Netzwerksegmente.

  • Alle Subnetze müssen eindeutige gültige CIDR-Blöcke sein.
  • Nachdem Sie ein Subnetz erstellt haben, kann es nicht mehr vergrößert, ersetzt oder verkleinert werden.
  • GDC erzwingt keine Begrenzung für die Größe eines CIDR. Bei den meisten IP-Adressbereichen, die größer als /8 sind, verhindern zusätzliche Validierungen jedoch, dass Sie ein so großes Subnetz erstellen. Ein Subnetz darf sich beispielsweise nicht mit einem unzulässigen Subnetz überschneiden. Um die Wahrscheinlichkeit zu minimieren, dass Sie ein ungültiges Subnetz auswählen, empfehlen wir, die maximale Subnetzgröße auf /8 zu beschränken.

  • Sie können keine Subnetze erstellen, die sich mit verbotenen Subnetzen, anderen Subnetzen im selben VPC-Netzwerk, Subnetzen in einem angehängten externen Netzwerksegment oder Subnetzen in einem Peering-Netzwerk überschneiden. Sie müssen mit Ihrer Infrastrukturbetreibergruppe zusammenarbeiten, um sicherzustellen, dass in diesen Szenarien keine sich überschneidenden Subnetze erstellt werden.

  • GDC erstellt entsprechende Routen für Subnetze. Für VPC-Netzwerk-Subnetze werden Routen im virtuellen Netzwerk-Stack Ihrer Organisation erstellt. Für Subnetze des externen Netzwerksegments werden Routen in der Routingtabelle des externen Peering-Netzwerks erstellt.

  • Prüfen Sie, ob Subnetze mit lokalen IP-Adressen in Konflikt stehen, wenn Sie Ihr VPC-Netzwerk über ein verwaltetes VPN oder eine freigegebene oder dedizierte Interconnect-Verbindung mit einem anderen Netzwerk verbunden haben.

  • Subnetze dürfen nicht kleiner oder größer als ein unzulässiger Bereich sein oder mit diesem übereinstimmen. 169.0.0.0/8 ist beispielsweise kein gültiges Subnetz, da es sich mit dem Link-Local-Bereich 169.254.0.0/16 (RFC 3927) überschneidet, der eingeschränkt ist.

  • Subnetze dürfen sich nicht über einen RFC-Bereich (wie unter Gültige IPv4-Bereiche beschrieben) und einen privat genutzten öffentlichen IP-Adressbereich erstrecken. Beispiel: 172.0.0.0/10 ist kein gültiges Subnetz, da es sowohl den privaten IP-Adressbereich 172.16.0.0/12 als auch öffentliche IP-Adressen enthält.

  • Subnetze dürfen sich nicht über mehrere RFC-Bereiche erstrecken. Beispielsweise ist 192.0.0.0/8 kein gültiges Subnetz, da es sowohl 192.168.0.0/16 (RFC 1918) als auch 192.0.0.0/24 (RFC 6890) enthält. Sie können jedoch zwei Subnetze erstellen, eines mit 192.168.0.0/16 und eines mit 192.0.0.0/24.

Gültige IPv4-Bereiche

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 dürfen nicht zu einem unzulässigen Subnetzbereich gehören.

Bei GDC Air-Gapped wird keine Verbindung zum Internet vorausgesetzt. Daher werden in GDC Air-Gapped alle öffentlichen IP-Adressbereiche so beworben, als wären sie privat für Ihre Organisation.

Wenn Ihre importierten BYOIP-Adressen (Bring your own IP) öffentliche IP-Adressbereiche sind, müssen Sie dafür sorgen, dass sie in externen Netzwerken keine Netzwerkprobleme verursachen. Ihre BYOIP-Adressen dürfen sich nicht mit anderen Subnetzen in Ihrer Organisation überschneiden.

Unzulässige IPv4-Subnetze

Unzulässige Subnetzbereiche umfassen häufig reservierte RFC-Bereiche und alle global reservierten Subnetze in Ihrem spezifischen GDC-Universum, wie in der folgenden Tabelle beschrieben. Diese Bereiche können nicht für Subnetze verwendet werden.

Bereich Beschreibung
GDC-Infrastruktur Ein weltweit reservierter CIDR, der vom GDC-System verwendet wird. Wenn dieser Bereich für das Feld zone-infra-cidr des CIQ (Customer Intake Questionnaire) nicht angegeben ist, verwendet GDC standardmäßig 172.16.0.0/12 als GDC-Infrastrukturbereich.
Universumsspezifische Bereiche Zusätzliche Bereiche, die von der Infrastrukturbetreibergruppe reserviert werden.
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-Subnetzen

GDC verwendet zum Hosten des Subnetzes die ersten beiden und die letzten beiden IPv4-Adressen in jedem Subnetz.

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

Weitere Überlegungen

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 IPv4-Adressbereich des Subnetzes.

Nächste Schritte