Eigene IP-Adressen verwenden

Mit „Eigenen IP-Adresse verwenden“ (Bring your own IP addresses, BYOIP) können Sie Ihre eigenen öffentlichen IPv4-Adressen für Google Cloud-Ressourcen bereitstellen und verwenden. Nach dem Import der IP-Adressen werden diese von Google Cloud auf die gleiche Weise wie die von Google bereitgestellten IP-Adressen verwaltet. Es gibt jedoch folgende Ausnahmen:

  • Die IP-Adressen sind nur für den Kunden verfügbar, der sie gesendet hat.

  • Bei inaktiven oder verwendeten IP-Adressen fallen keine Kosten an.

Mit der Live-Migration können Sie festlegen, wann Google beginnt Routen für Ihr Präfix zu bewerben. Die Live-Migration ist standardmäßig nicht verfügbar. Wenden Sie sich an Ihren Google Cloud-Customer Engineer, um Zugriff zu erhalten.

Überblick

Erstellen Sie ein öffentlich beworbenes Präfix, um Ihre eigene IP-Adresse bei Google bereitzustellen. Die Bestätigung der Eigentümerschaft erfolgt für dieses öffentlich beworbene Präfix mithilfe von ROA und Reverse-DNS-Validierung. Nachdem die Verifizierung abgeschlossen ist, konfigurieren wir die Ankündigung dieses Präfixes für das Internet, aber das Präfix wird nicht bekannt gegeben, bis es bereitgestellt wird. Es dauert bis zu vier Wochen, bis das öffentlich beworbene Präfix bereitgestellt ist.

Während Sie darauf warten, dass das öffentlich beworbene Präfix bereitgestellt wird, teilen Sie das Präfix in öffentlich delegierte Präfixe (PDP) auf, die Sie für regionale oder globale Bereiche konfigurieren. Sie können das öffentlich delegierte Präfix entweder weiter unterteilen oder damit zuweisbare IP-Adressen erstellen. Es dauert bis zu vier Wochen, bis das öffentlich delegierte Präfix bereitgestellt ist.

Sobald die Bereitstellung des öffentlich delegierten Präfixes abgeschlossen ist, wird das öffentlich beworbene Präfix im Internet beworben. Wenn Sie die Live-Migration verwenden, finden Sie unter Live-Migration weitere Schritte.

Abbildung 1. Workflow zum Erstellen von öffentlich beworbenen Präfixen und öffentlichen delegierten Präfixen.

Öffentliche Beworbene Präfixe

Ein öffentlich beworbenes Präfix (public advertised prefix, PAP) ist eine Ressource in Compute Engine, die ein IP-Präfix darstellt, das Sie in Google Cloud übertragen. Dadurch können Sie Google Cloud-Ressourcen IP-Adressen aus Ihrem eigenen Präfix zuweisen. Das öffentlich beworbene Präfix ist eine einzelne Einheit des Route Advertisements. Das globale Backbone von Google bewirbt das öffentlich beworbene Präfix von allen Points of Presence aus. IP-Adressen im öffentlich beworbenen Präfix verwenden immer die Premium-Stufe der Netzwerkdienststufen.

Mit einem öffentlich beworbenen Präfix können entweder globale öffentliche delegierte Präfixe oder regionale öffentlich delegierte Präfixe erstellt werden, aber nicht beides.

Wenn Ihr öffentlich beworbenes Präfix vor dem 10. Juli 2023 erstellt wurde, finden Sie weitere Informationen unter Verhaltensänderungen für BYOIP.

Wenn Sie ein neues öffentlich beworbenes Präfix erstellen, muss es einen IPv4-IP-Bereich mit mindestens einem CIDR-Bereich von /24 haben. Ein kleinerer CIDR-Bereich wie /25 kann nicht als neues öffentlich beworbenes Präfix erstellt werden. Nach der Erstellung können Sie jedoch ein öffentlich beworbenes Präfix, z. B. ein /24 oder /23, in kleinere, öffentlich delegierte Präfixe unterteilen.

öffentlich delegierte Präfixe

Ein öffentlich delegiertes Präfix (PDP) ist ein IP-Block in Ihrem öffentlich beworbenen Präfix, der in einem einzelnen Bereich konfiguriert wird (eine bestimmte Region oder global). Bevor Sie Ihrem Projekt oder Ihrer Organisation IP-Adressen zuweisen können, müssen die IP-Blöcke delegiert und einem Bereich zugewiesen werden.

Das Erstellen globaler öffentlich delegierter Präfixe ist eingeschränkt. Weitere Informationen finden Sie unter Globale öffentlich delegierte Präfixe.

Sie können ein einzelnes öffentlich delegiertes Präfix in mehrere kleinere Blöcke aufteilen, aber diese Blöcke müssen denselben Bereich wie der übergeordnete Block haben. Sie können mehrere nicht fortlaufende öffentlich delegierte Präfixe in einem bestimmten Bereich konfigurieren. Diese kleineren Blöcke sind öffentlich delegierte Präfixe, die auch als Unterpräfixe bezeichnet werden.

Globale öffentliche delegierte Präfixe

Zum Erstellen eines globalen öffentlich delegierten Präfixes müssen Sie ein öffentlich beworbenes Präfix verwenden, das nur zum Erstellen globaler öffentlich delegierter Präfixe verwendet wird. Sie müssen das öffentlich delegierte Präfix in einem Projekt erstellen, dem Zugriff zum Erstellen globaler Präfixe gewährt wurde.

Wenn Sie den Zugriff anfordern möchten, reichen Sie eine Supportanfrage ein, um zu beantragen, dass Ihr Projekt für die Erstellung des globalen öffentlich delegierten Präfixes zugelassen wird.

IP-Adressen

Wenn Sie IP-Adressen aus einem öffentlichen delegierten Präfix erstellen, können die IP-Adressen nur innerhalb des Projekts und des Bereichs verwendet werden, dem sie zugewiesen sind. Alle IP-Adressen im öffentlichen delegierten Präfix oder Unterpräfix werden bereitgestellt. Es gibt keine reservierte Netzwerk- oder Sendeadresse. Wenn Sie beispielsweise ein öffentliches delegiertes Präfix oder Unterpräfix /28 verwenden, um IP-Adressen zu erstellen, werden 16 IP-Adressressourcen erstellt.

Jeder mit den entsprechenden IAM-Berechtigungen im Projekt kann die IP-Adressen verwenden.

  • compute.addresses.* für regionale IP-Adressen

  • compute.globalAddresses.* für globale IP-Adressen

Verhaltensänderungen für BYOIP

Die folgenden Verhaltensänderungen treten am 10. Juli 2023 in Kraft:

  • Mit einem öffentlich beworbenen Präfix können entweder globale öffentlich delegierte Präfixe oder regionale öffentlich delegierte Präfixe erstellt werden, aber nicht beides.
  • Öffentlich beworbene Präfixe, die vor dem 10. Juli 2023 erstellt wurden, können nur zum Erstellen regionaler öffentlich delegierter Präfixe verwendet werden.
  • Wenn Sie globale öffentlich delegierte Präfixe erstellen möchten, müssen Sie Zugriff anfordern.

Vorhandene globale öffentlich delegierte Präfixkonfigurationen sind nicht betroffen.

Ports auf BYOIP-Adressen öffnen

Die Ausführung eines Portscans für eine BYOIP-Adresse kann zu unerwarteten Ergebnissen führen. Globale BYOIP-Adressen werden von einem Infrastrukturdienst namens Google Front End (GFE) implementiert. Eine BYOIP-Adresse kann (auch wenn sie nicht verwendet wird) scheinbar offene Ports haben, da diese Ports von anderen Google-Diensten verwendet werden, die auch das GFE mitverwenden. Der Traffic zu diesen Ports wird verworfen und nicht protokolliert.

Globale IP-Adressen können nur von unterstützten Load-Balancern verwendet werden. Weitere Informationen zu offenen Ports auf Load-Balancern finden Sie hier:

Rolle "Öffentlicher IP-Administrator"

Sie können einen Administrator für Ihre BYOIP-Präfixe und -Adressen festlegen. Dazu weisen Sie ihm die Rolle Compute Public-IP-Administrator (roles/compute.publicIpAdmin) zu. Mit dieser Rolle können sie öffentlich routingfähige IP-Adressen in Ihrer Organisation verwalten.

Der Administrator für öffentliche IP-Adressen kann folgende Aufgaben ausführen:

  • Konfigurieren Sie öffentlich beworbene Präfixe in einem Projekt, das ihnen gehört.
  • Konfigurieren Sie die öffentlich beworbenen Präfixe in öffentlich delegierte Präfixe in einem eigenen Projekt.
  • Unterpräfixe von den öffentlich delegierten Präfixen an bestimmte Projekte in der Organisation delegieren.
  • Unterpräfixe, die zuvor von den öffentlich delegierten Präfixen an ein bestimmtes Projekt in der Organisation delegiert wurden widerrufen.
  • Löschen öffentlich delegierter Präfixe.

Planen der Bereitstellung

Es ist wichtig, Ihre Bereitstellung zu planen, da das Bereitstellen und Löschen von Prozessen mehrere Wochen dauern kann. Weitere Informationen zum Bereitstellungszeitplan und den zulässigen Präfixgrößen finden Sie unter Einschränkungen.

Bei der Planung Ihrer Bereitstellung sollten Sie folgende Entscheidungen beachten:

  • Wer ist für die Verwaltung von BYOIP-Adressen zuständig? Normalerweise ist dies ein Administrator oder eine Gruppe. Normalerweise sind sie jedoch nicht die gleichen Nutzer, die einzelne Projekte verwalten. Mit IAM-Rollen und -Berechtigungen können Sie unterscheiden, wer über Berechtigungen für die öffentlich beworbenen Präfixe und die delegierten Präfixe verfügt, die Sie bereitstellen möchten.

  • Wie werden Präfixe verwaltet? Wahrscheinlich möchten Sie Ihre BYOIP-Adressen in verschiedenen Projekten verwenden. Sie können Präfixe zentral in einem Projekt verwalten, das von den endgültigen Zielen der IP-Adressen getrennt ist. Wir empfehlen, die Präfix-Administration in einem eigenen Projekt zu isolieren, einschließlich eigener Nutzer und Gruppen mit Administratorberechtigungen öffentlicher IP-Adressen. Durch diese Isolation wird Verwirrung über die Präfixverwaltung und die unbeabsichtigte oder nicht autorisierte Verwendung von Präfixen verhindert. Weitere Informationen finden Sie unter Projektarchitektur.

  • Wie werden Präfixe benannt? Jede BYOIP-Ressource (öffentlich beworbenes Präfix, öffentlich delegiertes Präfix, Unterpräfix) erfordert einen Namen und der Name wird zum Verwalten der einzelnen Ressourcen verwendet. Sie weisen den Namen während der Ressourcenerstellung zu und Namen können nicht geändert werden, ohne die Ressource zu löschen und neu zu erstellen. Aus diesem Grund empfehlen wir Ihnen, Namen zu erstellen, die leicht zu verwalten sind. Zum Beispiel pap-203-0-113-0-24, pdp-203-0-113-0-25, sub-203-0-113-0-28, wobei die Buchstaben den Ressourcentyp bezeichnen und die Zahlen das spezifische Präfix und die Präfixlänge angeben.

  • Wo werden die IP-Adressen bereitgestellt? Es ist sinnvoll, sich den Bereitstellungsprozess als „Lagerung“ von IPs in Regionen (oder den globalen Bereich) vorzustellen. Der Bereitstellungsprozess für IP-Adressen dauert mehrere Wochen. Deshalb ist es sinnvoll, öffentlich delegierte Präfixe zu planen und bereitzustellen, bevor sie benötigt werden.

    Sie müssen nicht alle IP-Adressen sofort in einem öffentlich delegierten Präfix verwenden. Wenn Sie sich nicht sicher sind, wo Sie sie benötigen, richten Sie nur die öffentlich delegierten Präfixe ein, die Sie wirklich benötigen. Das Verschieben eines öffentlichen delegierten Präfixes erfordert das vollständige Löschen und kann dann bis zu acht Wochen dauern.

    Sobald die Bereitstellung des öffentlich delegierten Präfixes abgeschlossen ist, können Sie Unterpräfixe an Projekte delegieren und Adressen für die Verwendung mit Ressourcen erstellen. Wenn Sie BYOIP-Adressen in einer Region benötigen werden, schließen Sie die Bereitstellung für das öffentliche, delegierte Präfix im Voraus ab, damit Sie später den Bedarf on demand adressieren können.

    Wenn Sie beispielsweise einige IP-Adressen in us-central1 und einige IP-Adressen für globale Load-Balancer benötigen und einige IP-Adressen für die Zukunft reservieren möchten, sollten Sie den folgenden Plan erstellen.

    Präfix-Typ Präfix Umfang
    Öffentlich beworbenes Präfix 203.0.113.0/24
    Öffentlich beworbenes Präfix für globale Load-Balancer 192.0.2.0/24
    Öffentlich delegiertes Präfix 203.0.113.0/28 us-central1
    Öffentlich delegiertes Präfix 203.0.113.16/28 us-east-4
    Öffentlich delegiertes Präfix 192.0.2.0/28 global

    Die verbleibenden IP-Adressen sind für die zukünftige Verwendung reserviert.

Live-Migration

Die Live-Migration ist ein leistungsstarkes Feature, das eine detaillierte Planung und Ausführung erfordert.

Verwenden Sie die Live-Migration, um ein BYOIP-Präfix zu importieren, wenn ein Teil des Präfix bereits öffentlich beworben wird. Das Importieren eines beworbenen Präfixes ohne Verwendung der Live-Migration kann zu unerwartetem Routing und Paketverlust führen.

Die Live-Migration ist nur eingeschränkt verfügbar. Wenden Sie sich an Ihren Google Cloud Customer Engineer, um Zugriff zu erhalten, bevor Sie ein öffentlich delegiertes Präfix mit aktivierter Live-Migration erstellen.

Sie aktivieren die Live-Migration, wenn Sie ein öffentlich delegiertes Präfix erstellen. Indem Sie Folgendes sicherstellen verhindern Sie, dass Google das öffentlich beworbene Präfix gegenüber Kollegen bewirbt:

  • Alle öffentlich delegierten Präfixe innerhalb des öffentlich beworbenen Präfixes werden auf regionaler Ebene und nicht auf globaler Ebene konfiguriert. Weitere Informationen finden Sie in den Empfehlungen zur Live-Migration.

  • Keine IP-Adressen im Bereich des öffentlich beworbenen Präfixes sind Ressourcen zugewiesen.

Abbildung 2 zeigt dasselbe Projekt mit verschiedenen Konfigurationen, von denen eine verhindert, dass das Präfix beworben wird, und zwei, die bewirken, dass das öffentlich beworbene Präfix beworben wird.

Abbildung 2. Öffentlich beworbene Präfix-Bewerbung während der Live-Migration (zum Vergrößern anklicken).

Abbildung 2 veranschaulicht die folgenden Szenarien:

  • Im ersten Projektbeispiel werden alle öffentlich delegierten Präfixe im öffentlich beworbenen Präfix mit aktivierter Live-Migration konfiguriert. Es werden keine VMs mit IP-Adressen aus diesem Präfix konfiguriert.

    Ergebnis: Das öffentlich beworbene Präfix wird nicht beworben.

  • Im zweiten Projektbeispiel werden alle öffentlich delegierten Präfixe im öffentlich beworbenen Präfix mit aktivierter Live-Migration konfiguriert. Eine VM wird mit einer IP-Adresse aus diesem Präfix konfiguriert.

    Ergebnis: Das öffentlich beworbene Präfix wird beworben.

  • Im dritten Projektbeispiel wird ein öffentliches delegiertes Präfix innerhalb des öffentlich beworbenen Präfixes nicht mit aktivierter Live-Migration konfiguriert. Es werden keine VMs mit IP-Adressen aus diesem Präfix konfiguriert.

    Ergebnis: Das öffentlich beworbene Präfix wird beworben.

Sie steuern, wann die Bewerbung beginnt. Weisen Sie dazu IP-Adressen aus Ihrem öffentlichen delegierten Präfix den Google Cloud-Ressourcen zu. Weitere Informationen finden Sie unter Live-Migration.

Wenden Sie sich nach Abschluss der Live-Migration an Ihren Google Cloud Customer Engineer, damit er die Live-Migration für Ihr Präfix deaktivieren kann. Standardmäßig wird die Live-Migration 30 Tage nach Beginn der Bewerbung für das öffentlich beworbene Präfix deaktiviert. Wenn Sie die Live-Migrationsoption länger als 30 Tage benötigen, wenden Sie sich an Ihren Customer Engineer.

Einschränkungen der Live-Migration

Bei der Planung einer Live-Migration ist es wichtig, dass Sie die folgenden Anforderungen und Einschränkungen verstehen:

  • Das Erstellen eines öffentlichen delegierten Präfixes mit aktivierter Live-Migration wird nicht unterstützt, wenn der Bereich auf „Global“ festgelegt ist. Informationen zur Verwaltung der Live-Migration für globale Ressourcen finden Sie in den Empfehlungen zur Live-Migration.

  • Das längste Präfix, das migriert werden kann, ist ein /24, da /24 die maximal weiterleitbare Präfixlänge im Internet ist.

  • Es wird nicht davon ausgegangen, dass alle Kollegen von Google das längste Präfix zwischen zwei Websites respektieren. Einige Kollegen haben möglicherweise keine vollständigen Routingtabellen. Daher ist ein kürzeres Präfix beworben von Google gegenüber diesen Kollegen das einzige (und damit auch das längste Präfix) Präfix, das der Kollege sieht. Deshalb hat das Existenz jedes Präfixes von Google Vorrang, auch wenn Sie eine spezifischere Route von Ihrem lokalen Standort aus bewerben.

    Beispiel:

    Ein Kunde hat eine /23, die aktiv von seinem lokalen Standort aus weitergeleitet wird. Der Kunde plant, die /23 in zwei /24-Präfixe aufzuteilen und die spezifischeren Routen von ihrem lokalen Standort aus anzukündigen. Nach der Aufteilung möchten sie das öffentlich beworbene Präfix /23 für BYOIP konfigurieren. Sie gehen davon aus, dass die spezifischeren Routen von ihrem lokalen Standort Vorrang vor dem kürzeren BYOIP-Präfix haben und der Traffic weiterhin an die spezifischeren lokalen Präfixe weitergeleitet wird.

    Dieser Plan funktioniert leider nur teilweise:

    • Google-Kollegen, die vollständige Routingtabellen haben, bevorzugen die spezifischeren lokalen /24-Präfixe.

    • Google-Kollegen, die keine vollständigen Routingtabellen haben, bevorzugen das von Google angekündigte öffentlich beworbene Präfix, da die spezifischeren Präfixe in deren Routing-Tabellen nicht enthalten sind.

  • Ihr Traffic wird nicht zugestellt, wenn Google Traffic für ein gültiges öffentlich beworbenes Präfix erhält, für das Sie keine Dienste bereitgestellt haben, auch wenn es ein aktives lokales Bewerbung für das Präfix gibt.

    Beispiel:

    Ein Kunde hat ein lokales Netzwerk, das zwei /24-Präfixe umfasst. Das öffentlich beworbene Präfix ist das aggregierte /23.

    Der Kunde migriert einen einzelnen /24 zu Google und entfernt das lokale Präfix, lässt aber die andere /24 aktiv am lokalen Standort.

    Diese Konfiguration führt zu einem Teil der Trafficweiterleitung an Google für das gesamte /23-Präfix, obwohl dennoch ein spezifischeres /24-Präfix vom lokalen Standort angekündigt wird. Dieses Szenario lässt sich nur schwer diagnostizieren, da verschiedene Autonome Systeme Traffic an Ihren lokalen Standort liefern, andere aber an Google liefern, in welchem Fall der Traffic verworfen wird.

Empfehlungen für die Live-Migration

Befolgen Sie bei der Live-Migration am besten die folgenden Empfehlungen.

  • Trennen Sie alle Live-Migrationspräfixe in die längsten Präfixe auf, die angeben, wie diese Präfixe während der Migration beworben werden sollen. In den vorherigen Beispielen sollte /23 in zwei /24-Präfixe zerlegt und als solche an deren lokalen Standort angekündigt werden, bevor Sie das öffentliche beworbene Präfix erstellen.

  • Sie erstellen ROA-Anfragen mit exakter Präfixlänge und verlassen sich nicht darauf, dass der maximale Länge Parameter berücksichtigt wird.

  • Prüfen Sie, ob für die lokale Ursprungs-ASN und die Ursprungs-ASN von Google RPKI-ROA-Anfragen vorhanden sind. Wenn kein ROA für das lokale Präfix vorhanden ist, kann die Erstellung eines Google-Ursprungs-ROAs dazu führen, dass Drittanbieter-ISPs diese lokalen Präfixe herausfiltern, wenn sie die automatische RPKI-Filterung verwenden.

  • Erstellen Sie separate öffentlich beworbene Präfixe für globale Ressourcen und regionale Ressourcen, wenn Sie eine Live-Migration verwenden müssen. Wenn Sie die Live-Migration für ein öffentlich delegiertes Präfix aktivieren, müssen Sie eine Region für den Bereich angeben. Die Angabe des globalen Bereichs für ein öffentlich delegiertes Präfix, für das Live-Migration aktiviert ist, wird nicht unterstützt. Wenn Sie ein öffentlich delegiertes Präfix mit globalem Geltungsbereich und aktivierter Live-Migration erstellen, wird das Präfix sofort beworben.

    Wenn Sie regionale Präfixe in einem öffentlich beworbenen Präfix und globale Präfixe in einem anderen öffentlich beworbenen Präfix haben, können Sie sie separat verwalten. Sie können die Live-Migration der regionalen Ressourcen verwalten, und wenden Sie sich an Ihren Google Cloud Customer Engineer, um die Live-Migration der globalen Ressourcen zu verwalten.

Projektarchitektur

Wir empfehlen die Verwendung von Organisationen, um von Features wie IAM-Berechtigungen auf Organisationsebene und Freigegebene VPC zu profitieren. Weitere Informationen zum Verwenden einer Organisation finden Sie unter Organisationen erstellen und verwalten.

BYOIP (Bring Your Own IP)-Adressverwaltung in einer Organisation

In diesem Beispiel eines Projekts, das zu einer Organisation gehört, wird das dedizierte Projekt Public IP project verwendet, um die BYOIP-Adressen zu verwalten. Der Administrator öffentlicher IP-Adressen der Organisation hat das öffentlich beworbene Präfix und die öffentlich delegierten Präfixe im Public IP project erstellt.

Wenn VPC project öffentliche IP-Adressen benötigt, erstellt der Administrator öffentlicher IP-Adressen für die Organisation die IP-Adressen im VPC project.

Die Organisation kann mehrere Projekte enthalten und der öffentliche IP-Administrator kann IP-Adressen an all diese aus dem Public IP project delegieren.

Abbildung 5. Sie können Organisationen und Projekte verwenden, um BYOIP-Adressen zu verwalten.

Verwaltung von BYOIP (Bring Your Own IP)-Adressen mit freigegebener VPC

In diesem Beispiel einer Organisation, die eine freigegebene VPC enthält, gibt es das dedizierte Projekt Public IP project, das zur Verwaltung von BYOIP-Adressen verwendet wird. Der Administrator öffentlicher IP-Adressen der Organisation hat das öffentlich beworbene Präfix und die öffentlich delegierten Präfixe im Public IP project erstellt.

Wenn das Shared VPC host project oder die zugehörigen Dienstprojekte öffentliche IP-Adressen benötigen, erstellt der Administrator öffentlicher IP-Adressen für die Organisation die IP-Adressen im Shared VPC host project. Das Hostprojekt und die Dienstprojekte können auf die BYOIP-Adressen aus dem Hostprojekt zugreifen.

Das Erstellen von IP-Adressen in einem freigegebenen VPC-Dienstprojekt wird nicht unterstützt.

Abbildung 4. Sie können BYOIP-Adressen an ein freigegebenes VPC-Hostprojekt, aber nicht an ein freigegebenes VPC-Dienstprojekt delegieren. Ein Dienstprojekt kann jedoch BYOIP-Adressen verwenden, die an das Hostprojekt delegiert wurden.

BYOIP (Bring Your Own IP)-Adressverwaltung ohne Organisation

Wenn Sie ein Projekt verwenden, das nicht zu einer Organisation gehört, können Sie für die BYOIP-Adressverwaltung kein separates Projekt erstellen. Erstellen Sie das öffentlich beworbene Präfix und die öffentlich delegierten Präfixe im selben Projekt, das die BYOIP-Adressen erfordert.

Kontingente und Limits

Es gibt Kontingente und Limits für öffentlich delegierte Präfixe (PDPs) und öffentlich beworbene Präfixe (PAPs). Weitere Informationen finden Sie unter Kontingente und Limits für VPC.

Nächste Schritte