Übersicht über die Spoke-Verwaltung

Diese Seite bietet eine Übersicht aus der Perspektive eines VPC-Spoke-Administrators (Virtual Private Cloud).

Wenn sich der Network Connectivity Center-Hub und der VPC-Spoke im selben Projekt befinden, müssen VPC-Spoke-Administratoren beide die folgenden IAM-Bindungen (Identity and Access Management) für dieses Projekt haben:

Wenn sich der Network Connectivity Center-Hub und der VPC-Spoke in verschiedenen Projekten befinden, müssen IAM-Richtlinien die folgenden Bindungen haben:

Sie können auch benutzerdefinierte Rollen verwenden, sofern die benutzerdefinierte Rolle die gleichen Berechtigungen wie die oben aufgeführten vordefinierten Rollen enthält.

Wenn sich ein VPC-Netzwerk und der Network Connectivity Center-Hub in verschiedenen Projekten befinden, muss ein VPC-Spoke-Administrator ein Spoke-Angebot erstellen, um anzufordern, dass ein VPC-Netzwerk dem Hub beitritt. Ein Hub-Administrator überprüft das Angebot. Wenn der Hub-Administrator das Angebot akzeptiert, ist das VPC-Netzwerk mit dem Hub verbunden. Ein Hub-Administrator kann Spoke-Angebote auch ablehnen. Spoke-Administratoren können den Status eines VPC-Spoke-Angebots jederzeit prüfen.

Weitere Informationen finden Sie in den folgenden Abschnitten.

Eindeutigkeit der Subnetzroute

Ähnlich wie VPC-Netzwerk-Peering sind bei Google Cloud Konflikte mit Subnetz-IP-Adressbereichen zwischen VPC-Spokes möglich, die mit einem Network Connectivity Center-Hub verbunden sind. Ein Subnetz-IP-Adressbereich Konflikte mit einem anderen Subnetz-IP-Adressbereich, wenn einer der folgenden Punkte zutrifft:

  • Der Subnetz-IP-Adressbereich in einem VPC-Netzwerk stimmt genau mit einem Subnetz-IP-Adressbereich in einem anderen VPC-Netzwerk überein.
  • Der IP-Adressbereich eines Subnetzes in einem VPC-Netzwerk passt in einen Subnetz-IP-Adressbereich in einem anderen VPC-Netzwerk.
  • Ein Subnetz-IP-Adressbereich in einem VPC-Netzwerk enthält einen Subnetz-IP-Adressbereich in einem anderen VPC-Netzwerk.

VPC-Spokes können keine in Konflikt stehenden IP-Adressbereiche in denselben Network Connectivity Center-Hub exportieren. Sie können das Flag exclude-export-ranges in der Google Cloud CLI oder dem Feld excludeExportRanges in der API verwenden, um die Freigabe eines Subnetz-IP-Adressbereichs zu verhindern. von einem VPC-Spoke in einen Network Connectivity Center-Hub. Angenommen, Sie haben zwei VPC-Netzwerke, die Sie mit demselben Network Connectivity Center-Hub verbinden möchten:

  • Das erste VPC-Netzwerk hat ein Subnetz, dessen primärer interner IPv4-Adressbereich 100.64.0.0/16 ist, was zu einer Subnetzroute für 100.64.0.0/16 führt.
  • Das zweite VPC-Netzwerk hat ein Subnetz mit einem sekundären internen IPv4-Adressbereich von 100.64.0.0/24. Dies führt zu einer Subnetzroute für 100.64.0.0/24.

Die beiden Subnetzrouten haben in Konflikt stehende Subnetz-IP-Adressbereiche, da 100.64.0.0/24 in 100.64.0.0/16 passt. Sie können nicht beide Netzwerke als VPC-Spokes mit demselben Network Connectivity Center-Hub verbinden, es sei denn, Sie lösen den Konflikt. Sie können den Konflikt mit einer der folgenden Strategien lösen:

  • Schließen Sie entweder den IP-Adressbereich 100.64.0.0/16 aus, wenn Sie das erste VPC-Netzwerk an den Hub anhängen, oder den IP-Adressbereich 100.64.0.0/24, wenn Sie das zweite VPC-Netzwerk an den Hub anhängen.
  • Schließen Sie 100.64.0.0/16 oder den gesamten RFC 6598-Bereich 100.64.0.0/10 aus, wenn Sie jedes VPC-Netzwerk anhängen.

Interaktion mit VPC-Netzwerk-Peering-Subnetzrouten

Peering-Subnetzrouten sind Routen, die zwischen VPC-Netzwerken ausgetauscht werden, die über VPC-Netzwerk-Peering verbunden sind. Auch wenn Peering-Subnetzrouten nie zwischen VPC-Spokes ausgetauscht werden, die mit einem Network Connectivity Center-Hub verbunden sind, müssen Sie die Peering-Subnetzrouten berücksichtigen. Aus Sicht der einzelnen VPC-Spokes können keine lokalen Subnetzrouten, importierte Peering-Subnetzrouten und importierte Network Connectivity Center-Subnetzrouten in Konflikt stehen.

Die folgende Konfiguration veranschaulicht dieses Konzept:

  • Das VPC-Netzwerk net-a ist ein VPC-Spoke, der mit einem Network Connectivity Center-Hub verbunden ist.
  • Das VPC-Netzwerk net-b ist ein VPC-Spoke, der mit demselben Network Connectivity Center-Hub verbunden ist.
  • Die VPC-Netzwerke net-b und net-c sind über VPC-Netzwerk-Peering miteinander verbunden.

Angenommen, der IP-Adressbereich eines lokalen Subnetzes für 100.64.0.0/24 ist in net-c vorhanden. Dadurch wird eine lokale Subnetzroute in net-c und eine Peering-Subnetzroute in net-b erstellt. Obwohl die Peering-Subnetzroute für den IP-Adressbereich 100.64.0.0/24 nicht in den Network Connectivity Center-Hub exportiert wird, verhindert deren Vorhandensein in net-b, dass net-b eine Route des Network Connectivity Centers importiert werden kann, deren Ziel genau mit 100.64.0.0/24 übereinstimmt, in 100.64.0.0/24 passt oder 100.64.0.0/24 enthält. Daher können in net-a keine lokalen Subnetzrouten für 100.64.0.0/24, 100.64.0.0/25 oder 100.64.0.0/16 vorhanden sein, es sei denn, Sie konfigurierennet-a so, dass er den in Konflikt stehenden Bereich nicht exportiert.

Routentabellen mit Subnetzrouten

Google Cloud zeigt Subnetzrouten des Network Connectivity Centers, die aus VPC-Spokes importiert wurden, in zwei Routingtabellen an:

Google Cloud aktualisiert die Tabelle der VPC-Netzwerkrouten jedes VPC-Spoke und die Hub-Routingtabelle des Network Connectivity Centers automatisch, wenn eine der folgenden Bedingungen erfüllt ist:

  • Wenn Sie eine Aktivität für Subnetzrouten ausführen, z. B. das Hinzufügen oder Löschen eines Subnetzes.
  • Wenn VPC-Spokes dem Hub hinzugefügt oder daraus entfernt werden.

In VPC-Netzwerkroutentabellen wird jede importierte Route von anderen VPC-Spokes als Subnetzroute des Network Connectivity Centers angezeigt, deren nächster Hop der Network Connectivity Center-Hub ist. Die Namen der Subnetzrouten des Network Connectivity Centers beginnen mit dem Präfix ncc-subnet-route-. Wenn Sie den tatsächlichen nächsten Hop für eine importierte Network Connectivity Center-Subnetzroute sehen möchten, können Sie die Network Connectivity Center-Hub-Routingtabelle oder die Routingtabelle für das VPC-Netzwerk des VPC-Spokes, der die Subnetzroute in den Network Connectivity Center-Hub exportiert.

Weitere Informationen zu VPC-Routen finden Sie unter Routen in der VPC-Dokumentation.

Nächste Schritte