Inter-VPC-Netzwerkverbindung zwischen Clouds mit Network Connectivity Center

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Dieses Dokument enthält eine Referenzarchitektur, mit der Sie eine Inter-VPC-Netzwerktopologie eines cloudübergreifenden Netzwerks in Google Cloudbereitstellen können. Dieses Netzwerkdesign ermöglicht die Bereitstellung von Softwarediensten über Google Cloud und externe Netzwerke wie lokale Rechenzentren oder andere Cloud-Dienstanbieter (Cloud Service Providers, CSPs).

Die Zielgruppe dieses Dokuments sind Netzwerkadministratoren, Cloud-Architekten und Unternehmensarchitekten, die die Netzwerkverbindung aufbauen. Es umfasst auch Cloud-Architekten, die die Bereitstellung von Arbeitslasten planen. In diesem Dokument werden grundlegende Kenntnisse über Routing und Internetverbindung vorausgesetzt.

Dieses Design unterstützt mehrere externe Verbindungen, mehrere VPC-Netzwerke (Virtual Private Cloud) mit Dienstzugriff, die Dienste und Dienstzugriffspunkte enthalten, sowie mehrere VPC-Netzwerke für Arbeitslasten.

In diesem Dokument bezieht sich der Begriff Dienstzugriffspunkte auf Zugangspunkte zu Diensten, die über den Google Cloud Zugriff auf private Dienste und Private Service Connect zur Verfügung gestellt werden. Network Connectivity Center ist ein Hub-and-Spoke-Steuerungsebenenmodell für die Verwaltung von Netzwerkverbindungen inGoogle Cloud. Die Hub-Ressource bietet eine zentralisierte Verbindungsverwaltung für VPC-Spokes von Network Connectivity Center.

Ein Network Connectivity Center-Hub ist eine globale Steuerungsebene, die Routen erkennt und zwischen den verschiedenen damit verbundenen Spoke-Typen verteilt. VPC-Spokes fügen in der Regel Subnetzrouten in die zentralisierte Hub-Routentabelle ein. Hybrid-Spokes fügen in der Regel dynamische Routen in die zentrale Routentabelle des Hubs ein. Mithilfe der Informationen der Steuerungsebene des Network Connectivity Center-Hubs stellt Google Cloudautomatisch eine Verbindung auf Datenebene zwischen Network Connectivity Center-Spokes her.

Network Connectivity Center ist der empfohlene Ansatz zum Verbinden von VPCs für skalierbares Wachstum auf Google Cloud. Wenn Sie virtuelle Netzwerk-Appliances (NVAs) in den Trafficpfad einfügen müssen, können Sie die Router-Appliance-Funktion für dynamische Routen verwenden oder statische oder richtlinienbasierte Routen zusammen mit VPC-Netzwerk-Peering verwenden, um VPCs zu verbinden. Weitere Informationen finden Sie unter Cloudübergreifende Inter-VPC-Konnektivität mit VPC-Netzwerk-Peering.

Architektur

Das folgende Diagramm bietet einen allgemeinen Überblick über die Architektur der Netzwerke und die verschiedenen Paketflüsse, die diese Architektur unterstützt.

Die Architektur enthält die folgenden übergeordneten Elemente:

Komponente	Zweck	Interaktionen
Externe Netzwerke (lokales Netzwerk oder anderes CSP-Netzwerk)	Enthält die Clients von Arbeitslasten, die in den Arbeitslast-VPCs und in den VPCs mit Zugriff auf Dienste ausgeführt werden. Externe Netzwerke können auch Dienste hosten.	Tausch über das Transitnetzwerk Daten mit den VPC-Netzwerken von Google Cloudaus. Stellt eine Verbindung zum Transitnetzwerk über Cloud Interconnect oder HA VPN her. Beendet ein Ende der folgenden Abläufe: Extern/extern Externer Zugriff auf Dienste External-to-Private-Service-Connect-Nutzer Extern an Arbeitslast
Transit-VPC-Netzwerk (in Network Connectivity Center auch als Routing-VPC-Netzwerk bezeichnet)	Fungiert als Hub für das externe Netzwerk, das VPC-Netzwerk für den Zugriff auf Dienste und die Arbeitslast-VPC-Netzwerke.	Verbindet das externe Netzwerk, das VPC-Netzwerk für den Zugriff auf Dienste, das Private Service Connect-Nutzernetzwerk und die VPC-Netzwerke für Arbeitslasten über eine Kombination aus Cloud Interconnect, HA VPN und Network Connectivity Center.
VPC-Netzwerk mit Dienstzugriff	Bietet Zugriff auf Dienste, die von Arbeitslasten benötigt werden, die in den Arbeitslast-VPC-Netzwerken oder externen Netzwerken ausgeführt werden. Bietet außerdem Zugangspunkte zu verwalteten Diensten, die in anderen Netzwerken gehostet werden.	Tausch über das Transitnetzwerk Daten mit den externen, Arbeitslast- und Private Service Connect-Nutzernetzwerken aus. Stellt über HA VPN eine Verbindung zur Transit-VPC her. Durch das von HA VPN bereitgestelltes Transitiv-Routing kann externer Traffic VPCs verwalteter Dienste über das VPC-Netzwerk mit Dienstzugriff erreichen. Beendet ein Ende der folgenden Abläufe: Externer Zugriff auf Dienste Zugriff von Arbeitslast auf Dienste Dienstzugriff-zu-Private-Service-Connect-Nutzer
VPC-Netzwerk für verwaltete Dienste	Hostt verwaltete Dienste, die von Clients in anderen Netzwerken benötigt werden.	Taugt Daten mit den externen Netzwerken sowie den Netzwerken für den Dienstzugriff, Private Service Connect-Nutzer und den Arbeitslastnetzwerken aus. Stellt über den Zugriff auf private Dienste mit VPC-Netzwerk-Peering eine Verbindung zum VPC-Netzwerk für den Dienstzugriff her. Die VPC der verwalteten Dienste kann über Private Service Connect oder den Zugriff auf private Dienste auch eine Verbindung zur Private Service Connect-Nutzer-VPC herstellen. Beendet ein Ende von Datenflüssen aus allen anderen Netzwerken.
Private Service Connect-Nutzer-VPC	Hostt Private Service Connect-Endpunkte, auf die von anderen Netzwerken aus zugegriffen werden kann. Diese VPC kann auch eine Arbeitslast-VPC sein.	Daten werden über das Transit-VPC-Netzwerk mit den externen VPC-Netzwerken und dem Dienstzugriff-VPC-Netzwerk ausgetauscht. Stellt eine Verbindung zum Transitnetzwerk und zu anderen Arbeitslast-VPC-Netzwerken über Network Connectivity Center-VPC-Spokes her.
VPC-Netzwerke der Arbeitslast	Hostt Arbeitslasten, die von Clients in anderen Netzwerken benötigt werden. Diese Architektur ermöglicht mehrere Arbeitslast-VPC-Netzwerke.	Daten werden über das Transit-VPC-Netzwerk mit den externen VPC-Netzwerken und dem Dienstzugriff-VPC-Netzwerk ausgetauscht. Stellt eine Verbindung zum Transitnetzwerk, zu Private Service Connect-Nutzernetzwerken und zu anderen Arbeitslast-VPC-Netzwerken über Network Connectivity Center-VPC-Spokes her. Beendet ein Ende der folgenden Abläufe: Extern an Arbeitslast Zugriff von Arbeitslast auf Dienste Arbeitslast mit Private Service verbinden Arbeitslast zu Arbeitslast
Network Connectivity Center	Der Network Connectivity Center-Hub enthält eine globale Routingdatenbank, die als Netzwerksteuerungsebene für VPC-Subnetze und Hybrid-Verbindungsrouten in jeder Google Cloud Region dient.	Verbindet mehrere VPC- und Hybridnetzwerke in einer Any-to-Any-Topologie. Dazu wird ein Datenpfad erstellt, der die Routingtabelle der Steuerungsebene verwendet.

Das folgende Diagramm zeigt eine detaillierte Ansicht der Architektur, in der die vier Verbindungen zwischen den Komponenten hervorgehoben sind:

Beschreibungen der Verbindungen

In diesem Abschnitt werden die vier Verbindungen beschrieben, die im vorherigen Diagramm dargestellt sind. In der Dokumentation zu Network Connectivity Center wird das Transit-VPC-Netzwerk als Routing-VPC bezeichnet. Diese Netzwerke haben zwar unterschiedliche Namen, dienen aber demselben Zweck.

Verbindung 1: zwischen externen Netzwerken und den Transit-VPC-Netzwerken

Diese Verbindung zwischen den externen Netzwerken und den Transit-VPC-Netzwerken erfolgt über Cloud Interconnect oder HA VPN. Die Routen werden mithilfe von BGP zwischen den Cloud Routern im Transit-VPC-Netzwerk und zwischen den externen Routern im externen Netzwerk ausgetauscht.

• Router in den externen Netzwerken geben die Routen für die externen Subnetze an die VPC-Cloud Router für öffentliche Verkehrsmittel an. Im Allgemeinen geben externe Router an einem bestimmten Standort Routen von demselben externen Standort an, der bevorzugt wird als Routen für andere externe Standorte. Die Präferenz der Routen kann mithilfe von BGP-Messwerten und -Attributen ausgedrückt werden.
• Cloud Router im Transit-VPC-Netzwerk bewerben Routen für Präfixe in den VPCs von Google Cloudfür die externen Netzwerke. Diese Routen müssen mit benutzerdefinierten Cloud Router-Routenansagen angekündigt werden.
• Mit Network Connectivity Center können Sie Daten zwischen verschiedenen lokalen Netzwerken mithilfe des Backbonenetzwerks von Google übertragen. Wenn Sie die Interconnect-VLAN-Anhänge als Network Connectivity Center-Hybrid-Spokes konfigurieren, müssen Sie die Site-to-Site-Datenübertragung aktivieren.
• Cloud Interconnect-VLAN-Anhänge, die dieselben externen Netzwerkpräfixe verwenden, werden als einzelner Network Connectivity Center-Spoke konfiguriert.

Verbindung 2: zwischen Transit-VPC-Netzwerken und VPC-Netzwerken mit Zugriff auf Dienste

Diese Verbindung zwischen Transit-VPC-Netzwerken und VPC-Netzwerken mit Dienstzugriff erfolgt über HA VPN mit separaten Tunneln für jede Region. Routen werden mithilfe von BGP zwischen den regionalen Cloud Routern in den Transit-VPC-Netzwerken und in den VPC-Netzwerken für den Zugriff auf Dienste ausgetauscht.

• Transit-VPC-HA VPN-Cloud Router geben Routen für externe Netzwerkpräfixe, Arbeitslast-VPCs und andere VPCs mit Dienstzugriff an den VPC-Cloud Router mit Dienstzugriff an. Diese Routen müssen mit benutzerdefinierten Cloud Router-Routenankündigungen angekündigt werden.
• Die VPC-Netzwerk für den Zugriff auf Dienste kündigt ihre Subnetze und die Subnetze aller angehängten VPC-Netzwerke der verwalteten Dienste an das Transit-VPC-Netzwerk an. VPC-Routen für verwaltete Dienste und die VPC-Subnetzrouten für den Zugriff auf Dienste müssen mit Ankündigungen benutzerdefinierter Cloud Router-Routen angekündigt werden.

Verbindung 3: zwischen dem Transit-VPC-Netzwerk, Arbeitslast-VPC-Netzwerken und Private Service Connect-Diensten auf VPC-Netzwerke

Die Verbindung zwischen dem Transit-VPC-Netzwerk, den Arbeitslast-VPC-Netzwerken und den Private Service Connect-VPC-Netzwerken von Nutzern wird hergestellt, wenn Subnetze und Präfixrouten über Network Connectivity Center ausgetauscht werden. Diese Verbindung ermöglicht die Kommunikation zwischen den Arbeitslast-VPC-Netzwerken, VPC-Netzwerken mit Zugriff auf Dienste, die als Network Connectivity Center-VPC-Spokes verbunden sind, und anderen Netzwerken, die als Network Connectivity Center-Hybrid-Spokes verbunden sind. Zu diesen anderen Netzwerken gehören die externen Netzwerke und die VPC-Netzwerke für den Dienstzugriff, die Verbindung 1 bzw. Verbindung 2 verwenden.

• Die Cloud Interconnect- oder HA VPN-Anhänge im Transit-VPC-Netzwerk verwenden Network Connectivity Center, um dynamische Routen in die Arbeitslast-VPC-Netzwerke zu exportieren.
• Wenn Sie das Arbeitslast-VPC-Netzwerk als Spoke des Network Connectivity Center-Hubs konfigurieren, exportiert das Arbeitslast-VPC-Netzwerk seine Subnetze automatisch in das Transit-VPC-Netzwerk. Optional können Sie das Transit-VPC-Netzwerk als VPC-Spoke einrichten. Es werden keine statischen Routen aus dem Arbeitslast-VPC-Netzwerk in das Transit-VPC-Netzwerk exportiert. Es werden keine statischen Routen aus dem Transit-VPC-Netzwerk in das Arbeitslast-VPC-Netzwerk exportiert.

Verbindung 4: Private Service Connect-Nutzer-VPC mit Network Connectivity Center-Weitergabe

• Private Service Connect-Endpunkte sind in einer gemeinsamen VPC organisiert, die Nutzern den Zugriff auf eigene und von Drittanbietern verwaltete Dienste ermöglicht.
• Das Private Service Connect-Nutzer-VPC-Netzwerk ist als Network Connectivity Center-VPC-Spoke konfiguriert. Dieser Spoke aktiviert die Private Service Connect-Weitergabe auf dem Network Connectivity Center-Hub. Bei der Private Service Connect-Weitergabe wird das Hostpräfix des Private Service Connect-Endpunkts als Route in der Routingtabelle des Network Connectivity Center-Hubs angegeben.
• Private Service Connect-Dienste ermöglichen den Zugriff auf private VPC-Netzwerke. Sie stellen eine Verbindung zu Arbeitslast-VPC-Netzwerken und Transit-VPC-Netzwerken her. Diese Verbindungen ermöglichen eine vorübergehende Verbindung zu Private Service Connect-Endpunkten. Für den Network Connectivity Center-Hub muss die Verbindungsweitergabe für Private Service Connect aktiviert sein.
• Network Connectivity Center erstellt automatisch einen Datenpfad von allen Spokes zum Private Service Connect-Endpunkt.

Trafficabläufe

Das folgende Diagramm zeigt die Abläufe, die durch diese Referenzarchitektur aktiviert werden.

In der folgenden Tabelle werden die Abläufe im Diagramm beschrieben:

Quelle	Ziel	Beschreibung
Externes Netzwerk	VPC-Netzwerk mit Dienstzugriff	Der Traffic folgt Routen über die externen Verbindungen zum Transitnetzwerk. Die Routen werden vom nach außen gerichteten Cloud Router angekündigt. Der Traffic folgt der benutzerdefinierten Route zum VPC-Netzwerk für den Zugriff auf Dienste. Die Route wird über die HA VPN-Verbindung angekündigt. Wenn sich das Ziel in einem VPC-Netzwerk für verwaltete Dienste befindet, das über den Zugriff auf private Dienste mit dem VPC-Netzwerk für den Zugriff auf Dienste verbunden ist, folgt der Traffic den benutzerdefinierten Routen von Network Connectivity Center zum Netzwerk für verwaltete Dienste.
VPC-Netzwerk mit Dienstzugriff	Externes Netzwerk	Der Traffic folgt einer benutzerdefinierten Route über die HA VPN-Tunnel zum Transitnetzwerk. Der Traffic folgt den Routen über die externen Verbindungen zurück zum externen Netzwerk. Die Routen werden von den externen Routern über BGP erkannt.
Externes Netzwerk	VPC-Netzwerk der Arbeitslast oder Private Service Connect-VPC-Netzwerk des Nutzers	Der Traffic folgt den Routen über die externen Verbindungen zum Transitnetzwerk. Die Routen werden vom nach außen gerichteten Cloud Router angekündigt. Der Traffic folgt der Subnetzroute zum relevanten Arbeitslast-VPC-Netzwerk. Die Route wird über Network Connectivity Center erlernt.
VPC-Netzwerk der Arbeitslast oder Private Service Connect-VPC-Netzwerk des Nutzers	Externes Netzwerk	Der Traffic folgt einer dynamischen Route zurück zum Transitnetzwerk. Die Route wird über einen Export benutzerdefinierter Network Connectivity Center-Routen erlernt. Der Traffic folgt den Routen über die externen Verbindungen zurück zum externen Netzwerk. Die Routen werden von den externen Routern über BGP erkannt.
VPC-Netzwerk der Arbeitslast	VPC-Netzwerk mit Dienstzugriff	Der Traffic folgt den Routen zum Transit-VPC-Netzwerk. Die Routen werden durch einen Export benutzerdefinierter Network Connectivity Center-Routen erkannt. Der Traffic folgt einer Route durch einen der HA VPN-Tunnel zum VPC-Netzwerk für den Zugriff auf Dienste. Die Routen werden aus Ankündigungen benutzerdefinierter BGP-Routen erlernt.
VPC-Netzwerk mit Dienstzugriff	VPC-Netzwerk der Arbeitslast	Der Traffic folgt einer benutzerdefinierten Route zum Transitnetzwerk. Die Route wird über die HA VPN-Tunnel hinweg angekündigt. Der Traffic folgt der Subnetzroute zum relevanten Arbeitslast-VPC-Netzwerk. Die Route wird über Network Connectivity Center erlernt.
VPC-Netzwerk der Arbeitslast	VPC-Netzwerk der Arbeitslast	Traffic, der eine Arbeitslast-VPC verlässt, folgt über Network Connectivity Center der spezifischeren Route zur anderen Arbeitslast-VPC. Durch den Rücktraffic wird dieser Pfad umgekehrt.

Verwendete Produkte

• Virtual Private Cloud (VPC): Ein virtuelles System, das globale, skalierbare Netzwerkfunktionen für Ihre Google Cloud Arbeitslasten bietet. VPC umfasst VPC-Netzwerk-Peering, Private Service Connect, Zugriff auf private Dienste und freigegebene VPCs.
• Network Connectivity Center: Ein Orchestrierungs-Framework, das die Netzwerkverbindung zwischen Spoke-Ressourcen vereinfacht, die mit einer zentralen Verwaltungsressource, dem Hub, verbunden sind.
• Cloud Interconnect: Ein Dienst, mit dem Ihr externes Netzwerk über eine hochverfügbare Verbindung mit niedriger Latenz auf das Google-Netzwerk erweitert wird.
• Cloud VPN: Ein Dienst, mit dem Sie Ihr Peer-Netzwerk über einen IPsec-VPN-Tunnel sicher auf das Google-Netzwerk ausdehnen können.
• Cloud Router: Ein verteiltes und vollständig verwaltetes Angebot, das Lautsprecher- und Antwortfunktionen des Border Gateway Protocol (BGP) bietet. Cloud Router arbeitet mit Cloud Interconnect, Cloud VPN und Router-Appliances zusammen, um dynamische Routen in VPC-Netzwerken basierend auf von BGP empfangenen und benutzerdefinierten erkannten Routen zu erstellen.
• Cloud-Firewall der nächsten Generation: Ein vollständig verteilter Firewalldienst mit erweiterten Schutzfunktionen, Mikrosegmentierung und einfacher Verwaltung, um Ihre Google Cloud Arbeitslasten vor internen und externen Angriffen zu schützen.

Designaspekte

In diesem Abschnitt werden Designfaktoren, Best Practices und Designempfehlungen beschrieben, die Sie berücksichtigen sollten, wenn Sie mit dieser Referenzarchitektur eine Topologie entwickeln, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit und Leistung entspricht.

Sicherheit und Compliance

In der folgenden Liste werden die Sicherheits- und Complianceaspekte für diese Referenzarchitektur beschrieben:

• Aus Compliancegründen möchten Sie Arbeitslasten möglicherweise nur in einer einzigen Region bereitstellen. Wenn der gesamte Traffic in einer einzelnen Region bleiben soll, können Sie eine Topologie von 99,9% verwenden.
• Verwenden Sie die Cloud Next Generation Firewall (Cloud NGFW), um Traffic zu sichern, der in die VPC-Netzwerke für den Dienstzugriff und die Arbeitslast ein- und ausgeht. Zum Prüfen des Traffics zwischen Hybridnetzwerken über das Transitnetzwerk oder zwischen externen Netzwerken und von Google verwalteten Diensten müssen Sie externe Firewalls oder NVA-Firewalls verwenden.
• Wenn Sie eine L7-Traffic-Prüfung benötigen, aktivieren Sie den Dienst zur Erkennung und Verhinderung von Eindringversuchen (optional mit Unterstützung für die TLS-Prüfung), um schädliche Aktivitäten zu blockieren und Ihre Arbeitslasten vor Bedrohungen zu schützen. Dazu stehen Sicherheitslücken, Anti-Spyware- und Antivirenprogramme zur Verfügung. Der Dienst erstellt von Google verwaltete zonale Firewall-Endpunkte, die mithilfe einer Paketabfangtechnologie die Arbeitslasten transparent prüfen, ohne dass eine Umstrukturierung der Route erforderlich ist. Für Cloud Next Generation Firewall Enterprise fallen Gebühren für zonale Firewall-Endpunkte und Datenverarbeitung an.
• Wenn Sie Traffic basierend auf Daten von Google Threat Intelligence zulassen oder blockieren möchten, verwenden Sie Google Threat Intelligence. Es fallen Kosten für die Cloud Next Generation Firewall Standard-Datenverarbeitung an.
• Aktivieren Sie das Logging von Firewallregeln und verwenden Sie Firewall Insights, um Ihre Firewallregeln im Blick zu behalten, ihre Auswirkungen zu prüfen, sie zu verstehen und zu optimieren. Das Logging von Firewallregeln kann Kosten verursachen, sodass Sie es selektiv verwenden sollten.
• Aktivieren Sie Konnektivitätstests, um dafür zu sorgen, dass sich der Traffic wie erwartet verhält.
• Aktivieren Sie Logging und Monitoring entsprechend Ihren Traffic- und Complianceanforderungen. Verwenden Sie VPC-Flusslogs zusammen mit Flow Analyzer, um Informationen zu Ihren Traffic-Mustern zu erhalten.
• Verwenden Sie Cloud IDS oder Cloud NGFW Enterprise zur Einbruchsprävention im Benachrichtigungsmodus, um zusätzliche Informationen zum Traffic zu erhalten.

Zuverlässigkeit

In der folgenden Liste werden die Zuverlässigkeitsaspekte für diese Referenzarchitektur beschrieben:

• Um eine Verfügbarkeit von 99,99% für Cloud Interconnect zu erreichen, müssen Sie eine Verbindung in zwei verschiedene Google Cloud Regionen aus verschiedenen Metropolregionen über zwei verschiedene Zonen herstellen.
• Sie können Arbeitslasten und andere Cloud-Ressourcen auf Regionen verteilen, um die Zuverlässigkeit zu verbessern und das Risiko regionaler Ausfälle zu minimieren.
• Erstellen Sie eine ausreichende Anzahl von VPN-Tunneln, um den erwarteten Traffic zu verarbeiten. Für einzelne VPN-Tunnel gelten Bandbreitenbeschränkungen.

Leistungsoptimierung

In der folgenden Liste werden die Leistungsaspekte für diese Referenzarchitektur beschrieben:

• Sie können die Netzwerkleistung möglicherweise verbessern, indem Sie die maximale Übertragungseinheit (MTU) Ihrer Netzwerke und Verbindungen erhöhen. Weitere Informationen finden Sie unter Maximale Übertragungseinheit.
• Die Kommunikation zwischen der Transit-VPC und den Arbeitslastressourcen erfolgt über eine Network Connectivity Center-Verbindung. Diese Verbindung bietet einen Full-Line-Rate-Durchsatz für alle VMs im Netzwerk ohne zusätzliche Kosten. Sie haben mehrere Möglichkeiten, Ihr externes Netzwerk mit dem Transitnetzwerk zu verbinden. Weitere Informationen zum Ausgleich von Kosten- und Leistungsaspekten finden Sie unter Netzwerkverbindungsprodukt auswählen.

Bereitstellung

In diesem Abschnitt wird erläutert, wie Sie die Inter-VPC-Verbindung des Cloud-Netzwerks mithilfe der in diesem Dokument beschriebenen Network Connectivity Center-Architektur bereitstellen.

Die Architektur in diesem Dokument erstellt drei Arten von Verbindungen zu einer zentralen Transit-VPC sowie eine Verbindung zwischen Arbeitslast-VPC-Netzwerken und Arbeitslast-VPC-Netzwerken. Nachdem Network Connectivity Center vollständig konfiguriert ist, stellt es die Kommunikation zwischen allen Netzwerken her.

Bei dieser Bereitstellung wird davon ausgegangen, dass Sie Verbindungen zwischen dem externen und dem Transitnetzwerk in zwei Regionen erstellen, wobei sich Arbeitslast-Subnetze in anderen Regionen befinden können. Wenn Arbeitslasten nur in einer Region platziert werden, müssen Subnetze nur in dieser Region erstellt werden.

Führen Sie die folgenden Aufgaben aus, um diese Referenzarchitektur bereitzustellen:

1. Netzwerksegmentierung mit Network Connectivity Center erstellen
2. Regionen für Konnektivität und Arbeitslasten ermitteln
3. VPC-Netzwerke und -Subnetze erstellen
4. Verbindungen zwischen externen Netzwerken und dem Transit-VPC-Netzwerk erstellen
5. Verbindungen zwischen Ihrem Transit-VPC-Netzwerk und VPC-Netzwerken für den Zugriff auf Dienste erstellen
6. Verbindung zwischen Ihrem Transit-VPC-Netzwerk und Arbeitslast-VPC-Netzwerken herstellen
7. Cloud NGFW-Richtlinien konfigurieren
8. Konnektivität zu Arbeitslasten testen

Netzwerksegmentierung mit Network Connectivity Center erstellen

Bevor Sie zum ersten Mal einen Network Connectivity Center-Hub erstellen, müssen Sie entscheiden, ob Sie eine Full-Mesh-Topologie oder eine Sterntopologie verwenden möchten. Die Entscheidung, ob Sie ein vollständiges Mesh-Netzwerk miteinander verbundener VPCs oder eine Sterntopologie von VPCs festlegen, ist irreversibel. Beachten Sie die folgenden allgemeinen Richtlinien, um diese unumkehrbare Entscheidung zu treffen:

• Wenn die Geschäftsarchitektur Ihrer Organisation Traffic zwischen einem Ihrer VPC-Netzwerke zulässt, verwenden Sie das Network Connectivity Center-Mesh.
• Wenn Traffic zwischen bestimmten VPC-Spokes nicht zulässig ist, diese VPC-Spokes jedoch eine Verbindung zu einer Kerngruppe von VPC-Spokes herstellen können, verwenden Sie eine Sterntopologie von Network Connectivity Center.

Regionen für Konnektivität und Arbeitslasten ermitteln

Im Allgemeinen sollten Sie Konnektivitäts- und Google Cloud Arbeitslasten in der Nähe Ihrer lokalen Netzwerke oder anderer Cloud-Clients platzieren. Weitere Informationen zum Platzieren von Arbeitslasten finden Sie unter Google Cloud Regionsauswahl und Best Practices für die Auswahl der Region in Compute Engine.

VPC-Netzwerke und Subnetze erstellen

Führen Sie die folgenden Aufgaben aus, um VPC-Netzwerke und Subnetze zu erstellen:

1. Erstellen oder identifizieren Sie die Projekte, in denen Sie Ihre VPC-Netzwerke erstellen werden. Eine Anleitung hierzu finden Sie unter Netzwerksegmentierung und Projektstruktur. Wenn Sie freigegebene VPC-Netzwerke verwenden möchten, stellen Sie Ihre Projekte als freigegebene VPC-Hostprojekte bereit.

2. Planen Sie die Zuweisung von IP-Adressen für Ihre Netzwerke. Sie können Ihre Bereiche durch Erstellen interner Bereiche vorab zuweisen und reservieren. Dadurch wird die spätere Konfiguration und der Betrieb einfacher.

3. Erstellen Sie ein Transitnetzwerk-VPC mit aktiviertem globalem Routing.

4. VPC-Netzwerke mit Dienstzugriff erstellen Wenn Sie Arbeitslasten in mehreren Regionen haben möchten, aktivieren Sie das globale Routing.

5. Erstellen Sie Arbeitslast-VPC-Netzwerke. Wenn Sie Arbeitslasten in mehreren Regionen haben, aktivieren Sie das globale Routing.

Verbindungen zwischen externen Netzwerken und dem Transit-VPC-Netzwerk erstellen

In diesem Abschnitt wird davon ausgegangen, dass eine Verbindung in zwei Regionen besteht. Außerdem wird davon ausgegangen, dass die externen Standorte verbunden sind und ein Failover aufeinander möglich sind. Außerdem wird angenommen, dass Clients an einem externen Standort Dienste in der Region erreichen, in der sich der externe Standort befindet.

1. Richten Sie die Verbindung zwischen externen Netzwerken und Ihrem Transitnetzwerk ein. Weitere Informationen dazu finden Sie unter Externe und Hybridkonnektivität. Eine Anleitung zur Auswahl eines Konnektivitätsprodukts finden Sie unter Netzwerkverbindungsprodukt auswählen.

2. Konfigurieren Sie das BGP in jeder verbundenen Region so:

   • Konfigurieren Sie den Router am angegebenen externen Standort so:
     • Geben Sie alle Subnetze für diesen externen Standort mit demselben BGP-MED auf beiden Schnittstellen an, z. B. 100. Wenn beide Schnittstellen denselben MED-Wert ansagen, kann Google Cloud ECMP verwenden, um den Traffic über beide Verbindungen zu verteilen.
     • Geben Sie alle Subnetze vom anderen externen Standort mit einem MED mit niedrigerer Priorität als dem der ersten Region an, z. B. 200. Sagt denselben MED-Wert von beiden Schnittstellen aus.
   • Konfigurieren Sie den nach außen gerichteten Cloud Router in der Transit-VPC der verbundenen Region so:
     • Legen Sie für Ihren Cloud Router eine private ASN fest.
     • Verwenden Sie benutzerdefiniertes Routen-Advertising, um alle Subnetzbereiche aus allen Regionen über beide nach außen gerichteten Cloud Router-Schnittstellen anzukündigen. Fassen Sie sie nach Möglichkeit zusammen. Verwenden Sie auf beiden Schnittstellen denselben MED-Wert, z. B. 100.

3. Mit Network Connectivity Center-Hub und Hybrid-Spokes arbeiten, verwenden Sie die Standardparameter.

   • Erstellen Sie einen Network Connectivity Center-Hub. Wenn Ihre Organisation Traffic zwischen allen VPC-Netzwerken zulässt, verwenden Sie die Standardkonfiguration für das vollständige Mesh-Netzwerk.
   • Wenn Sie Partner Interconnect, Dedicated Interconnect, HA-VPN oder eine Router-Appliance verwenden, um lokale Präfixe zu erreichen, konfigurieren Sie diese Komponenten als verschiedene Network Connectivity Center-Hybrid-Spokes.
     • Legen Sie einen Filter fest, der alle IPv4-Adressbereiche umfasst, um die Subnetze der Routingtabelle des Network Connectivity Center-Hubs an Remote-BGP-Nachbarn bekannt zu geben.
     • Wenn die Hybridkonnektivität auf einem Cloud Router in einer Region beendet wird, die Datenübertragung unterstützt, konfigurieren Sie den Hybrid-Spoke mit aktivierter Site-to-Site-Datenübertragung. Dadurch wird die Site-to-Site-Datenübertragung über das Backbonenetzwerk von Google unterstützt.

Verbindungen zwischen Ihrem Transit-VPC-Netzwerk und VPC-Netzwerken mit Dienstzugriff erstellen

Für das transitive Routing zwischen externen Netzwerken und der VPC mit Dienstzugriff sowie zwischen Arbeitslast-VPCs und der VPC mit Dienstzugriff verwendet die VPC mit Dienstzugriff HA VPN für die Verbindung.

1. Schätzen Sie, wie viel Traffic zwischen den VPCs für öffentliche Verkehrsmittel und den VPCs für den Dienstzugriff in jeder Region übertragen werden muss. Skalieren Sie die erwartete Anzahl von Tunneln entsprechend.

2. Konfigurieren Sie HA VPN zwischen dem Transit-VPC-Netzwerk und dem VPC-Netzwerk für den Zugriff auf Dienste in Region A. Folgen Sie dazu der Anleitung unter HA VPN-Gateways zum Verbinden von VPC-Netzwerken erstellen. Erstellen Sie im Transit-VPC-Netzwerk einen dedizierten HA VPN-Cloud Router. Lassen Sie den zum externen Netzwerk ausgerichteten Router externe Netzwerkverbindungen erhalten.

   • Konfiguration des Cloud Routers für die VPC für öffentliche Verkehrsmittel:
     • Verwenden Sie benutzerdefiniertes Routen-Advertising auf dem Cloud Router in der Transit-VPC, um VPC-Subnetze von externen Netzwerken und Arbeitslasten an die VPC mit Zugriff auf Dienste bekannt zu geben.
   • Konfiguration des VPC-Cloud Routers für den Zugriff auf Dienste:
     • Verwenden Sie benutzerdefiniertes Route Advertising im Cloud Router des VPC-Netzwerks mit Zugriff auf Dienste, um die Subnetzwerke für den Zugriff auf Dienste an die Transit-VPC anzukündigen.
     • Wenn Sie den Zugriff auf private Dienste verwenden, um ein VPC-Netzwerk für verwaltete Dienste mit der VPC für den Dienstzugriff zu verbinden, verwenden Sie benutzerdefinierte Routen, um diese Subnetze ebenfalls anzukündigen.
   • Konfigurieren Sie auf der Transit-VPC-Seite des HA VPN-Tunnels das Tunnelpaar als Network Connectivity Center-Hybrid-Spoke:
     • Konfigurieren Sie den Hybrid-Spoke mit aktivierter Site-to-Site-Datenübertragung, um die interregionale Datenübertragung zu unterstützen.
     • Legen Sie einen Filter fest, der alle IPv4-Adressbereiche umfasst, um die Subnetze der Routingtabellen des Network Connectivity Center-Hubs an Remote-BGP-Nachbarn bekannt zu geben. Durch diese Aktion werden alle IPv4-Subnetzrouten an den Nachbarn gemeldet.
       • Zum Installieren dynamischer Routen bei begrenzter Kapazität auf dem externen Router konfigurieren Sie den Cloud Router so, dass eine Zusammenfassungsroute mit einem benutzerdefinierten Routen-Advertising ankündigt. Verwenden Sie diesen Ansatz, anstatt die vollständige Routentabelle des Network Connectivity Center-Hubs anzukündigen.

3. Wenn Sie die VPC eines verwalteten Dienstes über den Zugriff auf private Dienste mit der VPC für den Dienstzugriff verbinden, nachdem die VPC-Netzwerk-Peering-Verbindung hergestellt wurde, müssen Sie auch die VPC-Seite für den Dienstzugriff der VPC-Netzwerk-Peering-Verbindung aktualisieren, um benutzerdefinierte Routen zu exportieren.

Verbindung zwischen Ihrem Transit-VPC-Netzwerk und Arbeitslast-VPC-Netzwerken herstellen

Verwenden Sie Network Connectivity Center mit VPC-Spokes, um eine umfangreiche Inter-VPC-Verbindung einzurichten. Network Connectivity Center unterstützt zwei verschiedene Arten von Datenebenenmodellen: das vollständige Mesh-Datenebenenmodell oder das Sterntopologie-Datenebenenmodell.

• Wenn alle Ihre Netzwerke miteinander kommunizieren können, gilt: Vollständige Mesh-Verbindung herstellen.
• Wenn Ihre Geschäftsarchitektur eine Punkt-zu-Multipoint-Topologie erfordert, klicken Sie auf Sterntopologie-Konnektivität einrichten.

Vollständige Mesh-Verbindung herstellen

Die VPC-Spokes von Network Connectivity Center umfassen die Transit-VPCs, die Private Service Connect-Nutzer-VPCs und alle Arbeitslast-VPCs.

• Obwohl Network Connectivity Center ein vollständig Mesh-Netzwerk aus VPC-Spokes erstellt, müssen die Netzwerkbetreiber den Traffic zwischen den Quellnetzwerken und den Zielnetzwerken mithilfe von Firewallregeln oder Firewallregeln zulassen.
• Konfigurieren Sie alle Arbeitslast-, Transit- und Private Service Connect-Nutzer-VPCs als Network Connectivity Center-VPC-Spokes. VPC-Spokes dürfen keine Subnetzüberschneidungen haben.
  • Melden Sie beim Konfigurieren des VPC-Spokes nicht überlappende IP-Adressbereiche an die Routingtabelle des Network Connectivity Center-Hubs:
    • Schließen Sie Export-Subnetzbereiche ein.
    • Subnetzbereiche für Export ausschließen.
• Wenn sich VPC-Spokes in verschiedenen Projekten befinden und die Spokes von anderen Administratoren als den Network Connectivity Center-Hub-Administratoren verwaltet werden, müssen die VPC-Spoke-Administratoren eine Anfrage initiieren, um dem Network Connectivity Center-Hub in den anderen Projekten beizutreten.
  • Verwenden Sie IAM-Berechtigungen (Identity and Access Management) im Hubprojekt von Network Connectivity Center, um diesem Nutzer die Rolle roles/networkconnectivity.groupUser zu gewähren.
• Damit private Dienstverbindungen über andere Network Connectivity Center-Spokes vorübergehend und global zugänglich sind, aktivieren Sie die Weitergabe von Private Service Connect-Verbindungen auf dem Network Connectivity Center-Hub.

Wenn eine vollständig vermaschte Inter-VPC-Kommunikation zwischen Arbeitslast-VPCs nicht zulässig ist, sollten Sie eine Sterntopologie von Network Connectivity Center verwenden.

Verbindung mit Sterntopologie herstellen

Zentralisierte Geschäftsarchitekturen, die eine Punkt-zu-Multipoint-Topologie erfordern, können eine Sterntopologie von Network Connectivity Center verwenden.

Führen Sie die folgenden Aufgaben aus, um eine Sterntopologie von Network Connectivity Center zu verwenden:

1. Erstellen Sie in Network Connectivity Center einen Network Connectivity Center-Hub und geben Sie eine Sterntopologie an.
2. Damit private Dienstverbindungen vorübergehend und global von anderen Network Connectivity Center-Spokes zugänglich sind, aktivieren Sie die Weitergabe von Private Service Connect-Verbindungen auf dem Network Connectivity Center-Hub.
3. Wenn Sie den Network Connectivity Center-Hub für eine Sterntopologie konfigurieren, können Sie VPCs in einer von zwei vordefinierten Gruppen gruppieren: Mittelgruppen oder Edge-Gruppen.

4. Konfigurieren Sie zum Gruppieren von VPCs in der mittleren Gruppe die Transit-VPC und die Private Service Connect-Nutzer-VPCs als Network Connectivity Center-VPC-Spoke als Teil der Mittelgruppe.

   Network Connectivity Center erstellt ein vollständig Mesh-Netzwerk zwischen VPC-Spokes, die sich in der mittleren Gruppe befinden.

5. Zum Gruppieren von Arbeitslast-VPCs in der Edge-Gruppe konfigurieren Sie jedes dieser Netzwerke als Network Connectivity Center-VPC-Spokes innerhalb dieser Gruppe.

   Network Connectivity Center erstellt einen Punkt-zu-Punkt-Datenpfad von jedem VPC-Spoke von Network Connectivity Center zu allen VPCs in der Center-Gruppe.

Cloud NGFW-Richtlinien konfigurieren

Zusätzlich zu den Anleitungen unter Sicherheit und Compliance sollten Sie sich die Best Practices für Firewallregeln ansehen.

Weitere Hinweise:

• Wir empfehlen die Verwendung von Netzwerk-Firewallrichtlinien anstelle von VPC-Firewallregeln, wenn Ihre Arbeitslasten auf Compute Engine-VMs ausgeführt werden. Netzwerk-Firewallrichtlinien bieten Vorteile wie detaillierte Sicherheit und Zugriffssteuerung durch den Einsatz von Tags, vereinfachte Regelverwaltung, einfachere Abläufe, einen umfangreicheren Funktionsumfang und einen flexiblen Datenstandort. Wenn Sie bereits VPC-Firewallregeln haben, können Sie das Migrationstool für VPC-Firewallregeln verwenden, um Sie bei der Migration zu einer globalen Netzwerk-Firewallrichtlinie zu unterstützen.
• Google Kubernetes Engine erstellt und verwaltet automatisch bestimmte VPC-Firewallregeln, um grundlegenden Traffic zuzulassen. Daher empfehlen wir, diese Regeln nicht zu ändern oder zu löschen. Netzwerk-Firewallrichtlinien können jedoch weiterhin zusammen mit VPC-Firewallregeln verwendet werden. Optional können Sie die Reihenfolge der Richtlinienerzwingung ändern.
• Wir empfehlen, aufgrund der IAM-Steuerelemente, der verbesserten Skalierung und der Unterstützung von Netzwerk-Firewallrichtlinien Tags anstelle von Netzwerk-Tags mit Firewallregeln zu verwenden. Da Tags jedoch nicht von hierarchischen Firewallrichtlinien oder über Peering-Netzwerke von Network Connectivity Center unterstützt werden, müssen Sie in diesen Fällen Regeln erstellen, die auf CIDR-Bereichen basieren.

1. Wenn Sie die L7-Prüfung in Cloud NGFW aktivieren möchten, konfigurieren Sie den Dienst zur Einbruchsprävention, einschließlich Sicherheitsprofilen, Firewall-Endpunkt und VPC-Verknüpfung.
2. Erstellen Sie eine globale Netzwerk-Firewallrichtlinie und alle erforderlichen Firewallregeln. Berücksichtigen Sie die vorhandenen impliziten Regeln zum Zulassen von ausgehendem Traffic und zum Ablehnen von eingehendem Traffic, die in jedem VPC-Netzwerk vorhanden sind.
3. Verknüpfen Sie die Richtlinie mit den VPC-Netzwerken.
4. Wenn Sie in Ihren Netzwerken bereits VPC-Firewallregeln verwenden, sollten Sie die Richtlinie und die Reihenfolge der Regelauswertung ändern, damit Ihre neuen Regeln vor den VPC-Firewallregeln ausgewertet werden.
5. Aktivieren Sie optional das Logging von Firewallregeln.

Verbindung zu Arbeitslasten testen

Wenn Sie Arbeitslasten haben, die bereits in Ihren VPC-Netzwerken bereitgestellt sind, testen Sie jetzt den Zugriff darauf. Wenn Sie die Netzwerke vor der Bereitstellung von Arbeitslasten verbunden haben, können Sie die Arbeitslasten jetzt bereitstellen und testen.

Nächste Schritte

• Weitere Informationen zu den in diesem Designleitfaden Google Cloud verwendeten Produkten:
  • VPC-Netzwerke
  • Network Connectivity Center
  • Cloud Interconnect
  • HA VPN
• Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.

Beitragende

Autoren:

• Eric Yu | Networking Specialist Customer Engineer
• Deepak Michael | Networking Specialist Customer Engineer
• Victor Moreno | Product Manager, Cloud Networking
• Osvaldo Costa | Networking Specialist Customer Engineer

Weitere Beitragende:

• Mark Schlagenhauf | Technical Writer, Netzwerk
• Ammett Williams | Developer Relations Engineer
• Ghaleb Al-habian | Network Specialist
• Tony Sarathchandra | Senior Product Manager