Ziele

• Machen Sie sich mit den Konzepten hinter einem VPC-basierten Hub-and-Spoke-Modell für die Verwaltung des gesamten VPC-zu-VPC-Datenverkehrs vertraut.
• Machen Sie sich mit VPC-Ingress-und Egress-Routing vertraut.
• Asymmetrische Routing-Probleme identifizieren und optional beheben.
• Machen Sie sich mit der Verwendung von Network Load Balancer für einen hoch verfügbaren und skalierbaren Firewall-Router vertraut.
• Verwenden Sie die Routing-und Weiterleitungsregeln für DNS-Services, um ein architektonisch solides Namensauflösungssystem zu erstellen.

Vorbereitende Schritte

Für dieses Lernprogramm ist Folgendes erforderlich:

• terraform zur Bereitstellung von Ressourcen mithilfe von IaC (Infrastructure as Code)
• python zum optionalen Ausführen der pytest-Befehle
• Wenn Sie einen Firewall-Router implementieren, müssen Sie IP-Spoofing-Prüfungen aktivieren.

In den Voraussetzungen finden Sie einige Optionen, einschließlich einer Dockerfile zum einfachen Erstellen der vorausgesetzten Umgebung.

Darüber hinaus:

• Überprüfen Sie die Benutzerberechtigungen. Stellen Sie sicher, dass Ihr Benutzerkonto über ausreichende Berechtigungen zum Erstellen und Verwalten aller Ressourcen in diesem Lernprogramm verfügt. Siehe die Liste von:
  • erforderliche Berechtigungen für VPC.
  • erforderliche Berechtigungen für die Erstellung von Transit Gateway
  • erforderliche Berechtigungen für IP-Spoofing-Prüfungen.
  • erforderliche Berechtigungen zum Verwalten von Berechtigungen.

Zusammenfassung von Teil 1

In Teil 1 dieses Lernprogramms haben wir den Adressraum der Transit-und Spoke-VPCs sorgfältig geplant. Die zonenbasierte Architektur wird nachfolgend dargestellt:

Dieses Diagramm zeigt den Datenfluss. Nur das Unternehmen <-> Spoke durchläuft die Firewall:

Dies wurde mit Direct Link, Transit Gateway und VPC-Routing erreicht. Alle Zonen sind ähnlich konfiguriert und das folgende Diagramm zeigt die Details von Zone 1:

CIDR 10.1.0.0/16 deckt den Transit und die Spokes ab und wird über Direct Link als beworbene Route an das Unternehmen übergeben. In ähnlicher Weise deckt die CIDR 192.168.0.0/24 das Unternehmen ab und wird über Transit Gateway als beworbene Route an die Spokes übergeben.

Egress-Routen in den Spokes leiten Datenverkehr an den Firewall-Router weiter. Ingress-Routen im Transit-Routenunternehmen <-> haben Datenverkehr über den Firewall-Router gesprochen.

Bereitstellung der ersten VPC-Ressourcen, die den gesamten VPC-internen Datenverkehr über den Firewall-Router weiterleiten

Häufig verwendet ein Unternehmen eine Transit-VPC, um den Datenverkehr mit dem Firewall-Router zu überwachen. In Teil 1 fließt nur der <-> Peripherietransportverkehr des Unternehmens durch den Transit-Firewall-Router. In diesem Abschnitt geht es um das Routing des gesamten VPC-an-VPC-Datenverkehrs über Firewall-Router.

Dieses Diagramm zeigt den in diesem Schritt implementierten Datenfluss:

Der gesamte Datenverkehr zwischen VPCs fließt durch den Firewall-Router:

• Unternehmen <->.
• Unternehmen <-> Transit.
• Transit <-> sprach.
• sprach <-> sprach in einer anderen VPC.

Datenverkehr innerhalb einer VPC fließt nicht durch die Firewall.

Wenn Sie ab Teil 1 fortfahren, notieren Sie sich die Konfiguration in terraform.tfvars: all_firewall = true.

Zonenübergreifendes Routing korrigieren

Wie bereits erwähnt, ist es für ein System für die Ausfallsicherheit bei Zonenausfällen am besten, den zonenübergreifenden Datenverkehr zu eliminieren. Wenn zonenübergreifende Unterstützung erforderlich ist, können zusätzliche Egress-Routen hinzugefügt werden. Das Problem für Datenverkehr von Peripherieserver 0 zu Peripherieserver 1 wird im folgenden Diagramm dargestellt:

Der grüne Pfad ist ein Beispiel für die Weiterleitung der Spoke 0-Zone 2 10.2.0.4 an die Spoke 1-Zone 1 10.1.1.4. Die entsprechende Egress-Route lautet:

Zone	Ziel	Nächster Hop
Dallas10.0.0.0/810.2.15.196

Links nach rechts wird der Firewall-Router in der mittleren Zone, Zone 2, des Diagramms ausgewählt. Im Rückkehrpfad ist Zone 1 ausgewählt.

Um dieses Problem zu beheben, müssen einige spezifischere Routen hinzugefügt werden, damit die Zonen mit höherer Anzahl an die Firewalls mit der niedrigeren Zonennummer weitergeleitet werden, wenn ein Ziel mit einer niedrigeren Zonennummer angegeben wird. Wenn Sie auf eine Zone mit gleicher oder höherer Nummerierung verweisen, wird die Weiterleitung an die Firewall in derselben Zone fortgesetzt.

Routen in der Standard-Egress-Routing-Tabelle der einzelnen Spokes (dargestellt für Dallas/us-south):

Zone	Ziel	Nächster Hop
Dallas10.1.0.0/1610.1.15.196
Dallas10.1.0.0/1610.1.15.196
Dallas10.2.0.0/1610.2.15.196

Diese Routen werden auch ein ähnliches Problem beim asymmetrischen Routing von Peripherietransportzonen beheben. < -- > Betrachten Sie den Transit-Worker 10.1.15.4-> Spoke-Worker 10.2.0.4. Der Datenverkehr vom Transitworker in Zone 1 wählt den Firewall-Router in Zone 1 aus (dieselbe Zone). Bei der Rückfahrt anstelle des Firewall-Routers in Zone 2 (gleiche Zone) wird nun der Firewall-Router in Zone 1 verwendet.

1. Wenden Sie die Ebene 'all_firewall_asym' an:

   ./apply.sh all_firewall_asym_tf
   

2. Führen Sie die Testsuite aus.

   Ihre erwarteten Ergebnisse sind: alle Tests BESTANDEN, führen Sie sie parallel aus (-n 10):

   pytest -n 10 -m curl
   

Der gesamte Datenverkehr zwischen VPCs wird jetzt über die Firewall-Router weitergeleitet.

High Performance High Availability Firewall (HA)-Router

Um zu verhindern, dass ein Firewall-Router zum Leistungsengpass oder zu einem Single Point of Failure wird, ist es möglich, eine VPC-Netzlastausgleichsfunktion hinzuzufügen, um Datenverkehr an die zonalen Firewall-Router zu verteilen, um einen hoch verfügbaren HA-Firewall-Router zu erstellen. Überprüfen Sie anhand der Dokumentation zum Firewall-Router, ob diese Architektur unterstützt wird.

Dieses Diagramm zeigt eine einzelne Zone mit einer Netzlastausgleichsfunktion (NLB), die im Routenmodus vor zwei Firewall-Routern konfiguriert ist. Um dies zu sehen, ist es erforderlich, die Konfiguration zu ändern und erneut anzuwenden.

1. Ändern Sie diese beiden Variablen in config_tf/terraform.tfvars:

   firewall_nlb                 = true
   number_of_firewalls_per_zone = 2
   

   Diese Änderung führt dazu, dass die IP-Adresse des Firewall-Routers von der früher verwendeten Firewall-Router-Instanz in die IP-Adresse der NLB geändert wird. Die Änderung der IP-Adresse muss auf eine Reihe von VPC-Routentabellenrouten in den Transit-und Spoke-VPCs angewendet werden. Es empfiehlt sich, alle zuvor aufgebrachten Schichten anzuwenden:

2. Wenden Sie alle Ebenen über die Ebene all_firewall_asym_tf an:

   ./apply.sh : all_firewall_asym_tf
   

Beobachten Sie die vorgenommenen Änderungen:

1. Öffnen Sie die Lastausgleichsfunktionen für VPC.
2. Wählen Sie den Load Balancer in Zone 1 (Dallas 1/us-south-1) mit dem Suffix fw-z1-s3.
3. Beachten Sie die privaten IPs.

Vergleichen Sie die privaten IPs mit denen in der Transit-VPC-Ingress-Routentabelle:

1. Öffnen Sie Virtual Private Clouds.
2. Wählen Sie die Transit-VPC aus.
3. Klicken Sie auf Routing-Tabellen verwalten.
4. Klicken Sie auf die Routing-Tabelle tgw-ingress. Beachten Sie, dass die IP-Adresse Nächster Hop mit einer der privaten IP-Adressen der NLB übereinstimmt.

Überprüfen Sie die Ausfallsicherheit:

1. Führen Sie die Tests für Spoke 0 Zone 1 aus:

   pytest -k r-spoke0-z1 -m curl
   

2. Öffnen Sie die Virtual Server-Instanzen für VPC.
3. Stoppen Sie den Datenverkehr zur 0-Firewallinstanz, indem Sie eine Sicherheitsgruppe angeben, die Port 80 für eingehende Daten nicht zulässt. Suchen Sie die Instanz mit dem Suffix fw-z1-s3-0 und öffnen Sie die Detailansicht:
   1. Blättern Sie abwärts und klicken Sie auf das Stiftsymbol neben der Netzschnittstelle.
   2. X-fw-inall-outall abwählen
   3. Überprüfen Sie x-fw-in22-outall.
   4. Klicken Sie auf Speichern.
4. Führen Sie den Pytest erneut aus. Dies weist auf Fehler hin. Es dauert einige Minuten, bis die NLB die Weiterleitung des Datenverkehrs an die nicht antwortende Instanz stoppt. An diesem Punkt werden alle Tests bestanden. Warten Sie weiter und führen Sie pytest aus, bis alle Tests erfolgreich sind.

Die NLB-Firewall ist nicht mehr erforderlich. Entfernen Sie die NLB-Firewall:

1. Ändern Sie diese beiden Variablen in config_tf/terraform.tfvars:

   firewall_nlb                 = false
   number_of_firewalls_per_zone = 1
   

2. Wenden Sie alle Ebenen über die Ebene all_firewall_asym_tf an:

   ./apply.sh : all_firewall_asym_tf
   

Hinweis zur im Routing-Modus konfigurierten NLB

Im NLB-Routenmodus werden Routentabelleneinträge neu geschrieben. Die aktive IP-Adresse der NLB-Appliance bleibt während einer Übernahme immer in der Routentabelle. Dies erfolgt jedoch nur für Routen in der Transit-VPC, die die NLB enthält. Der Spoke hat Egress-Routen, die mit einer der NLB-Appliance-IPs initialisiert wurden. Der nächste Spoke-Hop wird bei der Übernahme der NLB-Appliance nicht aktualisiert!

Es ist erforderlich, eine Ingress-Route in der Transit-VPC zu verwalten, die von der NLB neu geschrieben wird, um die aktive Appliance wiederzugeben. Die Spoke-Egress-Route übermittelt Pakete an die richtige Zone der Transit-VPC. Beim Routing innerhalb der Transit-VPC-Zone wird die übereinstimmende Ingress-Regel gefunden, die die aktive Appliance enthält.

Im Folgenden wird die weiter oben beschriebene Transit-VPC-Ingress-Routentabelle erläutert. Der nächste Hop wird mit der aktiven NLB-Appliance auf dem aktuellen Stand gehalten. Beachten Sie, dass Dallas 3 eine Änderung aufweist, die vom NLB-Routenmodusdienst geschrieben wurde, um die aktive Appliance widerzuspiegeln.

Die NLB erfordert die Erstellung einer IAM-Berechtigung, die es der NLB ermöglicht, in die VPC zu schreiben. Diese Berechtigung wurde vom Script apply.sh erstellt. Weitere Informationen zur Konfiguration, die vom Script ausgeführt wurde, finden Sie unter Netzlastausgleichsfunktion mit Routing-Modus erstellen.

Der NLB-Pool im Routenmodus muss mit dem Wert null für Sitzungspersistenztyp konfiguriert werden.

DNS

Der Service IBM Cloud DNS Services wird verwendet, um Namen in IP-Adressen zu konvertieren. In diesem Beispiel wird ein DNS-Dienst in der Cloud erstellt. Die DNS-Zone cloud.example.com wird erstellt und die Transit-VPC wird als zulässiges Netz hinzugefügt. DNS-Datensätze für die Cloudinstanzen werden cloud.example.comhinzugefügt. Beispiel: Ein Datensatz wird für den Worker Spoke 0 in Zone 1 erstellt, der den vollständigen Namen spoke0-z1-workerhätte.cloud.example.com.

Lesen Sie Informationen zur DNS-Freigabe für VPE-Gateways. Die Transit-VPC wird als DNS-Hub aktiviert. Jede Spoke-VPC ist mit einer DNS-Auflösungsbindung an den Transit-VPC-Hub konfiguriert. Dadurch werden die Spoke-VPC-DHCP-Einstellungen für DNS-Server als angepasste Transit-VPC-Auflöser konfiguriert.

./apply.sh dns_tf

pytest -n 10 -m dns

Virtual Private Endpoint-Gateways

VPC ermöglicht privaten Zugriff auf IBM Cloud Services über Virtual Private Endpoint (VPE) for VPC. Die VPE-Gateways ermöglichen eine differenzierte Netzzugriffssteuerung über IBM Cloud VPC-Standardsteuerelemente:

• Security Groups.
• VPC-Netzzugriffssteuerungslisten
• Routing-Tabellen und -Routen.

Für jedes VPC-VPE-Gateway wird eine DNS-Zone erstellt. Die DNS-Zone wird dem privaten DNS-Service, der der VPC zugeordnet ist, automatisch hinzugefügt. Jede Spoke-VPC verfügt über eine DNS-Konfiguration bound zur Transit-VPC. Dadurch kann die Spoke-VPE-DNS-Zone für die Transit-VPC gemeinsam genutzt werden.

1. Erstellen Sie eine IBM Cloud Databases for PostgreSQL-Instanz und VPEs für den Transit und jede der Spoke-VPCs, indem Sie die Ebenen 'vpe_transit_tf' und 'vpe_spokes_tf ' anwenden:

   ./apply.sh vpe_transit_tf vpe_spokes_tf
   

2. Es gibt eine Reihe von vpe-und vpedns-Tests, die im pytest-Script verfügbar sind. Der Test vpedns prüft, ob der DNS-Name einer Databases for PostgreSQL-Instanz im privaten CIDR-Block der übergeordneten VPC enthalten ist. Der Test vpe führt einen psql-Befehl aus, um über Fernzugriff auf die Databases for PostgreSQL-Instanz zuzugreifen. vpe und vpedns aus Spoke 0 Zone 1 testen:

   • Erwartete Ergebnisse für alle Tests

   pytest -m 'vpe or vpedns' -k spoke0-z1
   

Alle Tests in diesem Lernprogramm sollten jetzt bestanden werden. Es gibt einige. Führen Sie sie parallel aus:

pytest -n 10

Produktionshinweise und Schlussfolgerungen

Die VPC-Referenzarchitektur für IBM Cloud for Financial Services enthält viel mehr Details zum Schützen von Workloads in IBM Cloud.

Einige offensichtliche Änderungen müssen vorgenommen werden:

• CIDR-Blöcke wurden aus Gründen der Übersichtlichkeit und Einfachheit ausgewählt. Die Verfügbarkeitszonen in der Region mit mehreren Zonen könnten 10.1.0.0/10, 10.64.0.0/10oder 10.128.0.0/10 sein, um den Adressraum zu sparen. Ebenso könnte der Adressraum für Workerknoten auf Kosten von Firewall, DNS und VPE erweitert werden.
• Sicherheitsgruppen für jede der Netzschnittstellen für Worker-VSIs, Virtual Private Endpoint Gateways, DNS-Positionen und Firewalls sollten sorgfältig berücksichtigt werden.
• Die Netzzugriffssteuerungslisten für jedes Teilnetz sollten sorgfältig berücksichtigt werden.
• Variable IP-Adressen wurden allen Testinstanzen zugeordnet, um Konnektivitätstests über SSH zu unterstützen. Dies ist in der Produktion weder erforderlich noch wünschenswert.
• Implementieren Sie kontextbasierte Einschränkungen, um den Zugriff auf alle Ressourcen weiter zu steuern.

In diesem Lernprogramm haben Sie eine Hub-VPC und eine Gruppe von Spoke-VPCs erstellt. Sie haben den gesamten VPC-übergreifenden Datenverkehr über einen Transit-VPC-Firewall-Router weitergeleitet. Für den Transit-VPC-Hub wurde ein DNS-Service erstellt und jede Spoke-VPC wurde an die Transit-VPC gebunden.

Ressourcen entfernen

Führen Sie terraform destroy in allen Verzeichnissen in umgekehrter Reihenfolge mit dem Befehl ./apply.sh aus:

./apply.sh -d : :

Lernprogramm erweitern

Ihre Architektur ist möglicherweise nicht mit der dargestellten Architektur identisch, wird aber wahrscheinlich aus den hier beschriebenen grundlegenden Komponenten aufgebaut sein. Ideen zum Erweitern dieses Lernprogramms:

• Integrieren Sie eingehenden öffentlichen Internetzugang mithilfe von IBM Cloud® Internet Services.
• Flow Logs for VPC-Erfassung beim Transit hinzufügen.
• Stellen Sie jede der Spokes in ein separates Konto in einem Unternehmen.
• Erzwingen Sie einen Teil des Spoke-to-Spoke-Datenverkehrs durch die Firewall und einen Teil nicht durch die Firewall.
• Ersetzen Sie die Worker-VSIs durch Red Hat OpenShift on IBM Cloud und die VPC-Lastausgleichsfunktion.
• Erzwingen Sie den gesamten abgehenden Datenverkehr über die Firewall in der Transit-VPC und über öffentliche Gateways.

Zugehörige Inhalte

• IBM Cloud for Financial Services
• Implementierung isolierter Workloads über mehrere Standorte und Regionen hinweg
• Öffentliches Front-End und privates Back-End in einer virtuellen privaten Cloud,
• Virtualisierung von Netzfunktionen
• Privater Hub und Spoke mit transparentem VNF und Spoke-to-Spoke-Datenverkehr