1. Palo Alto-Firewall im aktiven/aktiven Modus mit OCI Flexible Network Load Balancer bereitstellen
  2. Erfahren Sie mehr über das Deployment der Palo Alto-Firewall im aktiven/aktiven Modus mit OCI Flexible Network Load Balancer

Erfahren Sie mehr über das Deployment der Palo Alto-Firewall im aktiven/aktiven Modus mit OCI Flexible Network Load Balancer

Dieses Dokument enthält eine Anleitung zum Bereitstellen von Firewalls der Palo Alto VM-Serie im aktiven/aktiven Modus in Oracle Cloud Infrastructure (OCI).

Obwohl Palo Alto die Active/Active High Availability-(HA-)Funktionalität nativ in On-Premise-Data Centern unterstützt, ist dies in Public Cloud-Umgebungen nicht möglich. In OCI wurde jedoch ein Workaround für dieses Deployment mit einer bahnbrechenden Funktion namens symmetrischem Hashing im OCI Flexible Network Load Balancer ermöglicht.

In diesem Deployment-Modell fungiert die Palo Alto-Firewall als Passthrough-Gerät, d.h. sie erfordert keine Network Address Translation (NAT) oder öffentliche IP-Adressen. Die öffentliche IP-Adresse wird stattdessen mit dem eigentlichen DMZ-Server oder den Load Balancern verknüpft. Dadurch sind auch bei Erreichen der maximalen Anzahl sekundärer IPs keine zusätzlichen NICs erforderlich. Diese Funktionalität wird durch die Option aktiviert, Routentabellen an das NAT-Gateway, das Internetgateway und Servicegateways in OCI anzuhängen.

Vorteile:

  1. Erhöhter Durchsatz: Beide Firewalls sind aktiv, was zu einem höheren Durchsatz führt.
  2. Nahtlose Skalierung: Neue Firewalls können bereitgestellt werden, ohne den vorhandenen Traffic zu unterbrechen, und sie können dem Backend der Network Load Balancer hinzugefügt werden.
  3. Reduzierte Failover-Zeit: Failover ist schneller, da keine API-Aufrufe erforderlich sind, um die IP-Adresse vom primären auf das sekundäre Gerät zu verschieben.
  4. Keine OCI Identity and Access Management-Policy-Konfiguration: Die OCI Identity and Access Management-Policy-Konfiguration ist nicht erforderlich, damit die Palo Alto-Firewall das VCN lesen und das Verschieben von NICs verwalten kann.
  5. Keine zusätzlichen NICs erforderlich: Wenn die Anzahl der öffentlichen IPs 64 überschreitet, sind keine zusätzlichen NICs erforderlich, da der Firewall keine öffentlichen IPs zugeordnet sind. Die Größe des DMZ-Subnetzes bestimmt die maximale Anzahl von Services oder Anwendungen, die im Internet verfügbar gemacht werden können.
  6. Kosteneinsparungen: Die Lizenzierungs- und VM-Betriebskosten werden gesenkt, da für dieses Modell keine zusätzlichen NICs erforderlich sind.

Bevor Sie beginnen

Um dieses Deployment-Modell besser zu verstehen, finden Sie in den folgenden Links Informationen zur symmetrischen Hashing-Funktionalität von OCI Flexible Network Load Balancer und Palo Alto-Deployment in OCI.

Architektur

Das folgende Diagramm zeigt die allgemeine Architektur, die zum Testen des Palo Alto Active/Active-Setups in OCI verwendet wird.

Dies ist ein typisches Hub-Spoke-Architektur-Deployment in OCI, bei dem die Active/Active Palo Alto-Firewall mit vier NICs im Hub-VCN bereitgestellt wird. Außerdem wird ein öffentliches Subnetz für DMZ im Hub-VCN hinzugefügt. Die Spoke-VCNs werden an das DRG angehängt, um alle Nord-Süd-, Ost-West-Firewalls über die Palo Alto-Firewalls zu leiten. Das aktive/aktive Setup wird erreicht, indem die Palo Alto-VMs als Backend von Inbound- und Trust-NLBs hinzugefügt werden.

In diesem Abschnitt werden wir tief in die Verkehrsführung und -flüsse in dieser Referenzarchitektur eintauchen. Der Begriff "tok" in den Namen der Ressourcen bezieht sich auf die Region Tokio, in der dieses Referenzarchitekturmodell bereitgestellt und getestet wurde.


Beschreibung von oci-nlb-palo-alto-active-active-arch.png folgt
Beschreibung der Abbildung oci-nlb-palo-alto-active-active-arch.png

oci-nlb-palo-alto-active-active-arch-oracle.zip

Eingehender Internetverkehr von Nord-Süd zu OCI:

Das folgende Diagramm zeigt den Fluss von DMZ-Webdiensten, die dem Internet ausgesetzt sind. Der Anwendungs-Load Balancer befindet sich in einem öffentlichen Subnetz, und die Backend-Server befinden sich in privaten Subnetzen des Spoke-VCN. Der detaillierte Ablauf auf jedem Hop wird in den folgenden Schritten beschrieben.


Beschreibung von oci-nlb-palo-alto-active-active-dmz.png folgt
Beschreibung der Abbildung oci-nlb-palo-alto-active-active-dmz.png

oci-nlb-palo-alto-active-active-dmz-oracle.zip

  1. Der Traffic vom Clientrechner im Internet wird an das Internetgateway (IGW) weitergeleitet.
  2. IGW referenziert die Routentabelle des Internetgateways zum Subnetz "hub-tok-publiclb-sn" und leitet den Traffic an die eingehende NLB-IP 10.1.1.198 weiter.
  3. Der eingehende NLB verteilt den Datenverkehr mit dem symmetrischen Hashing-Algorithmus auf eines der PA-Geräte im Backend.
  4. Firewall validiert die Policy und leitet den Datenverkehr von seiner eingehenden Schnittstelle auf dem virtuellen Router "inbound-rtr" an den Anwendungs-Load Balancer mit der öffentlichen IP weiter.

    Hinweis:

    Die Firewallsicherheits-Policy wird in die private IP (10.1.1.112) des öffentlichen Load Balancers geschrieben.
  5. OCI Flexible Network Load Balancer führt die Quellnetzwerkadressübersetzung (SNAT) für den Traffic aus und leitet ihn an das dynamische Routinggateway (DRG) weiter, das sich auf die Subnetzroutentabelle bezieht.
  6. DRG, das sich auf die Routentabelle des Hub-VCN-Anhangs bezieht, leitet den Traffic an das Spoke-VCN weiter, und der Traffic erreicht den Webserver.
  7. Der Webserver sendet den Rückgabetraffic entsprechend der Routentabelle des Subnetzes an den DRG-Anhang.
  8. DRG referenziert die Routentabelle des Spoke-VCN-Anhangs und sendet den Traffic an den OCI Flexible Network Load Balancer im Hub.
  9. Der OCI Flexible Network Load Balancer UNAT den Traffic und verwendet die Standardroute des Subnetzes, um den Traffic an die eingehende NLB-IP 10.1.1.198 zu senden.
  10. Der eingehende NLB leitet den Datenverkehr an dasselbe PA-Gerät im Backend weiter, das den Datenverkehr mit dem symmetrischen Hashing-Algorithmus initiiert hat.
  11. Palo Alto empfängt den Datenverkehr auf der eingehenden NIC und sendet den Datenverkehr über die Standardroute virtueller Router an das Internetgateway zurück.
  12. Das Internetgateway leitet den Datenverkehr an den Internetclient weiter.

North-South Outbound Internet Traffic Flow von OCI:

Das folgende Diagramm zeigt den Fluss des ausgehenden Internettraffics von OCI. Alle VMs in OCI verwenden das SNAT- und OCI-NAT-Gateway von Palo Alto, um auf das Internet zuzugreifen. Der SNAT von Palo Alto wird benötigt, um den Rückweg symmetrisch zu gestalten. Die ausgehende öffentliche IP-Adresse ist die IP-Adresse des NAT-Gateways.


Beschreibung von oci-nlb-palo-alto-active-active-outbound.png folgt
Beschreibung der Abbildung oci-nlb-palo-alto-active-active-outbound.png

OCI-nlb-palo-alto-active-active-outbound-oracle.zip

  1. Traffic von der VM im Spoke-Subnetz mit der Standardroute zum DRG leitet den Traffic an den DRG-Anhang weiter.
  2. DRG bezieht sich auf die Anhangsroutentabelle des Spoke und leitet den Traffic an das Hub-VCN und die Transitroutentabelle des VCN weiter, um den Traffic an die Trust-NLB-IP 10.1.1.229 weiterzuleiten.
  3. NLB-Load gleicht den Datenverkehr mit einer der Firewalls im Active/Active-Modus aus.
  4. Firewall empfängt den Datenverkehr auf der Vertrauensschnittstelle im virtuellen Standardrouter. Er führt SNAT für den Traffic zur Untrust-Schnittstellen-IP durch und verweist auf die Standardroute, um den Traffic an das OCI-NAT-Gateway weiterzuleiten.
  5. Das NAT-Gateway leitet den Datenverkehr über die öffentliche IP des NAT-Gateways an das Internet weiter.
  6. Das Internet leitet den Rückgabetraffic erneut an das NAT-Gateway weiter.
  7. NAT Gateway UNAT ist der Verkehr und leitet es zurück zur gleichen Palo Alto Schnittstelle wie es eine SNAT auf Palo Alto gab.
  8. Auf Palo Alto basierende Statustabelle und Routen auf dem virtuellen Standardrouter senden den Traffic aus vertrauenswürdiger NIC an das DRG nach dem Reverse-NAT-Gateway.
  9. DRG bezieht sich auf die Routentabelle, die an das Hub-VCN angehängt ist, und leitet zum jeweiligen Spoke-VCN weiter und erreicht die Quell-VM.

East-West-Traffic zwischen Speichen in OCI oder On Premise zu OCI:

Das folgende Diagramm zeigt den Verkehrsfluss zwischen On Premise und OCI. Um den Verkehrsfluss zwischen Speichen in OCI zu verstehen, können wir On-Premises als einen der Speichen betrachten. In diesem Fall ist die einzige Änderung die Routentabelle, die im Spoke-Anhang referenziert wird. Dieses Deployment kann auf den Single-Arm-Modus verwiesen werden, bei dem der Traffic in dieselbe Schnittstelle der Firewall eingeht und diese verlässt. Hier ist die Schnittstelle die Trust-Schnittstelle.


Beschreibung von oci-nlb-palo-alto-active-active-onprem.png folgt
Beschreibung der Abbildung oci-nlb-palo-alto-active-active-onprem.png

OCI-nlb-palo-alto-active-active-onprem-oracle.zip

  1. On-Premise-Traffic wird entweder über IPSec oder OCI FastConnect an das OCI-DRG weitergeleitet.
  2. DRG bezieht sich auf die Anhangsroutentabelle von OCI FastConnect oder IPSec und leitet den Traffic an das Hub-VCN weiter. Die Routentabelle für den VCN-Anhang im Hub leitet Traffic an die Trust-NLB-IP 10.1.1.229 weiter.
  3. Beim NLB-Load Balancing wird der Datenverkehr auf eine der Firewalls im Active/Active-Modus verteilt.
  4. Firewall verarbeitet den Traffic gemäß der Sicherheitsregel und leitet ihn in der Hubroutentabelle im Hubanhang zurück an DRG.
  5. DRG bezieht sich auf die Routentabelle, die an den Hubanhang angehängt ist, und leitet den Traffic an das jeweilige Spoke-VCN und die entsprechende VM weiter.
  6. Die VM sendet den Rückgabetraffic an das DRG und verweist auf die Standardroutenregel in der Routentabelle.
  7. DRG bezieht sich auf die Routentabelle, die an das Spoke-VCN angehängt ist, und leitet den Traffic an das Hub-VCN weiter. Die Hubtransitroutentabelle leitet den Traffic an das Trust-NLB weiter.
  8. Mit dem symmetrischen Hashing-Algorithmus gleicht NLB den Datenverkehr mit demselben Palo Alto-Gerät aus.
  9. Firewall verweist auf die Statustabelle und Routen des virtuellen Standardrouters und sendet den Traffic zurück an das DRG in der Hubroutentabelle im Hubanhang.
  10. DRG bezieht sich auf die Hubroutentabelle im Hubanhang und leitet den Traffic über den OCI FastConnect- oder IPSec-Tunnel an On Premise weiter.

Ausgehender East-West-Trafficfluss von OCI-VMs zu Oracle Services Network:

Das folgende Diagramm zeigt den Fluss des ausgehenden Traffics von OCI-VMs zum Oracle Services Network. Alle VMs in OCI verwenden das SNAT- und OCI-Gervicegateway von Palo Alto für den Zugriff auf das Oracle Services Network. Der SNAT von Palo Alto wird benötigt, um den Rückweg symmetrisch zu gestalten. Wenn Sie im Oracle Services Network das VCN auf die Ausnahmeliste setzen müssen, sind dies die Hub-VCN-Bereiche.


Beschreibung von oci-nlb-palo-alto-active-active-osn.png folgt
Beschreibung der Abbildung oci-nlb-palo-alto-active-active-osn.png

OCI-nlb-palo-alto-active-active-osn-oracle.zip

  1. Traffic von der VM im Spoke-Subnetz mit der Standardroute zum DRG leitet den Traffic an den DRG-Anhang weiter.
  2. DRG bezieht sich auf die Anhangsroutentabelle des Spoke und leitet den Traffic an das Hub-VCN und die Routentabelle für VCN-Anhänge im Hub-VCN weiter, um den Traffic an die Trust-NLB-IP 10.1.1.229 weiterzuleiten.
  3. Trust NLB gleicht den Datenverkehr mit einer der Firewalls im Active/Active-Modus aus.
  4. Firewall empfängt den Datenverkehr auf der Vertrauensschnittstelle auf dem virtuellen Standardrouter. Er führt SNAT für den Datenverkehr zur Untrust-Schnittstellen-IP aus. Anschließend wird mit Verweis auf die Standardroute der Traffic an die Routentabelle des OCI-Subnetzes und dann an das OCI-Servicegateway weitergeleitet.
  5. Das Servicegateway leitet den Datenverkehr über das OCI-Backbone an das Oracle Services Network weiter und sendet den Rückgabetraffic zurück an dieselbe Schnittstelle der Firewall wie bei einem SNAT auf Palo Alto.
  6. Palo Alto bezieht sich auf die Statustabelle, führt die umgekehrte NAT aus und sendet basierend auf der statischen Route auf dem virtuellen Standardrouter den Verkehr aus vertrauenswürdiger NIC und schließlich an das DRG.
  7. DRG bezieht sich auf die Routentabelle, die an das Hub-VCN angehängt ist, und leitet den Traffic an das jeweilige Spoke-VCN und dann an die Quell-VM weiter.

Diese Architektur unterstützt die folgenden Komponenten:

  • Network Load Balancer

    Network Load Balancer ist ein Load Balancing-Service, der auf Layer 3 und Layer 4 des Open Systems Interconnection-(OSI-)Modells ausgeführt wird. Dieser Service bietet die Vorteile von High Availability und bietet hohen Durchsatz bei gleichzeitig extrem geringer Latenz.

  • Palo Alto-Firewall

    Die Firewall der nächsten Generation der VM-Serie schützt Ihre Anwendungen und Daten mit denselben Sicherheitsfunktionen, die auch die Infrastruktur der Kunden in der Cloud schützen. Mit der Firewall der nächsten Generation der VM-Serie können Entwickler und Cloud-Sicherheitsarchitekten Inline-Bedrohungs- und Datenverlustvermeidung in ihren Anwendungsentwicklungsworkflow einbetten.

  • Dynamisches Routinggateway (DRG)

    Das DRG ist ein virtueller Router, der einen Pfad für 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 Oracle Cloud Infrastructure-Region, ein On-Premise-Netzwerk oder ein Netzwerk in einem anderen Cloud-Provider.

  • Internetgateway

    Ein Internetgateway ermöglicht Traffic zwischen den öffentlichen Subnetzen in einem VCN und dem öffentlichen Internet.

  • Network Address Translation-(NAT-)Gateway

    Mit einem NAT-Gateway können private Ressourcen in einem VCN auf Hosts im Internet zugreifen, ohne diese Ressourcen für eingehende Internetverbindungen freizugeben.

  • On-Premise-Netzwerk

    Dies ist ein lokales Netzwerk, das von Ihrer Organisation verwendet wird.

  • Routentabelle

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

  • Servicegateway

    Das Servicegateway bietet Zugriff von einem VCN auf andere Services, wie Oracle Cloud Infrastructure Object Storage. Der Traffic vom VCN zum Oracle-Service wird über die Oracle-Netzwerkstruktur geleitet und durchläuft nicht das Internet.

  • Virtuelles Cloud-Netzwerk (VCN) und Subnetz

    Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten. Wie herkömmliche Data Center-Netzwerke erhalten Sie mit VCNs die Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich 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.