Diese Abbildung zeigt zwei Oracle Cloud Infrastructure-Regionen mit zwei Availability-Domains. Jede Region beinhaltet mindestens drei virtuelle Cloud-Netzwerke (VCNs), die für das Deployment dieser Architektur erforderlich sind. Die VCNs sind hier als Funktionsschichten angeordnet.

Management-VCN:

Das Management-VCN enthält zwei virtuelle Cisco ASA-Maschinen (VMs) mit einer VM in jeder Availability-Domain als Sandwich zwischen internem und externem flexiblen Netzwerk-Load Balancer. Sie können den Management-Server auch im Management-VCN bereitstellen, um die Firewallkonfiguration zu verwalten. Das Management-VCN umfasst ein einzelnes Management-Subnetz. Jede Firewall verfügt über einen dedizierten VPN-Pool, und der Endbenutzer erhält eine IP-Adresse von diesem Pool.

Das Management-Subnetz verwendet die primäre Schnittstelle (nic0/0), damit Endbenutzer eine Verbindung zur Benutzeroberfläche herstellen können.

Das Management-VCN verwendet ein Internetgateway, um Internet- und externe Webclients mit der virtuellen Cisco ASA-Firewall zu verbinden, um die Konfiguration zu verwalten. Das Management-VCN enthält außerdem zwei virtuelle Cisco ASA-Maschinen (VMs) mit einer VM in jeder Availability-Domain, zwischen dem flexiblen Netzwerk-Load Balancer. Das Mgt-VCN umfasst ein einzelnes Management-Subnetz. Jede Firewall verfügt außerdem über einen dedizierten VPN-Pool, und Endbenutzer erhalten eine IP-Adresse von diesem Pool.

Außerhalb des VCN:

Das VCN enthält mindestens ein externes Subnetz, das die sekundäre Schnittstelle (nic0/1) verwendet, damit Endbenutzer VPN-Traffic über Network Load Balancer an diese Schnittstelle senden können. Das externe VCN umfasst den folgenden flexiblen externen Netzwerk-Load Balancer. Dieser öffentliche Netzwerk-Load Balancer verfügt auch über externe Schnittstellen von Cisco ASA Virtual Firewall. So wird sichergestellt, dass jeder Traffic, der über den flexiblen Netzwerk-Load Balancer eingeht, zu einer der Firewall hinter ihm geleitet wird. Endbenutzer verwenden diese Netzwerk-Load Balancer-VIP als VPN-Head-End. Mit 2-tuple-Hash wird ein Load Balancing des Datenverkehrs an eine virtuelle Cisco ASA-Firewall sichergestellt. Dies würde die Stickiness für AnyConnect-Clients und Anwendungsdatenverkehr beibehalten.

Innerhalb des VCN:

Das VCN enthält mindestens ein Subnetz innerhalb. Das innere Subnetz verwendet die sekundäre Schnittstelle (nic0/2), damit Endbenutzer VPN-Traffic über Network Load Balancer an diese Schnittstelle senden können. Sie können auch ein weiteres Set aus Network Load Balancer bereitstellen, um Traffic von Spoke-VCNs zu steuern, die an die interne NLB und die zugehörige ASAv-Firewall weitergeleitet werden.

Spoke- oder Anwendungs-VCN (optional): Beim VCN kann es sich um ein Anwendungs-VCN handeln, das als Spoke-VCN fungiert. Wenn Sie von außen eine Verbindung herstellen und eine IP von einem dedizierten VPN-Pool abrufen, können Sie über das lokale Peering-Gateway oder dynamisches Routinggateway zu einem Spoke-VCN gelangen. Ein primäres Datenbanksystem befindet sich in Availability-Domain 1, und ein Standby-Datenbanksystem befindet sich in Availability-Domain 2. Das VCN der Datenbankebene ist über ein dynamisches Routinggateway mit dem Hub-VCN verbunden.