Netzwerke sind erforderlich, damit Ressourcen innerhalb Ihrer Google Cloud-Organisation und zwischen Ihrer Cloud-Umgebung und der lokalen Umgebung kommunizieren können. In diesem Abschnitt wird die Struktur des Blueprints für VPC-Netzwerke, IP-Adressbereich, DNS, Firewallrichtlinien und die Konnektivität zur lokalen Umgebung beschrieben.
Netzwerktopologie
Das Blueprint-Repository bietet die folgenden Optionen für Ihre Netzwerktopologie:
- Verwenden Sie für jede Umgebung separate freigegebene VPC-Netzwerke, ohne dass der Netzwerktraffic direkt zwischen Umgebungen zugelassen wird.
- Verwenden Sie ein Hub-and-Spoke-Modell, das ein Hub-Netzwerk hinzufügt, um jede Umgebung in Google Cloud zu verbinden, wobei der Netzwerkverkehr zwischen Umgebungen durch eine virtuelle Netzwerk-Appliance (NVA) gesteuert wird.
Wählen Sie die dual freigegebene VPC-Netzwerktopologie aus, wenn Sie keine direkte Netzwerkverbindung zwischen Umgebungen wünschen. Wählen Sie die Hub-and-Spoke-Netzwerktopologie aus, wenn Sie Netzwerkverbindungen zwischen Umgebungen zulassen möchten, die von einer NVA gefiltert werden, z. B. wenn Sie vorhandene Tools verwenden, die einen direkten Netzwerkpfad zu jedem Server in Ihrer Umgebung erfordern.
Beide Topologien verwenden eine freigegebene VPC als Hauptnetzwerknetzwerkkonstrukt, da eine freigegebene VPC eine klare Trennung der Zuständigkeiten ermöglicht. Netzwerkadministratoren verwalten Netzwerkressourcen in einem zentralisierten Hostprojekt und Arbeitslastteams stellen ihre eigenen Anwendungsressourcen bereit und nutzen die Netzwerkressourcen in Dienstprojekten, die an das Hostprojekt angehängt sind.
Beide Topologien enthalten eine Basisversion und eine eingeschränkte Version jedes VPC-Netzwerks. Das Basis-VPC-Netzwerk wird für Ressourcen verwendet, die nicht vertrauliche Daten enthalten, und das eingeschränkte VPC-Netzwerk wird für Ressourcen mit sensiblen Daten verwendet, die VPC Service Controls erfordern. Weitere Informationen zur Implementierung von VPC Service Controls finden Sie unter Ressourcen mit VPC Service Controls schützen.
Duale freigegebene VPC-Netzwerktopologie
Wenn Sie die Netzwerkisolation zwischen Ihren Entwicklungs-, Nicht-Produktions- und Produktionsnetzwerken in Google Cloud benötigen, empfehlen wir die duale freigegebene VPC-Netzwerktopologie. Diese Topologie verwendet für jede Umgebung separate freigegebene VPC-Netzwerke, wobei jede Umgebung zusätzlich zwischen einem grundlegenden freigegebenen VPC-Netzwerk und einem eingeschränkten freigegebenen VPC-Netzwerk aufgeteilt wird.
Das folgende Diagramm zeigt die Dual-VPC-Netzwerktopologie.
Im Diagramm werden die wichtigsten Konzepte der dualen freigegebenen Topologie für freigegebene VPC beschrieben:
- Jede Umgebung (Produktion, Nicht-Produktion und Entwicklung) hat ein freigegebenes VPC-Netzwerk für das Basisnetzwerk und ein freigegebenes VPC-Netzwerk für das eingeschränkte Netzwerk. Dieses Diagramm zeigt nur die Produktionsumgebung, aber für jede Umgebung wird dasselbe Muster wiederholt.
- Jedes freigegebene VPC-Netzwerk hat zwei Subnetze, wobei sich jedes Subnetz in einer anderen Region befindet.
- Die Verbindung mit lokalen Ressourcen wird über vier VLAN-Anhänge für die Dedicated Interconnect-Instanz für jedes freigegebene VPC-Netzwerk ermöglicht, wobei vier Cloud Router-Dienste verwendet werden (zwei in jeder Region für Redundanz). Weitere Informationen finden Sie unter Hybridkonnektivität zwischen der lokalen Umgebung und Google Cloud.
Diese Topologie lässt zu, dass der Netzwerkverkehr direkt zwischen Umgebungen fließt. Wenn der Netzwerkverkehr direkt zwischen Umgebungen fließen muss, müssen Sie zusätzliche Schritte ausführen, um diesen Netzwerkpfad zuzulassen. Beispiel: Sie können Private Service Connect-Endpunkte konfigurieren, um einen Dienst von einem VPC-Netzwerk zu einem anderen VPC-Netzwerk freizugeben. Alternativ können Sie Ihr lokales Netzwerk so konfigurieren, dass der Traffic von einer Google Cloud-Umgebung zur lokalen Umgebung und dann zu einer anderen Google Cloud-Umgebung geleitet wird.
Hub-and-Spoke-Netzwerktopologie
Wenn Sie Ressourcen in Google Cloud bereitstellen, die einen direkten Netzwerkpfad zu Ressourcen in mehreren Umgebungen erfordern, empfehlen wir die Hub-and-Spoke-Netzwerktopologie.
Die Hub-and-Spoke-Topologie verwendet einige der Konzepte, die Teil der dualen freigegebenen VPC-Topologie sind. Die Topologie wird jedoch geändert, um ein Hub-Netzwerk hinzuzufügen. Das folgende Diagramm zeigt die Hub-and-Spoke-Topologie.
Im Diagramm werden die folgenden Schlüsselkonzepte der Hub-and-Spoke-Netzwerktopologie beschrieben:
- Dieses Modell fügt ein Hub-Netzwerk hinzu. Jedes der Entwicklungs-, Nicht-Produktions- und Produktionsnetzwerke (Spokes) ist über VPC-Netzwerk-Peering mit dem Hub-Netzwerk verbunden. Wenn Sie dagegen das Kontingentlimit überschreiten, können Sie stattdessen ein HA VPN-Gateway verwenden.
- Die Verbindung zu lokalen Netzwerken ist nur über das Hub-Netzwerk zulässig. Alle Spoke-Netzwerke können mit freigegebenen Ressourcen im Hub-Netzwerk kommunizieren und diesen Pfad verwenden, um eine Verbindung zu lokalen Netzwerken herzustellen.
- Die Hub-Netzwerke enthalten eine NVA für jede Region, die redundant hinter internen Netzwerk-Load-Balancer-Instanzen bereitgestellt wird. Diese NVA dient als Gateway zum Zulassen oder Ablehnen der Kommunikation zwischen Spoke-Netzwerken.
- Das Hub-Netzwerk hostet auch Tools, für die eine Verbindung zu allen anderen Netzwerken erforderlich ist. Sie können beispielsweise Tools auf VM-Instanzen für die Konfigurationsverwaltung in der gemeinsamen Umgebung bereitstellen.
- Das Hub-and-Spoke-Modell wird für eine Basisversion und eine eingeschränkte Version jedes Netzwerks dupliziert.
Zum Aktivieren des Spoke-Spoke-Traffics stellt der Blueprint NVAs im freigegebenen Hub-VPC-Netzwerk bereit, die als Gateways zwischen Netzwerken dienen. Routen werden von Hub zu Spoke-VPC-Netzwerken über benutzerdefinierten Routenaustausch ausgetauscht. In diesem Szenario muss die Verbindung zwischen Spokes über die NVA weitergeleitet werden, da VPC-Netzwerk-Peering nicht transitiv ist, und Spoke-VPC-Netzwerke daher keine Daten direkt miteinander austauschen können. Sie müssen die virtuellen Appliances so konfigurieren, dass der Traffic zwischen den Spokes selektiv zugelassen wird.
Weitere Informationen zur Verwendung von NVAs zur Steuerung des Traffics zwischen Spokes finden Sie unter Zentralisierte Netzwerk-Appliances in Google Cloud.
Muster für die Projektbereitstellung
Wenn Sie neue Projekte für Arbeitslasten erstellen, müssen Sie entscheiden, wie die Ressourcen in diesem Projekt eine Verbindung zu Ihrem vorhandenen Netzwerk herstellen. In der folgenden Tabelle werden die Muster zum Bereitstellen von Projekten beschrieben, die im Blueprint verwendet werden.
| Muster | Beschreibung | Nutzungsbeispiel |
|---|---|---|
| Freigegebene Basisprojekte | Diese Projekte werden als Dienstprojekte für ein Basisprojekt mit freigegebener VPC konfiguriert. Verwenden Sie dieses Muster, wenn Ressourcen in Ihrem Projekt folgende Kriterien haben:
|
example_base_shared_vpc_project.tf |
| Freigegebene eingeschränkte Projekte | Diese Projekte werden als Dienstprojekte für ein eingeschränktes Hostprojekt in einer freigegebenen VPC konfiguriert. Verwenden Sie dieses Muster, wenn Ressourcen in Ihrem Projekt folgende Kriterien haben:
|
example_restricted_shared_vpc_project.tf |
| Floating-Projekte | Floating-Projekte sind nicht mit anderen VPC-Netzwerken in Ihrer Topologie verbunden. Verwenden Sie dieses Muster, wenn Ressourcen in Ihrem Projekt folgende Kriterien haben:
Es kann vorkommen, dass Sie das VPC-Netzwerk eines Floating-Projekts von der Haupt-VPC-Netzwerktopologie trennen und gleichzeitig eine begrenzte Anzahl von Endpunkten zwischen Netzwerken bereitstellen möchten. Veröffentlichen Sie in diesem Fall Dienste mit Private Service Connect, um den Netzwerkzugriff auf einen einzelnen Endpunkt über VPC-Netzwerke hinweg zu teilen, ohne das gesamte Netzwerk freizugeben. |
example_floating_project.tf |
| Peering-Projekte | Peering-Projekte erstellen ihre eigenen VPC-Netzwerke und verbinden sich mit anderen VPC-Netzwerken in Ihrer Topologie. Verwenden Sie dieses Muster, wenn Ressourcen in Ihrem Projekt folgende Kriterien haben:
Wenn Sie Peering-Projekte erstellen, sind Sie dafür verantwortlich, nicht in Konflikt stehende IP-Adressbereiche zuzuweisen und das Kontingent für Peering-Gruppen zu planen. |
example_peering_project.tf |
Zuweisung von IP-Adressen
In diesem Abschnitt wird erläutert, wie die Blueprint-Architektur IP-Adressbereiche zuweist. Möglicherweise müssen Sie die spezifischen IP-Adressbereiche ändern, die auf der Verfügbarkeit der IP-Adresse in der vorhandenen Hybridumgebung basieren.
Die folgende Tabelle enthält eine Aufschlüsselung des IP-Adressbereichs, der dem Blueprint zugewiesen ist. Die Hub-Umgebung gilt nur für die Hub-and-Spoke-Topologie.
| Zweck | VPC-Typ | Region | Hub-Umgebung | Entwicklungsumgebung | Nicht-Produktionsumgebung | Produktionsumgebung |
|---|---|---|---|---|---|---|
| Primäre Subnetzbereiche | Basis | Region 1 | 10.0.0.0/18 | 10.0.64.0/18 | 10.0.128.0/18 | 10.0.192.0/18 |
| Region 2 | 10.1.0.0/18 | 10.1.64.0/18 | 10.1.128.0/18 | 10.1.192.0/18 | ||
| Nicht zugewiesen | 10.{2-7}.0.0/18 | 10.{2-7}.64.0/18 | 10.{2-7}.128.0/18 | 10.{2-7}.192.0/18 | ||
| Eingeschränkt | Region 1 | 10.8.0.0/18 | 10.8.64.0/18 | 10.8.128.0/18 | 10.8.192.0/18 | |
| Region 2 | 10.9.0.0/18 | 10.9.64.0/18 | 10.9.128.0/18 | 10.9.192.0/18 | ||
| Nicht zugewiesen | 10.{10-15}.0.0/18 | 10.{10-15}.64.0/18 | 10.{10-15}.128.0/18 | 10.{10-15}.192.0/18 | ||
| Zugriff auf private Dienste | Basis | Global | 10.16.0.0/21 | 10.16.8.0/21 | 10.16.16.0/21 | 10.16.24.0/21 |
| Eingeschränkt | Global | 10.16.32.0/21 | 10.16.40.0/21 | 10.16.48.0/21 | 10.16.56.0/21 | |
| Private Service Connect-Endpunkte | Basis | Global | 10.17.0.1/32 | 10.17.0.2/32 | 10.17.0.3/32 | 10.17.0.4/32 |
| Eingeschränkt | Global | 10.17.0.5/32 | 10.17.0.6/32 | 10.17.0.7/32 | 10.17.0.8/32 | |
| Proxy-only-subnets | Basis | Region 1 | 10.18.0.0/23 | 10.18.2.0/23 | 10.18.4.0/23 | 10.18.6.0/23 |
| Region 2 | 10.19.0.0/23 | 10.19.2.0/23 | 10.19.4.0/23 | 10.19.6.0/23 | ||
| Nicht zugewiesen | 10.{20-25}.0.0/23 | 10.{20-25}.2.0/23 | 10.{20-25}.4.0/23 | 10.{20-25}.6.0/23 | ||
| Eingeschränkt | Region 1 | 10.26.0.0/23 | 10.26.2.0/23 | 10.26.4.0/23 | 10.26.6.0/23 | |
| Region 2 | 10.27.0.0/23 | 10.27.2.0/23 | 10.27.4.0/23 | 10.27.6.0/23 | ||
| Nicht zugewiesen | 10.{28-33}.0.0/23 | 10.{28-33}.2.0/23 | 10.{28-33}.4.0/23 | 10.{28-33}.6.0/23 | ||
| Sekundäre Subnetzbereiche | Basis | Region 1 | 100.64.0.0/18 | 100.64.64.0/18 | 100.64.128.0/18 | 100.64.192.0/18 |
| Region 2 | 100.65.0.0/18 | 100.65.64.0/18 | 100.65.128.0/18 | 100.65.192.0/18 | ||
| Nicht zugewiesen | 100.{66-71}.0.0/18 | 100.{66-71}.64.0/18 | 100.{66-71}.128.0/18 | 100.{66-71}.192.0/18 | ||
| Eingeschränkt | Region 1 | 100.72.0.0/18 | 100.72.64.0/18 | 100.72.128.0/18 | 100.72.192.0/18 | |
| Region 2 | 100.73.0.0/18 | 100.73.64.0/18 | 100.73.128.0/18 | 100.73.192.0/18 | ||
| Nicht zugewiesen | 100.{74-79}.0.0/18 | 100.{74-79}.64.0/18 | 100.{74-79}.128.0/18 | 100.{74-79}.192.0/18 |
Die obige Tabelle veranschaulicht diese Konzepte zum Zuweisen von IP-Adressbereichen:
- Die Zuweisung von IP-Adressen ist in Bereiche für jede Kombination aus freigegebener Basis-VPC, eingeschränkter freigegebener VPC, Region und Umgebung unterteilt.
- Einige Ressourcen sind global und erfordern keine Untergruppen für jede Region.
- Bei regionalen Ressourcen wird der Blueprint standardmäßig in zwei Regionen bereitgestellt. Darüber hinaus gibt es nicht verwendete IP-Adressbereiche, sodass Sie in sechs zusätzliche Regionen erweitern können.
- Das Hub-Netzwerk wird nur in der Hub-and-Spoke-Netzwerktopologie verwendet, während die Entwicklungs-, Nicht-Produktions- und Produktionsumgebungen in beiden Netzwerktopologien verwendet werden.
In der folgenden Tabelle wird erläutert, wie die einzelnen Arten von IP-Adressbereichen verwendet werden.
| Zweck | Beschreibung |
|---|---|
| Primäre Subnetzbereiche | Ressourcen, die Sie in Ihrem VPC-Netzwerk bereitstellen, z. B. VM-Instanzen, verwenden interne IP-Adressen aus diesen Bereichen. |
| Zugriff auf private Dienste | Bei einigen Google Cloud-Diensten wie Cloud SQL müssen Sie für den Zugriff auf private Dienste einen Subnetzbereich zuweisen. Der Blueprint reserviert global für jedes freigegebene VPC-Netzwerk einen /21-Bereich, um IP-Adressen für Dienste zuzuweisen, die Zugriff auf private Dienste erfordern. Wenn Sie einen Dienst erstellen, der vom Zugriff auf private Dienste abhängt, weisen Sie ein regionales /24-Subnetz aus dem reservierten /21-Bereich zu. |
| Private Service Connect | Der Blueprint stellt jedes VPC-Netzwerk mit einem Private Service Connect-Endpunkt für die Kommunikation mit Google Cloud APIs bereit. Mit diesem Endpunkt können Ihre Ressourcen im VPC-Netzwerk Google Cloud APIs erreichen, ohne ausgehenden Traffic zum Internet oder öffentlich beworbenen Internetbereichen zu benötigen. |
| Proxybasierte Load-Balancer | Bei einigen Arten von Anwendungs-Load-Balancern müssen Nur-Proxy-Subnetze vorab zugewiesen werden. Auch wenn der Blueprint keine Anwendungs-Load-Balancer bereitstellt, die diesen Bereich erfordern, hilft die Vorabzuweisung von Bereichen, Probleme zu vermeiden, wenn Arbeitslasten einen neuen Subnetzbereich anfordern müssen, um bestimmte Load-Balancer-Ressourcen zu aktivieren. |
| Sekundäre Subnetzbereiche | Einige Anwendungsfälle, z. B. containerbasierte Arbeitslasten, erfordern sekundäre Bereiche. Der Blueprint weist Bereiche aus dem RFC 6598-IP-Adressbereich für sekundäre Bereiche zu. |
Zentralisierte DNS-Einrichtung
Für die DNS-Auflösung zwischen Google Cloud und lokalen Umgebungen empfehlen wir einen hybriden Ansatz mit zwei autoritativen DNS-Systemen. Bei diesem Ansatz übernimmt Cloud DNS die autoritative DNS-Auflösung für Ihre Google Cloud-Umgebung und die vorhandenen lokalen DNS-Server übernehmen die autoritative DNS-Auflösung für lokale Ressourcen. Ihre lokale Umgebung und die Google Cloud-Umgebung führen DNS-Lookups zwischen Umgebungen über Weiterleitungsanfragen durch.
Das folgende Diagramm zeigt die DNS-Topologie für mehrere VPC-Netzwerke, die im Blueprint verwendet werden.
Das Diagramm beschreibt die folgenden Komponenten des DNS-Designs, die durch den Blueprint bereitgestellt werden:
- Das DNS-Hub-Projekt im gemeinsamen Ordner ist der zentrale Punkt des DNS-Austauschs zwischen der lokalen Umgebung und der Google Cloud-Umgebung. Die DNS-Weiterleitung verwendet dieselben Dedicated Interconnect-Instanzen und Cloud Router, die bereits in Ihrer Netzwerktopologie konfiguriert sind.
- In der Dual-freigegebenen VPC-Topologie verwendet der DNS-Hub das freigegebene VPC-Basisnetzwerk.
- In der Hub-and-Spoke-Topologie verwendet der DNS-Hub das freigegebene VPC-Netzwerk des Basis-Hubs.
- Server in jedem freigegebenen VPC-Netzwerk können DNS-Einträge aus anderen freigegebenen VPC-Netzwerken über die DNS-Weiterleitung auflösen, die zwischen Cloud DNS in jedem freigegebenen VPC-Hostprojekt und dem DNS-Hub konfiguriert ist.
- Lokale Server können DNS-Einträge in Google Cloud-Umgebungen mithilfe von DNS-Serverrichtlinien auflösen, die Abfragen von lokalen Servern zulassen. Der Blueprint konfiguriert eine Serverrichtlinie für eingehenden Traffic im DNS-Hub, um IP-Adressen zuzuweisen. Die lokalen DNS-Server leiten Anfragen an diese Adressen weiter. Alle DNS-Anfragen an Google Cloud erreichen zuerst den DNS-Hub, wodurch dann Einträge von DNS-Peers aufgelöst werden.
- Server in Google Cloud können DNS-Einträge in der lokalen Umgebung mithilfe von Weiterleitungszonen auflösen, die lokale Server abfragen. Alle DNS-Anfragen an die lokale Umgebung stammen vom DNS-Hub. Die DNS-Anfragequelle ist 35.199.192.0/19.
Firewallrichtlinien
Google Cloud verfügt über mehrere Firewallrichtlinientypen. Hierarchische Firewallrichtlinien werden auf Organisations- oder Ordnerebene erzwungen, um die Firewallrichtlinienregeln für alle Ressourcen in der Hierarchie konsistent zu übernehmen. Darüber hinaus können Sie Netzwerk-Firewallrichtlinien für jedes VPC-Netzwerk konfigurieren. Der Blueprint kombiniert diese Firewallrichtlinien, um gemeinsame Konfigurationen in allen Umgebungen mithilfe hierarchischer Firewallrichtlinien zu erzwingen und spezifischere Konfigurationen für jedes einzelne VPC-Netzwerk mithilfe von Netzwerkfirewallrichtlinien zu erzwingen.
Der Blueprint verwendet keine Legacy-VPC-Firewallregeln. Es wird empfohlen, nur Firewallrichtlinien zu verwenden und die Verwendung mit Legacy-VPC-Firewallregeln zu vermeiden.
Hierarchische Firewallrichtlinien
Der Blueprint definiert eine einzelne hierarchische Firewallrichtlinie und hängt die Richtlinie an jeden der Ordner für Produktion, Nicht-Produktion, Entwicklung, Bootstrap und allgemeine Ordner an. Diese hierarchische Firewallrichtlinie enthält die Regeln, die in allen Umgebungen allgemein erzwungen werden sollen. Sie delegiert die Auswertung detaillierterer Regeln an die Netzwerk-Firewallrichtlinie für jede einzelne Umgebung.
In der folgenden Tabelle werden die Regeln der hierarchischen Firewallrichtlinien beschrieben, die vom Blueprint bereitgestellt werden.
| Regelbeschreibung | Traffic-Richtung | Filter (IPv4-Bereich) | Protokolle und Ports | Aktion |
|---|---|---|---|---|
| Delegieren Sie die Auswertung des eingehenden Traffics von RFC 1918 an niedrigere Ebenen in der Hierarchie. | Ingress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| Delegieren Sie die Auswertung des ausgehenden Traffics an RFC 1918 an niedrigere Ebenen in der Hierarchie. | Egress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| IAP für die TCP-Weiterleitung | Ingress |
35.235.240.0/20 |
tcp:22,3390 |
Allow |
| Windows Server-Aktivierung | Egress |
35.190.247.13/32 |
tcp:1688 |
Allow |
| Systemdiagnosen für Cloud Load Balancing | Ingress |
130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22 |
tcp:80,443 |
Allow |
Netzwerk-Firewallrichtlinien
Der Blueprint konfiguriert für jedes Netzwerk eine Netzwerk-Firewallrichtlinie. Jede Netzwerk-Firewallrichtlinie beginnt mit einer Mindestanzahl von Regeln, die den Zugriff auf Google Cloud-Dienste zulassen und den ausgehenden Traffic an alle anderen IP-Adressen ablehnen.
Im Hub-and-Spoke-Modell enthalten die Netzwerk-Firewallrichtlinien zusätzliche Regeln, um die Kommunikation zwischen Spokes zu ermöglichen. Die Netzwerk-Firewallrichtlinie lässt ausgehenden Traffic von einem zum Hub oder einem anderen Spoke zu und lässt eingehenden Traffic von der NVA im Hub-Netzwerk zu.
In der folgenden Tabelle werden die Regeln in der globalen Netzwerk-Firewallrichtlinie beschrieben, die für jedes VPC-Netzwerk im Blueprint bereitgestellt werden.
| Regelbeschreibung | Traffic-Richtung | Filtern | Protokolle und Ports |
|---|---|---|---|
| Lassen Sie ausgehenden Traffic zu Google Cloud APIs zu. | Egress |
Der Private Service Connect-Endpunkt, der für jedes einzelne Netzwerk konfiguriert ist. Siehe Privater Zugriff auf Google APIs. | tcp:443 |
| Verweigern Sie ausgehenden Traffic, der nicht mit anderen Regeln übereinstimmt. | Egress |
Alle | all |
Ausgehenden Traffic von einem Spoke zu einem anderen Spoke zulassen (nur für Hub-and-Spoke-Modell). |
Egress |
Das Aggregat aller in der Hub-and-Spoke-Topologie verwendeten IP-Adressen. Traffic, der eine Spoke-VPC verlässt, wird zuerst an die NVA im Hub-Netzwerk weitergeleitet. | all |
Eingehenden Traffic von der NVA im Hub-Netzwerk zulassen (nur für Hub-and-Spoke-Modell). |
Ingress |
Traffic, der von den NVAs im Hub-Netzwerk stammt. | all |
Wenn Sie den Blueprint zum ersten Mal bereitstellen, kann eine VM-Instanz in einem VPC-Netzwerk mit Google Cloud-Diensten, aber nicht mit anderen Infrastrukturressourcen im selben VPC-Netzwerk kommunizieren. Damit VM-Instanzen kommunizieren können, müssen Sie der Netzwerk-Firewallrichtlinie und den Tags zusätzliche Regeln hinzufügen, die explizit die Kommunikation der VM-Instanzen ermöglichen. Tags werden VM-Instanzen hinzugefügt und der Traffic wird anhand dieser Tags ausgewertet. Tags haben außerdem IAM-Steuerelemente, mit denen Sie diese zentral definieren und ihre Verwendung an andere Teams delegieren können.
Das folgende Diagramm zeigt ein Beispiel für das Hinzufügen benutzerdefinierter Tags und Netzwerk-Firewallregeln, damit Arbeitslasten innerhalb eines VPC-Netzwerks kommunizieren können.
Das Diagramm veranschaulicht die folgenden Konzepte dieses Beispiels:
- Die Netzwerk-Firewallrichtlinie enthält Regel 1, die ausgehenden Traffic aus allen Quellen mit der Priorität 65530 ablehnt.
- Die Netzwerk-Firewallrichtlinie enthält Regel 2, die eingehenden Traffic von Instanzen mit dem Tag
service=frontendzu Instanzen mit dem Tagservice=backendmit der Priorität 999 zulässt. - Die Instanz-2-VM kann Traffic von instance-1 empfangen, da der Traffic mit den von Regel 2 zulässigen Tags übereinstimmt. Regel 2 wird abgeglichen, bevor Regel 1 auf Grundlage des Prioritätswerts ausgewertet wird.
- Die Instanz-3-VM empfängt keinen Traffic. Die einzige Firewallrichtlinienregel für diesen Traffic ist Regel 1, also wird ausgehender Traffic von instance-1 abgelehnt.
Privater Zugriff auf Google Cloud APIs
Damit Ressourcen in Ihren VPC-Netzwerken oder lokalen Umgebungen Google Cloud-Dienste erreichen können, empfehlen wir eine private Verbindung anstelle von ausgehendem Internettraffic zu öffentlichen API-Endpunkten. Der Blueprint konfiguriert den privaten Google-Zugriff in jedem Subnetz und erstellt interne Endpunkte mit Private Service Connect, um mit Google Cloud-Diensten zu kommunizieren. Wenn sie zusammen verwendet werden, ermöglichen diese Steuerelemente einen privaten Pfad zu Google Cloud-Diensten, ohne sich auf den ausgehenden Internet-Traffic oder öffentlich beworbene Internetbereiche zu verlassen.
Der Blueprint konfiguriert Private Service Connect-Endpunkte mit API-Bundles, um zu unterscheiden, auf welche Dienste in welchem Netzwerk zugegriffen werden kann. Das Basisnetzwerk verwendet das Bundle all-apis und kann jeden Google-Dienst erreichen, und das eingeschränkte Netzwerk verwendet das vpcsc-Bundle, das den Zugriff auf eine begrenzte Anzahl von Diensten ermöglicht, die VPC Service Controls unterstützen.
Für den Zugriff von Hosts, die sich in einer lokalen Umgebung befinden, empfehlen wir die Verwendung einer Konvention für benutzerdefinierten FQDN für jeden Endpunkt, wie in der folgenden Tabelle beschrieben. Der Blueprint verwendet für jedes VPC-Netzwerk einen eindeutigen Private Service Connect-Endpunkt, der für den Zugriff auf eine andere Gruppe von API-Bundles konfiguriert ist. Sie müssen daher berücksichtigen, wie Diensttraffic von der lokalen Umgebung mit dem richtigen API-Endpunkt an das VPC-Netzwerk weitergeleitet wird. Wenn Sie VPC Service Controls verwenden, müssen Sie dafür sorgen, dass der Traffic an die Google Cloud-Dienste den Endpunkt innerhalb des gewünschten Perimeters erreicht. Konfigurieren Sie Ihre lokalen Steuerelemente für DNS, Firewalls und Router, um den Zugriff auf diese Endpunkte zu ermöglichen, und konfigurieren Sie lokale Hosts für die Verwendung des entsprechenden Endpunkts. Weitere Informationen finden Sie unter Über Google-APIs auf Back-Ends zugreifen.
In der folgenden Tabelle werden die Private Service Connect-Endpunkte beschrieben, die für jedes Netzwerk erstellt werden.
| VPC | Umgebung | API-Bundle | IP-Adresse des Private Service Connect-Endpunkts | Benutzerdefinierter FQDN | ||||
|---|---|---|---|---|---|---|---|---|
| Basis | Allgemein | all-apis |
10.17.0.1/32 | c.private.googleapis.com |
||||
| Entwicklung | all-apis |
10.17.0.2/32 | d.private.googleapis.com |
|||||
| Nicht-Produktion | all-apis |
10.17.0.3/32 | n.private.googleapis.com |
|||||
| Produktion | all-apis |
10.17.0.4/32 | p.private.googleapis.com |
|||||
| Eingeschränkt | Allgemein | vpcsc |
10.17.0.5/32 | c.restricted.googleapis.com |
||||
| Entwicklung | vpcsc |
10.17.0.6/32 | d.restricted.googleapis.com |
|||||
| Nicht-Produktion | vpcsc |
10.17.0.7/32 | n.restricted.googleapis.com |
|||||
| Produktion | vpcsc |
10.17.0.8/32 | p.restricted.googleapis.com |
|||||
Damit Traffic für Google Cloud-Dienste einen DNS-Lookup zum richtigen Endpunkt hat, konfiguriert der Blueprint private DNS-Zonen für jedes VPC-Netzwerk. In der folgenden Tabelle werden diese privaten DNS-Zonen beschrieben.
| Name der privaten Zone | DNS-Name | Eintragtyp | Daten |
|---|---|---|---|
googleapis.com. |
*.googleapis.com. |
CNAME |
private.googleapis.com. (für Basisnetzwerke) oder restricted.googleapis.com. (für eingeschränkte Netzwerke) |
private.googleapis.com (für Basisnetzwerke) oder restricted.googleapis.com (für eingeschränkte Netzwerke) |
A |
Die IP-Adresse des Private Service Connect-Endpunkts für dieses VPC-Netzwerk. | |
gcr.io. |
*.gcr.io |
CNAME |
gcr.io. |
gcr.io |
A |
Die IP-Adresse des Private Service Connect-Endpunkts für dieses VPC-Netzwerk. | |
pkg.dev. |
*.pkg.dev. |
CNAME |
pkg.dev. |
pkg.dev. |
A |
Die IP-Adresse des Private Service Connect-Endpunkts für dieses VPC-Netzwerk. |
Der Blueprint hat zusätzliche Konfigurationen, um zu erzwingen, dass diese Private Service Connect-Endpunkte konsistent verwendet werden. Für jedes freigegebene VPC-Netzwerk wird außerdem Folgendes erzwungen:
- Eine Netzwerk-Firewallregel, die ausgehenden Traffic von allen Quellen an die IP-Adresse des Private Service Connect-Endpunkts auf TCP:443 zulässt.
- Eine Netzwerk-Firewallrichtlinienregel, die ausgehenden Traffic zu 0.0.0.0/0 ablehnt, einschließlich der Standarddomains, die für den Zugriff auf Google Cloud-Dienste verwendet werden.
Internetverbindung
Der Blueprint lässt keinen eingehenden oder ausgehenden Traffic zwischen seinen VPC-Netzwerken und dem Internet zu. Bei Arbeitslasten, die eine Internetverbindung erfordern, müssen Sie zusätzliche Schritte ausführen, um die erforderlichen Zugriffspfade zu entwerfen.
Für Arbeitslasten, die ausgehenden Traffic zum Internet benötigen, empfehlen wir, ausgehenden Traffic über Cloud NAT zu verwalten, um ausgehenden Traffic ohne unerwünschte eingehende Verbindungen zuzulassen, oder über Secure Web Proxy für eine genauere Kontrolle, um nur ausgehenden Traffic zu vertrauenswürdigen Webdiensten zuzulassen.
Für Arbeitslasten, die eingehenden Traffic aus dem Internet erfordern, empfehlen wir Ihnen, Ihre Arbeitslast mit Cloud Load Balancing und Google Cloud Armor zu entwerfen, um von DDoS- und WAF-Schutzmaßnahmen zu profitieren.
Es wird nicht empfohlen, Arbeitslasten zu entwerfen, die eine direkte Verbindung zwischen dem Internet und einer VM über eine externe IP-Adresse auf der VM ermöglichen.
Hybridkonnektivität zwischen einer lokalen Umgebung und Google Cloud
Zum Herstellen einer Verbindung zwischen der lokalen Umgebung und Google Cloud empfehlen wir die Verwendung von Dedicated Interconnect, um die Sicherheit und Zuverlässigkeit zu maximieren. Eine Dedicated Interconnect-Verbindung ist eine direkte Verbindung zwischen Ihrem lokalen Netzwerk und Google Cloud.
Im folgenden Diagramm wird die Hybridkonnektivität zwischen der lokalen Umgebung und einem Google Virtual Private Cloud-Netzwerk vorgestellt.
Im Diagramm werden die folgenden Komponenten des Musters für die Verfügbarkeit von 99,99% für Dedicated Interconnect beschrieben:
- Vier Dedicated Interconnect-Verbindungen mit zwei Verbindungen in einer Metropolregion (Metro) und zwei Verbindungen in einer anderen Metropolregion.
- Die Verbindungen werden in zwei Paare aufgeteilt, wobei jedes Paar mit einem separaten lokalen Rechenzentrum verbunden ist.
- VLAN-Anhänge werden verwendet, um jede Dedicated Interconnect-Instanz mit Cloud Routern zu verbinden, die der Topologie für freigegebene VPC zugeordnet sind. Diese VLAN-Anhänge werden im Projekt
prj-c-interconnectgehostet. - Jedes freigegebene VPC-Netzwerk hat vier Cloud Router, zwei in jeder Region, wobei der dynamische Routingmodus auf
globalgesetzt ist, sodass jeder Cloud Router alle Subnetze unabhängig von der Region ankündigen kann.
Cloud Router nutzen das globale dynamische Routing, um Routen für alle Subnetze im VPC-Netzwerk zu bewerben. Cloud Router bewerben Routen in Remote-Subnetzen (Subnetze außerhalb der Cloud Router-Region) im Vergleich zu lokalen Subnetzen (Subnetze, die sich in der Cloud Router-Region befinden) mit einer niedrigeren Priorität. Optional können Sie beworbene Präfixe und Prioritäten ändern, wenn Sie die BGP-Sitzung für einen Cloud Router konfigurieren.
Für den Traffic von Google Cloud zu einer lokalen Umgebung wird der Cloud Router verwendet, der den Cloud-Ressourcen am nächsten ist. Innerhalb einer einzelnen Region haben mehrere Routen zu lokalen Netzwerken denselben Multi-Exit-Diskriminator-Wert (MED) und Google Cloud verwendet Equal Cost Multi-Path (ECMP)-Routing, um ausgehenden Traffic zwischen allen möglichen Routen zu verteilen.
Lokale Konfigurationsänderungen
Sie müssen zusätzliche Änderungen in Ihrer lokalen Umgebung konfigurieren, um die Verbindungen zwischen der lokalen Umgebung und Google Cloud zu konfigurieren. Der Terraform-Code im Blueprint konfiguriert automatisch Google Cloud-Ressourcen, ändert jedoch keine Ihrer lokalen Netzwerkressourcen.
Einige der Komponenten für die Hybridkonnektivität von Ihrer lokalen Umgebung zu Google Cloud werden automatisch durch den Blueprint aktiviert, darunter:
- Cloud DNS wird mit der DNS-Weiterleitung zwischen allen freigegebenen VPC-Netzwerken an einen einzelnen Hub konfiguriert, wie unter DNS-Einrichtung beschrieben. Eine Cloud DNS-Serverrichtlinie wird mit IP-Adressen für eingehenden Traffic konfiguriert.
- Cloud Router ist so konfiguriert, dass Routen für alle Subnetze und benutzerdefinierte Routen für die von den Private Service Connect-Endpunkten verwendeten IP-Adressen exportiert werden.
Um Hybridkonnektivität zu aktivieren, müssen Sie die folgenden zusätzlichen Schritte ausführen:
- Dedicated Interconnect-Verbindung bestellen
- Konfigurieren Sie lokale Router und Firewalls, um ausgehenden Traffic zum internen IP-Adressbereich zuzulassen, der unter IP-Adressbereichszuweisung definiert ist.
- Konfigurieren Sie Ihre lokalen DNS-Server so, dass sie für Google Cloud gebundene DNS-Lookups an die Weiterleitungs-IP-Adressen für eingehenden Traffic weiterleiten, die bereits durch den Blueprint konfiguriert sind.
- Konfigurieren Sie Ihre lokalen DNS-Server, Firewalls und Router so, dass sie DNS-Abfragen von der Weiterleitungszone von Cloud DNS (35.199.192.0/19) akzeptieren.
- Konfigurieren Sie lokale DNS-Server so, dass sie auf Abfragen von lokalen Hosts an Google Cloud-Dienste mit den unter Privater Zugriff auf Cloud APIs definierten IP-Adressen antworten.
- Konfigurieren Sie für die Verschlüsselung während der Übertragung über die Dedicated Interconnect-Verbindung MACsec für Cloud Interconnect oder konfigurieren Sie HA VPN über Cloud Interconnect für die IPsec-Verschlüsselung.
Weitere Informationen finden Sie unter Privater Google-Zugriff für lokale Hosts.
Nächste Schritte
- Weitere Informationen zu Erkennungskontrollen (nächstes Dokument in dieser Reihe)