Mit INTERLIR Marketplace haben Sie die Flexibilität, die gemieteten IPs als „Bring Your Own IP“ (BYOIP) mit Google Cloud zu verwenden. BYOIP ermöglicht es Ihnen, Ihre eigenen öffentlichen IPv4-Adressen für Ihre Google Cloud-Ressourcen bereitzustellen und zu nutzen. Diese Funktion ermöglicht eine nahtlose Integration Ihrer vorhandenen IP-Adressen mit der Google Cloud-Plattform und bietet Ihnen mehr Kontrolle und Bequemlichkeit bei der Verwaltung Ihrer Netzwerkinfrastruktur.
Sobald die IP-Adressen über BYOIP in Google Cloud importiert wurden, verwaltet Google sie ähnlich wie seine eigenen bereitgestellten IP-Adressen, mit einigen Ausnahmen:
Google Cloud erlaubt keine überlappenden BYOIP-Routenankündigungen. Das bedeutet, dass wenn ein IP-Adressbereich, wie z. B. 203.0.112.0/23, oder ein Teil davon, wie z. B. 203.0.112.0/24, bereits außerhalb von Google angekündigt wird, das Importieren des gleichen Bereichs oder eines Teils davon in Google Cloud nicht unterstützt wird. Überlappende Routenankündigungen mit passenden oder nicht passenden Präfixlängen zwischen Google und einem anderen Netzwerk können zu unerwarteten Routing-Problemen und Paketverlust führen.
Für das Verwalten der Routenankündigung Ihres importierten Präfixes bietet Google Cloud eine Funktion namens „Live Migration“ an. Live Migration ermöglicht es Ihnen, den Zeitpunkt zu kontrollieren, zu dem Google Cloud beginnt, Routen für Ihren importierten IP-Adressbereich anzukündigen. Es ist jedoch wichtig zu beachten, dass die Live Migration nicht standardmäßig verfügbar ist und von Google Cloud angefordert werden muss. Um Zugriff auf die Live Migration-Funktion zu beantragen, können Sie sich an Ihren Google Cloud-Vertreter wenden.
Überblick
Um Ihre eigene IP-Adresse in Google Cloud zu bringen, erstellen Sie zunächst einen öffentlich beworbenen Präfix (PAP). Die Eigentumsbestätigung für diesen PAP erfolgt durch die Verwendung von Route Origin Authorization (ROA) und reverse DNS-Validierung. Nach erfolgreicher Überprüfung wird die Ankündigung dieses PAPs im Internet konfiguriert, aber der Präfix wird erst dann beworben, wenn er bereitgestellt wird. Der Bereitstellungsprozess für den öffentlich beworbenen Präfix dauert in der Regel bis zu vier Wochen.
Während der Wartezeit auf die Bereitstellung teilen Sie den Präfix in öffentlich delegierte Präfixe (PDP) auf. Diese PDPs können entweder regionalen oder globalen Geltungsbereich haben, und Sie haben die Möglichkeit, sie weiter aufzuteilen oder sie zuweisbaren IP-Adressen zu verwenden. Die Bereitstellung des öffentlich delegierten Präfixes dauert ebenfalls bis zu vier Wochen.
Sobald die Bereitstellung des öffentlich delegierten Präfixes abgeschlossen ist, wird der öffentlich beworbene Präfix im Internet angekündigt. Wenn Sie Live Migration verwenden, können zusätzliche Schritte erforderlich sein. Es wird daher empfohlen, sich an die spezifischen Richtlinien für die Verwendung von Live Migration zu halten, die von Google Cloud bereitgestellt werden.
Ein öffentlich beworbener Präfix (PAP) ist eine Ressource innerhalb von Googles Compute Engine, die es Ihnen ermöglicht, Ihren eigenen IP-Präfix auf die Plattform zu bringen. Dadurch können Sie IP-Adressen aus Ihrem eigenen Präfix für Google Cloud-Ressourcen zuweisen. Das PAP repräsentiert eine einzelne Einheit der Routenankündigung, und Googles globales Backbone kündigt es von allen seinen Präsenzpunkten aus an. IP-Adressen innerhalb des öffentlich beworbenen Präfixes nutzen immer die Premium Tier of Network Service Tiers.
Bei der Erstellung eines neuen öffentlich beworbenen Präfixes muss es einen IPv4-IP-Bereich mit einem Mindest-CIDR-Bereich von /24 haben. Es ist nicht möglich, ein neues öffentlich beworbenes Präfix mit einem kleineren CIDR-Bereich wie /25 zu erstellen. Sobald jedoch ein öffentlich beworbener Präfix erstellt ist, haben Sie die Flexibilität, ihn in kleinere öffentlich delegierte Präfixe aufzuteilen, wie z. B. /24 oder /23.
Ein öffentlich delegiertes Präfix (PDP) ist ein bestimmter IP-Block innerhalb Ihres öffentlich beworbenen Präfixes, der so konfiguriert ist, dass er innerhalb eines definierten Geltungsbereichs in Google Cloud funktioniert, der entweder eine bestimmte Region oder global sein kann. Bevor Sie IP-Adressen Ihrem Projekt oder Ihrer Organisation zuweisen können, müssen diese IP-Blöcke einem bestimmten Geltungsbereich zugewiesen werden.
Google Cloud bietet die Flexibilität, ein öffentlich beworbenes Präfix in mehrere öffentlich delegierte Präfixe aufzuteilen. Jedes dieser öffentlich delegierten Präfixe kann in Ihren Google Cloud-Projekten mit seinem eigenen Geltungsbereich konfiguriert werden. Zusätzlich haben Sie die Möglichkeit, ein einzelnes öffentlich delegiertes Präfix in mehrere kleinere Blöcke aufzuteilen, jedoch ist es wichtig zu beachten, dass diese kleineren Blöcke denselben Geltungsbereich wie der übergeordnete Block haben müssen. Innerhalb eines bestimmten Geltungsbereichs können Sie auch mehrere nicht zusammenhängende öffentlich delegierte Präfixe konfigurieren, die auch als Teilpräfixe bezeichnet werden.
Sobald IP-Adressen aus einem öffentlich delegierten Präfix erstellt wurden, sind sie für die Verwendung innerhalb des spezifischen Projekts und Geltungsbereichs eingeschränkt, für den sie zugewiesen wurden. Jeder Benutzer mit den entsprechenden IAM-Berechtigungen im Projekt kann diese IP-Adressen für ihre vorgesehenen Zwecke nutzen:
compute.addresses.*` für regionale IP-Adressencompute.globalAddresses.*` für globale IP-AdressenUm einen Administrator für Ihre BYOIP-Präfixe und -Adressen zu ernennen, können Sie ihnen die Rolle „Compute Public IP-Administrator“ (Rolle „roles/compute.publicIpAdmin“) zuweisen. Mit dieser Rolle erhalten sie die Fähigkeit, öffentlich routbare IPs in Ihrer Organisation zu verwalten.
Die Aufgaben des „Public IP-Administrators“ umfassen:
1. Konfiguration von öffentlich beworbenen Präfixen in ihrem eigenen Projekt.
2. Einrichtung von öffentlich delegierten Präfixen mithilfe der konfigurierten öffentlich beworbenen Präfixe in ihrem eigenen Projekt.
3. Delegierung von Teilpräfixen aus den öffentlich delegierten Präfixen an bestimmte Projekte innerhalb der Organisation.
4. Rücknahme zuvor delegierter Teilpräfixe aus den öffentlich delegierten Präfixen für bestimmte Projekte innerhalb der Organisation.
5. Löschen von öffentlich delegierten Präfixen.
Eine effektive Planung ist entscheidend, wenn Sie BYOIP-Adressen bereitstellen, da die Bereitstellungs- und Löschungsprozesse mehrere Wochen dauern können. Um den Planungsprozess zu unterstützen, sollten Sie die folgenden Entscheidungen berücksichtigen:
1. Zuständigkeiten der Verwaltung: Bestimmen Sie, wer für die Verwaltung der BYOIP-Adressen verantwortlich sein wird. Normalerweise ist dies ein Administrator oder eine spezifische Gruppe, die von denjenigen getrennt ist, die einzelne Projekte verwalten. Verwenden Sie IAM-Rollen und Berechtigungen, um die Privilegien für öffentlich beworbene und delegierte Präfixe zu unterscheiden.
2. Präfixverwaltung: Überlegen Sie, wie Präfixe in verschiedenen Projekten verwaltet werden sollen. Es wird empfohlen, Präfixe zentral in einem dedizierten Projekt zu verwalten, das von den Projekten getrennt ist, in denen die IP-Adressen verwendet werden. Diese Isolierung hilft Verwirrung und unbefugte Verwendung von Präfixen zu vermeiden.
3. Namenskonvention: Jede BYOIP-Ressource (öffentlich beworbener Präfix, öffentlich delegierter Präfix, Teilpräfix) benötigt einen Namen für Verwaltungszwecke. Wählen Sie bei der Erstellung der Ressourcen aussagekräftige und leicht verwaltbare Namen aus, da sie nicht ohne erneute Erstellung der Ressource geändert werden können.
4. Bereitstellungsorte: Denken Sie bei der Bereitstellung von IPs an die Prozess als „Auffüllen“ von IPs in Regionen oder den globalen Geltungsbereich. Planen und bereitstellen Sie öffentlich delegierte Präfixe weit im Voraus, da die Bereitstellung mehrere Wochen dauert. Wenn Sie unsicher sind, wo IPs verwendet werden sollen, stellen Sie nur die benötigten Präfixe sofort bereit. Das Verschieben eines öffentlich delegierten Präfixes erfordert die Löschung und Neuerstellung, was bis zu acht Wochen dauern kann. Sobald die Bereitstellung abgeschlossen ist, delegieren Sie Teilpräfixe an Projekte und erstellen Sie Adressen für die Verwendung mit Ressourcen.
Als Beispiel nehmen wir an, Sie haben ein /24 öffentlich beworbenes Präfix und benötigen IPs in us-central1 und für globale Load Balancer, wobei einige für zukünftige Verwendung reserviert sind. Sie könnten den folgenden Plan erstellen:
Öffentlich beworbenes Präfix: 203.0.113.0/24
Öffentlich delegiertes Präfix: 203.0.113.0/28 (für us-central1)
Öffentlich delegiertes Präfix: 203.0.113.16/28 (für global)
Übrige IP-Adressen für zukünftige Verwendung reserviert.
Durch eine vorausschauende Planung und effektive Verwaltung der Präfixe können Sie eine reibungslose Bereitstellung von BYOIP-Adressen in Ihren Google Cloud-Projekten gewährleisten.
Die Live-Migration ist eine leistungsstarke Funktion, die es Ihnen ermöglicht, ein BYOIP-Präfix zu importieren, wenn irgendein Teil des Präfixes bereits öffentlich beworben wird. Sie erfordert eine sorgfältige Planung und Ausführung, um unerwartete Routingprobleme und Paketverlust zu vermeiden.
Um die Live-Migration zu nutzen, stellen Sie sicher, dass das zu importierende Präfix noch nicht beworben wird. Die Live-Migration ist nicht weit verbreitet, daher wenden Sie sich vor der Erstellung eines öffentlich delegierten Präfixes mit aktivierter Live-Migration an Ihren Google Cloud-Vertreter, um den Zugriff anzufordern.
Um die Live-Migration zu aktivieren, müssen Sie ein öffentlich delegiertes Präfix erstellen und sicherstellen, dass alle öffentlich delegierten Präfixe innerhalb des öffentlich beworbenen Präfixes einen regionalen Geltungsbereich und keinen globalen Geltungsbereich haben. Stellen Sie außerdem sicher, dass keine IP-Adressen im Bereich des öffentlich beworbenen Präfixes an Ressourcen zugewiesen sind. Durch Befolgung dieser Empfehlungen und Konfigurationen verhindern Sie, dass Google das öffentlich beworbene Präfix während des Migrationsprozesses an Peers bewirbt.
Abbildung 2 veranschaulicht die verschiedenen Konfigurationen in einem Projekt, wobei eine Konfiguration das Bewerben des Präfixes verhindert und zwei andere das öffentlich beworbene Präfix bewerben. Durch sorgfältige Verwaltung des Geltungsbereichs und der IP-Adresszuweisungen wird eine erfolgreiche Live-Migration Ihres BYOIP-Präfixes sichergestellt.
Abbildung 2 zeigt drei Szenarien, um die Ergebnisse der Verwendung der Live-Migration für öffentlich delegierte Präfixe innerhalb eines öffentlich beworbenen Präfixes zu veranschaulichen:
Sie haben die Kontrolle darüber, wann die Bewerbung des öffentlich beworbenen Präfixes beginnt, indem Sie IP-Adressen aus Ihrem öffentlich delegierten Präfix Google Cloud-Ressourcen zuweisen. Detaillierte Informationen zur Verwendung der Live-Migration finden Sie in der entsprechenden Dokumentation.
Nach Abschluss des Live-Migrationsprozesses empfiehlt es sich, sich an Ihren Google Cloud-Vertreter zu wenden, um die Live-Migration für Ihr Präfix zu deaktivieren. Standardmäßig ist die Live-Migration 30 Tage nach Beginn der Bewerbung des öffentlich beworbenen Präfixes deaktiviert. Wenn Sie die Option der Live-Migration für eine längere Zeit benötigen, kommunizieren Sie dies Ihrem Google Cloud-Vertreter.
Bei der Überlegung einer Live-Migration ist es entscheidend, spezifische Anforderungen und Einschränkungen zu beachten:
Zum Beispiel nehmen wir an, Sie haben ein aktiv geroutetes /23-Präfix von Ihrem Standort vor Ort. Sie planen, das /23 in zwei /24-Präfixe aufzuteilen und die spezifischeren Routen von Ihrem Standort vor Ort anzukündigen. Gleichzeitig konfigurieren Sie ein /23 öffentlich beworbenes Präfix für BYOIP. Während Sie möglicherweise davon ausgehen, dass die spezifischeren Routen vor Ort Vorrang vor dem kürzeren BYOIP-Präfix haben, ist dies möglicherweise nicht immer der Fall:
Es ist wichtig zu verstehen, dass wenn Google Traffic für ein gültiges öffentlich beworbenes Präfix erhält, für das Sie keine Dienste bereitgestellt haben, selbst wenn ein aktives Präfix vor Ort für das Präfix angekündigt wird, der Traffic nicht an Sie geliefert wird. Wenn Sie beispielsweise ein Vor-Ort-Netzwerk mit zwei /24-Präfixen haben und ein öffentlich beworbenes Präfix das Aggregat /23 ist, kann die Migration eines einzelnen /24 zu Google und das Zurückziehen des Vor-Ort-Präfixes bei gleichzeitiger Beibehaltung des anderen /24 vor Ort dazu führen, dass der Verkehr für das gesamte /23-Präfix zu Google geleitet wird. Dies kann zu Verwirrung führen, da der Verkehr je nach Routingpfaden verschiedener autonomer Systeme an unterschiedliche Ziele geliefert wird. Daher ist es wichtig, Ihre Live-Migration sorgfältig zu planen und zu konfigurieren, um unerwartete Routingprobleme zu vermeiden und eine ordnungsgemäße Verkehrsabwicklung sicherzustellen.
Hier sind die empfohlenen bewährten Verfahren für die Verwendung der Live-Migration:
Wir empfehlen die Verwendung von Organisationen, um von Funktionen wie zentralisierten IAM-Berechtigungen und Shared VPC zu profitieren, die eine verbesserte Ressourcenverwaltung und Sicherheit in Ihrer Google Cloud-Umgebung bieten.
In diesem Szenario wird innerhalb einer Organisation ein separates Projekt mit dem Namen „Public IP Project“ festgelegt, das die Verwaltung von BYOIP-Adressen übernimmt. Der „Public IP-Administrator“, der die IP-Adressverwaltung für die Organisation überwacht, erstellt das öffentlich beworbene Präfix und öffentlich delegierte Präfixe innerhalb dieses Projekts.
Wenn ein VPC-Projekt öffentliche IP-Adressen benötigt, erstellt der „Public IP-Administrator“ die erforderlichen IP-Adressen innerhalb des VPC-Projekts.
Die Organisation hat die Flexibilität, mehrere Projekte zu haben, und der „Public IP-Administrator“ kann IP-Adressen an alle von ihnen aus dem zentralen „Public IP Project“ delegieren. Dieser zentralisierte Ansatz vereinfacht die Verwaltung von IP-Adressen in den Projekten der Organisation.
In dieser Organisation mit Shared VPC wird ein separates Projekt mit dem Namen „Public IP Project“ festgelegt, das die Verwaltung von BYOIP-Adressen übernimmt. Der „Public IP-Administrator“, der für die IP-Adressverwaltung in der gesamten Organisation verantwortlich ist, hat das öffentlich beworbene Präfix und die öffentlich delegierten Präfixe innerhalb dieses zentralen Projekts erstellt.
Wenn das Shared VPC-Hostprojekt oder verwandte Serviceprojekte öffentliche IP-Adressen benötigen, erstellt der „Public IP-Administrator“ die erforderlichen IP-Adressen innerhalb des Shared VPC-Hostprojekts. Sowohl das Hostprojekt als auch die Serviceprojekte können auf die BYOIP-Adressen aus dem Hostprojekt zugreifen.
Es ist wichtig zu beachten, dass das direkte Erstellen von IP-Adressen in einem Shared VPC-Serviceprojekt nicht unterstützt wird. Die gesamte IP-Adressverwaltung erfolgt im zentralen „Public IP Project“ und wird über die relevanten Projekte innerhalb der Organisation geteilt.
Wenn Ihr Projekt nicht Teil einer Organisation ist, können Sie kein separates Projekt ausschließlich für die Verwaltung von BYOIP-Adressen erstellen. In solchen Fällen müssen Sie das öffentlich beworbene Präfix und die öffentlich delegierten Präfixe direkt innerhalb desselben Projekts erstellen, das die Verwendung von BYOIP-Adressen erfordert.
Evgeny Sevastyanov
Client Support Teamleader
Die Erschöpfung der IPv4-Adressen ist ein dringendes Problem, und Unternehmen erkennen
Die effiziente Nutzung des bestehenden IPv4-Adressraums ist ein möglicher Ansatz,
InterLIR GmbH ist eine Marktplatzlösung, die sich zum Ziel gesetzt hat, Netzwerkverfügbarkeitsprobleme
Auch wenn Sie nicht vorhaben, Ihr IPv4-Netzwerk zu verkaufen, gibt es immer noch
Eine Internet Protocol (IP)-Adresse ist eine eindeutige Kennung, die jedem mit dem
Die steigende Nachfrage nach IP-Blöcken hat die Preise in die Höhe getrieben und
Netzwerk-IP-Adressen variieren und erfordern eine fachkundige Beratung für Netzwerkbetreiber.
Einführung Im heutigen digitalen Umfeld ist der Schutz der Netzwerksicherheit von
In einer Ära, die von digitaler Konnektivität vorangetrieben wird, hat der Wert
