Hub-and-Spoke-Netzwerktopologie mit lokalen Peering-Gateways einrichten

Ein Hub-and-Spoke-Netzwerk, auch Star-Netzwerk genannt, verfügt über eine zentrale Komponente, die mit mehreren Netzwerken verbunden ist. Die gesamte Topologie ähnelt einem Rad, wobei eine zentrale Nabe über mehrere Speichen mit Punkten entlang der Radkante verbunden ist. Die Einrichtung dieser Topologie im herkömmlichen On-Premises-Data-Center kann teuer sein. Aber in der Cloud gibt es keine zusätzlichen Kosten.

Verwenden Sie die Hub-and-Spoke-Architektur, um kreative und leistungsstarke Netzwerklösungen in der Cloud für die folgenden gängigen Anwendungsfälle zu erstellen:

  • Einrichtung separater Entwicklungs- und Produktionsumgebungen.

  • Isolieren der Workloads verschiedener Kunden, wie z. B. der Abonnenten eines unabhängigen Softwareanbieters (ISV) oder der Kunden eines Managed Service Providers.

  • Trennung von Umgebungen, um Compliance-Anforderungen zu erfüllen, wie z. B. die Anforderungen der Zahlungskartenindustrie (PCI) und des Health Insurance Portability and Accountability Act (HIPAA).

  • Bereitstellung von Shared Information Technology Services wie Log Server, Domain Name System (DNS) und File Sharing über ein zentrales Netzwerk.

Architektur

Diese Referenzarchitektur zeigt eine Oracle Cloud Infrastructure-Region mit einem virtuellen Hub-Cloud-Netzwerk (VCN), das mit zwei Spoke-VCNs verbunden ist. Jedes Spoke-VCN wird per Peering mit dem Hub-VCN verbunden, indem ein Paar lokaler Peering-Gateways (LPGs) verwendet wird.

Die Architektur zeigt einige Beispielsubnetze und virtuelle Maschinen (VMs). Mit Sicherheitslisten wird der Netzwerktraffic zu und von jedem Subnetz gesteuert. Jedes Subnetz verfügt über eine Routentabelle, die Regeln zum direkten Traffic enthält, der für Ziele außerhalb des VCN gebunden ist.

Das Hub-VCN verfügt über ein Internetgateway für Netzwerktraffic zum und vom öffentlichen Internet. Darüber hinaus verfügt es über ein dynamisches Routinggateway (DRG), um private Konnektivität mit Ihrem On-Premise-Netzwerk zu ermöglichen. Dieses können Sie mit Oracle Cloud Infrastructure FastConnect, Site-to-Site-VPN oder beidem implementieren.

Sie können entweder Oracle Cloud Infrastructure Bastion oder einen Bastionhost verwenden, um sicheren Zugriff auf Ihre Ressourcen zu ermöglichen. Diese Architektur verwendet OCI-Bastion.

Das folgende Diagramm veranschaulicht die Referenzarchitektur.


Beschreibung von hub-spoke-oci.png folgt
Beschreibung der Abbildung hub-spoke-oci.png

hub-and-spoke-oci.zip

Die Architektur umfasst folgende Komponenten:
  • On-Premise-Netzwerk

    Dieses Netzwerk ist das lokale Netzwerk, das von Ihrer Organisation verwendet wird. Es ist einer der Sprecher der Topologie.

  • OCI-region

    Eine OCI-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Centre enthält, das Availability-Domains hostet. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können über Länder oder Kontinente voneinander getrennt werden.

  • Virtuelles OCI-Cloud-Netzwerk und Subnetz

    Ein virtuelles Cloud-Netzwerk (VCN) ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer OCI-Region einrichten. Wie herkömmliche Data Center-Netzwerke erhalten Sie über VCNs die Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.

  • Sicherheitsliste

    Sie können für jedes Subnetz Sicherheitsregeln erstellen, die Quelle, Ziel und Typ des Traffics angeben, der im Subnetz und außerhalb des Subnetzes zulässig ist.

  • Routentabelle

    Virtuelle Routentabellen enthalten Regeln zum Weiterleiten von Traffic von Subnetzen zu Zielen außerhalb eines VCN, in der Regel über Gateways.

  • Dynamisches Routinggateway (DRG)

    Das DRG ist ein virtueller Router, der einen Pfad für den privaten Netzwerktraffic zwischen VCNs in derselben Region zwischen einem VCN und einem Netzwerk außerhalb der Region bereitstellt, z.B. ein VCN in einer anderen OCI-Region, ein On-Premise-Netzwerk oder ein Netzwerk in einem anderen Cloud-Provider.

  • OCI Bastion

    Oracle Cloud Infrastructure Bastion bietet eingeschränkten und zeitlich begrenzten sicheren Zugriff auf Ressourcen, die keine öffentlichen Endpunkte haben und strenge Ressourcenzugriffskontrollen erfordern, wie Bare-Metal- und virtuelle Maschinen, Oracle MySQL Database Service, Autonomous Transaction Processing (ATP), Oracle Cloud Infrastructure Kubernetes Engine (OKE) und alle anderen Ressourcen, die den Secure Shell-Protokoll-(SSH-)Zugriff ermöglichen. Mit dem OCI Bastion-Service können Sie den Zugriff auf private Hosts aktivieren, ohne einen Jump-Host bereitzustellen und zu verwalten. Darüber hinaus erhalten Sie einen verbesserten Sicherheitsstatus mit identitätsbasierten Berechtigungen und einer zentralisierten, auditierten und zeitgebundenen SSH-Session. Mit OCI Bastion ist keine öffentliche IP für den Bastionzugriff erforderlich, sodass der Aufwand und die potenzielle Angriffsfläche bei der Bereitstellung von Remotezugriff entfallen.

  • Bastionhost

    Der Bastionhost ist eine Compute-Instanz, die als sicherer, kontrollierter Einstiegspunkt in die Topologie von außerhalb der Cloud dient. Der Bastionhost wird in der Regel in einer demilitarisierten Zone (DMZ) bereitgestellt. Damit können Sie sensible Ressourcen schützen, indem Sie sie in privaten Netzwerken platzieren, auf die nicht direkt von außerhalb der Cloud zugegriffen werden kann. Die Topologie verfügt über einen einzigen bekannten Einstiegspunkt, den Sie regelmäßig überwachen und auditieren können. So können Sie vermeiden, die sensibleren Komponenten der Topologie freizulegen, ohne den Zugriff darauf zu beeinträchtigen.

  • Lokale Peering-Gruppe (LPG)

    Ein LPG stellt Peering zwischen VCNs in derselben Region bereit. Peering bedeutet, dass die VCNs über private IP-Adressen kommunizieren, ohne das der Traffic über das Internet oder über das On-Premise-Netzwerk geleitet werden.

  • OCI Site-to-Site-VPN

    OCI Site-to-Site-VPN bietet IPSec-VPN-Konnektivität zwischen Ihrem On-Premise-Netzwerk und VCNs auf OCI. Die IPSec-Protokollsuite verschlüsselt den IP-Traffic, bevor diese Pakete von der Quelle an das Ziel übertragen werden, und entschlüsselt den Traffic, wenn er ankommt.

  • OCI FastConnect

    Oracle Cloud Infrastructure FastConnect erstellt eine dedizierte, private Verbindung zwischen Ihrem Data Center und OCI. FastConnect bietet Optionen höherer Bandbreite und ein zuverlässigeres Netzwerk als bei internetbasierten Verbindungen.

Empfehlungen

Ihre Anforderungen können von der hier beschriebenen Architektur abweichen. Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt.

  • VCNs

    Wenn Sie ein VCN erstellen, bestimmen Sie die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen, die Sie an Subnetze im VCN anhängen möchten. Verwenden Sie CIDR-Blöcke, die sich innerhalb des standardmäßigen privaten IP-Adressraums befinden.

    Wählen Sie CIDR-Blöcke aus, die sich mit keinem anderen Netzwerk (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider) überschneiden, zu dem Sie private Verbindungen einrichten möchten.

    Nachdem Sie ein VCN erstellt haben, können Sie die zugehörigen CIDR-Blöcke ändern, hinzufügen und entfernen.

    Berücksichtigen Sie beim Entwerfen der Subnetze den Verkehrsfluss und die Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Tier oder Rolle an dasselbe Subnetz an, das als Sicherheitsgrenze dienen kann.

    Verwenden Sie regionale Subnetze.

  • Sicherheitslisten

    Mit Sicherheitslisten können Sie Ingress- und Egress-Regeln definieren, die für das gesamte Subnetz gelten.

Hinweise

Wenn Sie eine Hub-and-Spoke-Netzwerktopologie in der Cloud entwerfen, berücksichtigen Sie die folgenden Faktoren:

  • Kostenfaktor

    Die einzigen Komponenten dieser Architektur, die Kosten verursachen, sind die Compute-Instanzen und FastConnect (Portstunden und Providergebühren). Den anderen Komponenten sind keine Kosten zugeordnet.

  • Sicherheit

    Schützen Sie die Topologie mit geeigneten Sicherheitsverfahren.

    Die Topologie, die Sie mit dem bereitgestellten Terraform-Code bereitstellen, enthält die folgenden Sicherheitseigenschaften:
    • Die Standardsicherheitsliste des Hub-VCN lässt SSH-Traffic von 0.0.0.0/0 zu. Passen Sie die Sicherheitsliste an, um nur die Hosts und Netzwerke zuzulassen, die SSH-Zugriff (oder andere Serviceports) auf Ihre Infrastruktur haben sollen.
    • Bei diesem Deployment werden alle Komponenten in demselben Compartment platziert.
    • Auf Spoke-VCNs kann nicht über das Internet zugegriffen werden.
  • Skalierbarkeit

    Beachten Sie die Servicelimits für VCNs und Subnetze für Ihren Mandanten. Wenn mehr Netzwerke benötigt werden, fordern Sie eine Erhöhung der Limits an.

  • Performance

    Innerhalb einer Region wirkt sich die Anzahl der VCNs nicht auf die Performance aus. Wenn Sie Peer-VCNs in verschiedenen Regionen verwenden, sollten Sie die Latenz berücksichtigen. Wenn Sie Sprecher verwenden, die über OCI Site-to-Site-VPN oder OCI FastConnect verbunden sind, ist der Durchsatz der Verbindung ein zusätzlicher Faktor.

  • Verfügbarkeit und Redundanz

    Mit Ausnahme der Instances haben die verbleibenden Komponenten keine Redundanzanforderungen.

    Die OCI Site-to-Site-VPN- und OCI FastConnect-Komponenten sind redundant. Zur weiteren Redundanz mehrere Verbindungen verwenden, vorzugsweise von verschiedenen Anbietern.

Stellen Sie

Der Terraform-Code für diese Referenzarchitektur ist unter GitHub verfügbar. Sie können den Code mit einem einzigen Klick in Oracle Cloud Infrastructure Resource Manager abrufen, den Stack erstellen und bereitstellen. Alternativ können Sie den Code von GitHub auf Ihren Computer herunterladen, den Code anpassen und die Architektur mit der Terraform-CLI bereitstellen.

Hinweis:

Der Terraform-Code enthält die meisten im Architekturdiagramm gezeigten Komponenten, einschließlich einer VM für Bastionhost. Die Service-VM, die Workload-VM, das OCI Site-to-Site-VPN, OCI FastConnect und die OCI Bastion sind nicht im Code enthalten, obwohl sie im Diagramm dargestellt sind.
  • Mit Oracle Cloud Infrastructure Resource Manager bereitstellen:
    1. Klicken Sie auf .In Oracle Cloud bereitstellen

      Wenn Sie noch nicht angemeldet sind, geben Sie den Mandanten und die Benutzerzugangsdaten ein.

    2. Überprüfen Sie die Geschäftsbedingungen und akzeptieren sie.
    3. Wählen Sie die Region aus, in der Sie den Stack bereitstellen möchten.
    4. Befolgen Sie die Anweisungen auf dem Bildschirm, um den Stack zu erstellen.
    5. Klicken Sie nach dem Erstellen des Stacks auf Terraform-Aktionen, und wählen Sie Planen aus.
    6. Warten Sie, bis der Job abgeschlossen ist, und prüfen Sie den Plan.

      Um Änderungen vorzunehmen, kehren Sie zur Seite "Stackdetails" zurück, klicken Sie auf Stack bearbeiten, und nehmen Sie die erforderlichen Änderungen vor. Führen Sie dann die Aktion Planen erneut aus.

    7. Wenn keine weiteren Änderungen erforderlich sind, kehren Sie zur Seite "Stackdetails" zurück, klicken Sie auf Terraform-Aktionen, und wählen Sie Anwenden aus.
  • Mit der Terraform-CLI bereitstellen:
    1. Gehen Sie zu GitHub.
    2. Klonen Sie das Repository, oder laden Sie es auf Ihren lokalen Computer herunter.
    3. Befolgen Sie die Anweisungen im Dokument README.

Mehr erfahren

Erfahren Sie mehr über diese Architektur und verwandte Architekturen:

Änderungslog

In diesem Log werden nur die wesentlichen Änderungen aufgeführt: