Cisco ASA: Policy-basiert

Dieses Thema stellt eine policy-basierte Konfiguration für ein Cisco ASA bereit, auf dem die Softwareversion 8.5 bis 9.7.0. ausgeführt wird

Wichtig

Oracle stellt Konfigurationsanweisungen für eine getestete Gruppe von Herstellern und Geräten bereit. Verwenden Sie die richtige Konfiguration für Ihren Hersteller und Ihre Softwareversion.

Wenn das Gerät oder die Softwareversion, die Oracle zur Überprüfung der Konfiguration verwendet hat, nicht genau mit Ihrem Gerät oder Ihrer Software übereinstimmt, können Sie die erforderliche Konfiguration auf Ihrem Gerät möglicherweise noch erstellen. Ziehen Sie die Dokumentation Ihres Herstellers zu Rate, und nehmen Sie die erforderlichen Anpassungen vor.

Wenn Ihr Gerät für einen Hersteller ausgelegt ist, der nicht in der Liste der verifizierten Hersteller und Geräte enthalten ist, oder wenn Sie bereits mit der Konfiguration Ihres Geräts für IPSec vertraut sind, finden Sie weitere Informationen in der Liste der unterstützten IPSec-Parameter und in der Dokumentation Ihres Herstellers.

Denken Sie daran, dass Oracle unterschiedliche Konfigurationen basierend auf der ASA-Software bereitstellt:

  • 9.7.1 oder höher: Routenbasierte Konfiguration
  • 8.5 bis 9.7.0: Policy-basierte Konfiguration (dieses Thema)
  • Älter als 8.5: Wird von den Oracle-Konfigurationsanweisungen nicht unterstützt. Ziehen Sie ein Upgrade auf eine neuere Version in Erwägung.
Wichtig

Oracle empfiehlt die Verwendung einer routenbasierten Konfiguration, um Interoperabilitätsprobleme zu vermeiden und eine Tunnelredundanz mit einem einzelnen Cisco ASA-Gerät zu erzielen.

Cisco ASA unterstützt keine routenbasierte Konfiguration für Softwareversionen, die älter sind als 9.7.1. Um optimale Ergebnisse zu erzielen, empfiehlt Oracle, ein Upgrade auf eine Softwareversion durchzuführen, die die routenbasierte Konfiguration unterstützt.

Bei einer policy-basierten Konfiguration können Sie nur einen einzelnen Tunnel zwischen Cisco ASA und Ihrem dynamischen Routinggateway (DRG) konfigurieren.

Oracle Cloud Infrastructure bietet Site-to-Site-VPN, eine sichere IPsec-Verbindung zwischen Ihrem On-Premise-Netzwerk und einem virtuellen Cloud-Netzwerk (VCN).

Das folgende Diagramm zeigt eine IPSec-Basisverbindung mit Oracle Cloud Infrastructure mit redundanten Tunneln. Die IP-Adressen in diesem Diagramm sind nur Beispiele und nicht literal zu verwenden.

In dieser Abbildung wird das allgemeine Layout Ihres On-Premise-Netzwerks, der IPsec-Tunnel für Site-to-Site-VPN und des VCN zusammengefasst.
Wichtig

Oracle stellt Konfigurationsanweisungen für eine getestete Gruppe von Herstellern und Geräten bereit. Verwenden Sie die richtige Konfiguration für Ihren Hersteller und Ihre Softwareversion.

Wenn das Gerät oder die Softwareversion, die Oracle zur Überprüfung der Konfiguration verwendet hat, nicht genau mit Ihrem Gerät oder Ihrer Software übereinstimmt, können Sie die erforderliche Konfiguration auf Ihrem Gerät möglicherweise noch erstellen. Ziehen Sie die Dokumentation Ihres Herstellers zu Rate, und nehmen Sie die erforderlichen Anpassungen vor.

Wenn Ihr Gerät für einen Hersteller ausgelegt ist, der nicht in der Liste der verifizierten Hersteller und Geräte enthalten ist, oder wenn Sie bereits mit der Konfiguration Ihres Geräts für IPSec vertraut sind, finden Sie weitere Informationen in der Liste der unterstützten IPSec-Parameter und in der Dokumentation Ihres Herstellers.

Best Practices

In diesem Abschnitt werden Best Practices und Überlegungen zur Verwendung von Site-to-Site-VPN beschrieben.

Spezifisch für Cisco ASA: VPN-Filter

Mit VPN-Filtern können Sie den Traffic weiter filtern, bevor er in einen Tunnel eintritt oder nachdem er einen Tunnel verlässt. Verwenden Sie VPN-Filter, wenn Sie zusätzliche Granularität zum Filtern verschiedener Traffictypen oder Quell-/Zielflüsse benötigen. Weitere Informationen finden Sie in der Dokumentation zu VPN-Filtern von Cisco.

Die VPN-Filterkonfiguration ist nicht Bestandteil der Konfigurationsvorlage im Abschnitt CPE-Konfiguration. Um VPN-Filter zu verwenden, fügen Sie die folgenden Konfigurationselemente manuell hinzu.

  • Access control list (ACL): Erstellen Sie eine ACL, mit der der VPN-Filter den durch die Tunnel zugelassenen Traffic einschränken kann. Wenn Sie bereits eine ACL für einen VPN-Filter verwenden, verwenden Sie sie nicht auch für eine Schnittstellenzugriffsgruppe.

    access-list ${vpnFilterAclName} extended permit ip ${VcnCidrNetwork} ${VcnCidrNetmask} ${onPremCidrNetwork} ${onPremCidrNetmask}
  • Group policy: Wenden Sie den VPN-Filter auf Ihre Gruppen-Policy an.

    group-policy oracle-vcn-vpn-policy attributes
     vpn-filter value ${vpnFilterAclName}
  • Tunnel group: Wenden Sie die Gruppen-Policy auf die Tunnelgruppe an.

    tunnel-group ${oracleHeadend1} general-attributes
     default-group-policy oracle-vcn-vpn-policy

Interessanter Verkehr

Oracle empfiehlt, dass Sie jederzeit interessanten Traffic über die IPSec-Tunnel laufen lassen, wenn Ihr CPE dies unterstützt. Cisco ASA erfordert die Konfiguration der SLA-Überwachung, wodurch interessanter Datenverkehr durch die IPSec-Tunnel läuft. In vielen Fällen, in denen Cisco ASA als Initiatorphase 2 fungiert, kommt es erst dann an, wenn kein interessanter Datenverkehr vorliegt, wodurch die SA entweder beim Hochfahren des Tunnels oder nach einer erneuten Schlüsselübergabe der Sicherheitsvereinigung heruntergefahren wird. Um solche Situationen zu vermeiden, kann kontinuierlicher interessanter Datenverkehr oder Funktionen wie IP SLA verwendet werden. Weitere Informationen finden Sie im Abschnitt "IP-SLA-Konfiguration" in der policy-basierten Cisco ASA-Konfigurationsvorlage.

Alle Tunnel für jede IPSec-Verbindung konfigurieren

Oracle stellt zwei IPSec-Headends für jede Verbindung bereit, um High Availability für Ihre geschäftskritischen Workloads bereitzustellen. Auf der Oracle-Seite befinden sich diese beiden Headends zu Redundanzzwecken auf verschiedenen Routern. Oracle empfiehlt die Konfiguration aller verfügbaren Tunnel für maximale Redundanz. Dies ist ein wichtiger Teil der "Design for Failure"-Philosophie.

Redundante CPEs an Ihren On-Premise-Netzwerkspeicherorten

Jede Ihrer Sites, die über IPSec mit Oracle Cloud Infrastructure verbunden ist, muss redundante Edge-Geräte (auch als Customer Premises Equipment (CPE) bezeichnet) haben. Fügen Sie jedes CPE der Oracle-Konsole hinzu, und erstellen Sie eine separate IPSec-Verbindung zwischen dem dynamischen Routinggateway (DRG)  und den CPEs. Für jede IPSec-Verbindung stellt Oracle durch Provisioning zwei Tunnel auf geografisch redundanten IPSec-Headends bereit. Weitere Informationen finden Sie im Connectivity Redundancy Guide (PDF).

Hinweise zum Routingprotokoll

Wenn Sie eine IPsec-Verbindung für Site-to-Site-VPN erstellen, verfügt diese über zwei redundante IPsec-Tunnel. Oracle empfiehlt, dass Sie das CPE so konfigurieren, dass beide Tunnel verwendet werden (wenn dies vom CPE unterstützt wird). In der Vergangenheit hat Oracle IPsec-Verbindungen erstellt, die bis zu vier IPsec-Tunnel enthielten.

Die folgenden drei Routingtypen sind verfügbar. Wählen Sie den Routingtyp separat für jeden Tunnel im Site-to-Site-VPN aus:

  • Dynamisches BGP-Routing: Die verfügbaren Routen werden dynamisch über BGP erlernt. Vom DRG werden die Routen aus Ihrem On-Premise-Netzwerk dynamisch erlernt. Auf der Oracle-Seite werden vom DRG die VCN-Subnetze veröffentlicht.
  • Statisches Routing: Wenn Sie die IPSec-Verbindung zum DRG einrichten, geben Sie die spezifischen Routen zu Ihrem On-Premise-Netzwerk an, über die das VCN informiert sein soll. Außerdem müssen Sie das CPE-Gerät mit statischen Routen zu den Subnetzen des VCN konfigurieren. Diese Routen werden nicht dynamisch erlernt.
  • Policybasiertes Routing: Wenn Sie die IPsec-Verbindung zum DRG einrichten, geben Sie die spezifischen Routen zu Ihrem On-Premise-Netzwerk an, über die das VCN informiert sein soll. Außerdem müssen Sie das CPE-Gerät mit statischen Routen zu den Subnetzen des VCN konfigurieren. Diese Routen werden nicht dynamisch erlernt.

Weitere Informationen über das Routing mit Site-to-Site-VPN, einschließlich Oracle-Empfehlungen zur Änderung des BGP-Algorithmus für die beste Pfadauswahl, finden Sie unter Routing für Site-to-Site-VPN.

Weitere wichtige CPE-Konfigurationen

Stellen Sie sicher, dass die Zugriffslisten in Ihrem CPE korrekt konfiguriert sind, damit der erforderliche Traffic von oder zu Oracle Cloud Infrastructure nicht blockiert wird.

Wenn mehrere Tunnel gleichzeitig hochgefahren sind, kann es zu asymmetrischem Routing kommen. Um asymmetrisches Routing zu ermöglichen, stellen Sie sicher, dass das CPE so konfiguriert ist, dass Traffic von Ihrem VCN in einem der Tunnel verarbeitet wird. Beispiel: Sie müssen die ICMP-Prüfung deaktivieren und die TCP-Statusumgehung konfigurieren. Für weitere Einzelheiten zur entsprechenden Konfiguration wenden Sie sich an den Support des CPE-Herstellers. Informationen zum Konfigurieren des symmetrischen Routings finden Sie unter Routing für Site-to-Site-VPN.

Spezifisch für Cisco ASA: Bedingungen und Einschränkungen

Dieser Abschnitt behandelt wichtige Merkmale und Einschränkungen, die für Cisco ASA spezifisch sind.

Unter Servicelimits finden Sie eine Liste der jeweiligen Limits sowie Anweisungen dazu, wie Sie eine Erhöhung anfordern.

Tunnel MTU und Path MTU Discovery

Mit Cisco ASA haben Sie zwei Optionen zum Adressieren von Tunnel MTU und Path MTU Discovery:

Option 1: TCP-MSS-Anpassung

Die Maximum Transmission Unit (Paketgröße) über den IPSec-Tunnel ist kleiner als 1500 Byte. Pakete, die für den Tunnel zu groß sind, können fragmentiert werden. Sie können auch ein Signal zurück an die über den Tunnel kommunizierenden Hosts senden, dass die gesendeten Pakete kleiner sein müssen.

Sie können das Cisco ASA so konfigurieren, dass die Maximum Segment Size (MSS) für neue TCP-Flüsse durch den Tunnel geändert wird. Das ASA prüft alle TCP-Pakete, bei denen das SYN-Flag gesetzt ist, und ändert den MSS-Wert auf den konfigurierten Wert. Diese Konfiguration kann bei neuen TCP-Flüssen bewirken, dass die Verwendung von Path Maximum Transmission Discovery (PMTUD) vermieden wird.

Verwenden Sie den folgenden Befehl, um die MSS zu ändern. Dieser Befehl ist nicht Bestandteil der Beispielkonfiguration im Abschnitt CPE-Konfiguration dieses Themas. Wenden Sie bei Bedarf den TCP-MSS-Anpassungsbefehl manuell an.

sysopt connection tcpmss 1387

Option 2: DF-Bit (Don't Fragment) löschen/setzen

Beim Path MTU Discovery muss für alle TCP-Pakete das DF-(Don't Fragment-)Bit gesetzt sein. Wenn das DF-Bit gesetzt ist und ein Paket für den Tunnel zu groß ist, löscht das ASA das Paket bei der Ankunft. Das ASA sendet ein ICMP-Paket an den Absender zurück, das angibt, dass das empfangene Paket für den Tunnel zu groß war. Das ASA bietet drei Optionen für die Handhabung des DF-Bits. Wählen Sie eine der Optionen, und wenden Sie sie auf die Konfiguration an:

  • Set the DF bit (empfohlen): Bei Paketen wird das DF-Bit im IP-Header gesetzt. Das ASA kann das Paket trotzdem fragmentieren, wenn das ursprüngliche empfangene Paket das DF-Bit gelöscht hat.

    crypto ipsec df-bit set-df ${outsideInterface}
  • Clear the DF bit: Das DF-Bit wird im IP-Header des Pakets gelöscht. Lässt zu, dass das Paket fragmentiert und an den Endhost in Oracle Cloud Infrastructure zur erneuten Assemblierung gesendet wird.

    crypto ipsec df-bit clear-df ${outsideInterface}
  • Ignore (copy) the DF bit: Das ASA prüft die IP-Header-Informationen des Originalpakets und kopiert die DF-Bit-Einstellung.

    crypto ipsec df-bit copy-df ${outsideInterface}

VPN-Traffic kann in einen Tunnel eintreten und einen anderen verlassen

Wenn der VPN-Traffic in eine Schnittstelle eintritt, die dieselbe Sicherheitsebene aufweist, wie eine Schnittstelle zum nächsten Hop des Pakets, müssen Sie diesen Traffic zulassen. Standardmäßig werden die Pakete zwischen Schnittstellen mit identischen Sicherheitsebenen im ASA gelöscht.

Fügen Sie den folgenden Befehl manuell hinzu, wenn Sie Traffic zwischen Schnittstellen mit denselben Sicherheitsebenen zulassen müssen. Dieser Befehl ist nicht Bestandteil der Beispielkonfiguration im Abschnitt CPE-Konfiguration.

same-security-traffic permit inter-interface

Allgemeine Bedingungen und Einschränkungen

In diesem Abschnitt werden allgemeine Merkmale und Einschränkungen von Site-to-Site-VPN beschrieben.

Unter Servicelimits finden Sie eine Liste der jeweiligen Limits sowie Anweisungen dazu, wie Sie eine Erhöhung anfordern.

Asymmetrisches Routing

Oracle verwendet asymmetrisches Routing über mehrere Tunnel, aus denen die IPSec-Verbindung besteht. Konfigurieren Sie Ihre Firewalls entsprechend. Andernfalls können Ping-Tests oder der Anwendungstraffic über die Verbindung hinweg nicht zuverlässig ausgeführt werden.

Wenn Sie mehrere Tunnel für Oracle Cloud Infrastructure verwenden, empfiehlt Oracle, dass Sie das Routing so konfigurieren, dass es den Traffic deterministisch über den bevorzugten Tunnel weiterleitet. Wenn Sie einen IPSec-Tunnel als primär und einen anderen als Backup verwenden möchten, konfigurieren Sie spezifischere Routen für den primären Tunnel (BGP) und weniger spezifische Routen (zusammenfassende oder Standardrouten) für den Backuptunnel (BGP/statisch). Wenn Sie dieselbe Route (z.B. eine Standardroute) über alle Tunnel anbieten, wird der Traffic vom VCN zum On-Premise-Netzwerk andernfalls an einen der verfügbaren Tunnel weitergeleitet. Das liegt daran, dass Oracle asymmetrisches Routing verwendet.

Spezifische Oracle-Routingempfehlungen zum Erzwingen des symmetrischen Routings finden Sie unter Routing für Site-to-Site-VPN.

Routenbasierte oder policybasierte IPsec-Verbindung

Das IPSec-Protokoll verwendet Sicherheitszuordnungen (Security Associations, SAs), um zu bestimmen, wie Pakete verschlüsselt werden. Innerhalb jeder SA definieren Sie Verschlüsselungsdomains, um die Quell- und Ziel-IP-Adresse eines Pakets einem Eintrag in der SA-Datenbank zuzuordnen. Dadurch wird festgelegt, wie ein Paket verschlüsselt oder entschlüsselt werden soll.

Hinweis

Von anderen Anbietern oder in der Branchendokumentation werden in Bezug auf SAs oder Verschlüsselungsdomains möglicherweise die Begriffe Proxy-ID, Sicherheitsparameterindex (SPI) oder Trafficselektor verwendet.

Es gibt zwei allgemeine Methoden zur Implementierung von IPSec-Tunneln:

  • Routenbasierte Tunnel: Auch als Next-Hop-Tunnel bezeichnet. Eine Routentabellensuche wird anhand der Ziel-IP-Adresse eines Pakets durchgeführt. Wenn es sich bei der Egress-Schnittstelle dieser Route um einen IPSec-Tunnel handelt, wird das Paket verschlüsselt und an das andere Ende des Tunnels gesendet.
  • Policy-basierte Tunnel: Die Quell- und-Ziel-IP-Adressen sowie das Protokoll des Pakets werden mit einer Liste von Policy-Anweisungen abgeglichen. Wenn eine Übereinstimmung gefunden wird, wird das Paket basierend auf den Regeln in dieser Policy-Anweisung verschlüsselt.

Die Site-to-Site-VPN-Headends von Oracle verwenden routenbasierte Tunnel, können jedoch mit policybasierten Tunneln arbeiten, zu denen einige Hinweise in den folgenden Abschnitten aufgeführt sind.

Verschlüsselungsdomain für routenbasierte Tunnel

Wenn Ihr CPE routenbasierte Tunnel unterstützt, konfigurieren Sie den Tunnel mit dieser Methode. Es handelt sich dabei um die einfachste Konfiguration mit der umfassendsten Interoperabilität mit dem Oracle-VPN-Headend.

Routingbasierte IPSec verwendet eine Verschlüsselungsdomain mit den folgenden Werten:

  • Quell-IP-Adresse: Beliebig (0.0.0.0/0)
  • Ziel-IP-Adresse: Beliebig (0.0.0.0/0)
  • Protokoll: IPv4

Wenn Sie spezifischer sein müssen, können Sie eine einzelne Zusammenfassungsroute für Ihre Verschlüsselungsdomainwerte anstelle einer Standardroute verwenden.

Verschlüsselungsdomain für policy-basierte Tunnel

Wenn Sie policybasierte Tunnel verwenden, generiert jeder Policy-Eintrag (ein CIDR-Block auf einer Seite der IPsec-Verbindung), den Sie definieren, eine IPsec-Sicherheitsverknüpfung (SA) mit jedem berechtigten Eintrag am anderen Ende des Tunnels. Dieses Paar wird als Verschlüsselungsdomain bezeichnet.

In diesem Diagramm enthält die Oracle-DRG-Seite des IPsec-Tunnels Policy-Einträge für drei IPv4-CIDR-Blöcke und einen IPv6-CIDR-Block. Die On-Premise-CPE-Seite des Tunnels enthält Policy-Einträge für zwei IPv4-CIDR-Blöcke und zwei IPv6-CIDR-Blöcke. Jeder Eintrag generiert eine Verschlüsselungsdomain mit allen möglichen Einträgen am anderen Ende des Tunnels. Beide Seiten eines SA-Paars müssen dieselbe IP-Version verwenden. Das Ergebnis sind insgesamt acht Verschlüsselungsdomains.

Diagramm mit mehreren Verschlüsselungsdomains, das veranschaulicht, wie ihre Anzahl bestimmt wird
Wichtig

Wenn das CPE nur policybasierte Tunnel unterstützt, beachten Sie die folgenden Einschränkungen.

  • Site-to-Site-VPN unterstützt mehrere Verschlüsselungsdomains, weist aber einen oberen Grenzwert von 50 Verschlüsselungsdomains auf.
  • Wenn Sie in einer Situation wie im obigen Beispiel nur drei der sechs möglichen IPv4-Verschlüsselungsdomains auf CPE-Seite konfiguriert haben, würde der Link mit dem Status "Teilweise hochgefahren" aufgelistet werden, weil auf DRG-Seite immer alle möglichen Verschlüsselungsdomains erstellt werden.
  • Policybasiertes Routing stützt sich auf Site-to-Site-VPN v2. Weitere Informationen zu Site-to-Site-VPN v2 finden Sie unter Aktualisierter Site-to-Site-VPN-Service.
  • Je nachdem, wann der Tunnel erstellt wurde, können Sie einen vorhandenen Tunnel möglicherweise nicht bearbeiten, um policybasiertes Routing zu verwenden. Sie müssen den Tunnel möglicherweise durch einen neuen IPsec-Tunnel ersetzen.
  • Die CIDR-Blöcke, die auf der Oracle-DRG-Seite des Tunnels verwendet werden, dürfen sich nicht mit den CIDR-Blöcken überschneiden, die auf der On-Premise-CPE-Seite des Tunnels verwendet werden.
  • Eine Verschlüsselungsdomain muss sich immer zwischen zwei CIDR-Blöcken derselben IP-Version befinden.

Wenn sich das CPE hinter einem NAT-Gerät befindet

Im Allgemeinen muss die CPE-IKE-ID, die an Ihrem Ende der Verbindung konfiguriert wurde, mit der CPE-IKE-ID übereinstimmen, die von Oracle verwendet wird. Standardmäßig verwendet Oracle die öffentliche IP-Adresse des CPE, die Sie beim Erstellen des CPE-Objekts in der Oracle-Konsole angeben. Wenn Ihr CPE sich jedoch hinter einem NAT-Gerät befindet, kann es sich bei der an Ihrem Ende konfigurierten CPE-IKE-ID um die private IP-Adresse des CPE handeln, wie im folgenden Diagramm dargestellt.

Diese Abbildung zeigt das CPE hinter einem NAT-Gerät, die öffentlichen und privaten IP-Adressen sowie die CPE-IKE-ID.
Hinweis

Einige CPE-Plattformen lassen die Änderung der lokalen IKE-ID nicht zu. In diesem Fall müssen Sie die Remote-IKE-ID in der Oracle-Konsole so ändern, dass sie mit der lokalen IKE-ID Ihres CPE übereinstimmt. Sie können den Wert angeben, wenn Sie die IPSec-Verbindung einrichten oder später, indem Sie die IPSec-Verbindung bearbeiten. Oracle erwartet, dass der Wert eine IP-Adresse oder ein vollständig angegebener Domainname (FQDN) ist, wie cpe.example.com. Weitere Informationen finden Sie unter Von Oracle verwendete CPE-IKE-ID ändern.

Unterstützte IPSec-Parameter

Eine Liste der vom Hersteller unterstützten IPSec-Parameter für alle Regionen finden Sie unter Unterstützte IPSec-Parameter.

Die Oracle BGP-ASN für die kommerzielle Cloud-Realm ist 31898. Wenn Sie Site-to-Site-VPN für die US Government Cloud konfigurieren, finden Sie weitere Informationen unter Erforderliche Site-to-Site-VPN-Parameter für die Government Cloud und BGP-ASN von Oracle. Informationen zur United Kingdom Government Cloud finden Sie unter BGP-ASN von Oracle.

CPE-Konfiguration

Wichtig

Die Konfigurationsanweisungen in diesem Abschnitt werden von Oracle Cloud Infrastructure für Ihr CPE bereitgestellt. Wenn Sie Support oder weitere Unterstützung benötigen, wenden Sie sich direkt an den Support des CPE-Herstellers.

In der folgenden Abbildung wird das Basislayout der IPSec-Verbindung dargestellt.

Diese Abbildung fasst das allgemeine Layout der IPSec-Verbindung und -Tunnel zusammen.

Die angegebene Konfigurationsvorlage ist für ein Cisco ASA mit der Softwareversion 8.5 (oder höher) bestimmt.

Hinweis

Cisco ASA-Versionen 9.7.1 und höher unterstützen die routenbasierte Konfiguration, die zur Vermeidung von Interoperabilitätsproblemen empfohlen wird.

Wenn Sie Tunnelredundanz mit einem einzelnen Cisco ASA-Gerät wünschen, müssen Sie die routenbasierte Konfiguration verwenden. Bei einer policy-basierten Konfiguration können Sie nur einen einzelnen Tunnel zwischen Cisco ASA und Ihrem dynamischen Routinggateway (DRG) konfigurieren.

Die Konfigurationsvorlage bezieht sich auf die folgenden Elemente, die Sie angeben müssen:

  • Öffentliche IP-Adresse des CPE: Die Internet-routbare IP-Adresse, die der externen Schnittstelle im CPE zugewiesen ist. Sie oder Ihr Oracle-Administrator stellt diesen Wert für Oracle beim Erstellen des CPE-Objekts in der Oracle-Konsole bereit.
  • Innere Tunnelschnittstelle (erforderlich, wenn BGP verwendet wird): Die IP-Adressen für die CPE- und Oracle-Enden der inneren Tunnelschnittstelle. Diese Werte geben Sie beim Erstellen der IPSec-Verbindung in der Oracle-Konsole an.
  • BGP-ASN (bei Verwendung von BGP erforderlich): Ihre BGP-ASN.

Darüber hinaus ist Folgendes erforderlich:

  • Konfigurieren Sie das interne Routing, das den Traffic zwischen dem CPE und Ihrem lokalen Netzwerk weiterleitet.
  • Stellen Sie sicher, dass Sie Traffic zwischen dem ASA und dem Oracle-VCN zulassen (die folgende Konfigurationsvorlage referenziert diese Zugriffsliste mit der Variablen ${outboundAclName}).
  • Identifizieren Sie die interne VPN-Gruppen-Policy (die folgende Konfigurationsvorlage referenziert diese Gruppen-Policy als oracle-vcn-vpn-policy).
  • Identifizieren Sie das Transformationsset, das für die kryptografische Zuordnung verwendet wird (die folgende Konfigurationsvorlage referenziert dieses Transformationsset als oracle-vcn-transform).
  • Identifizieren Sie den Namen und die Folgenummer der kryptografischen Zuordnung (die folgende Konfigurationsvorlage referenziert den Zuordnungsnamen als oracle-vpn-map-v1 und die Folgenummer 1).
  • Geben Sie die Vorgangsnummer für das kontinuierliche IP-SLA-Pingen an (die folgende Konfigurationsvorlage verwendet die Vorgangsnummer 1).
Wichtig

Diese folgende Konfigurationsvorlage von Oracle Cloud Infrastructure ist ein Ausgangspunkt für die Anwendung auf Ihr CPE. Die Syntax für jede CPE-Gerätekonfiguration kann je nach Modell und Softwareversion unterschiedlich sein. Vergleichen Sie Ihr CPE-Modell und die Version mit der entsprechenden Konfigurationsvorlage.

Einige der in der Vorlage referenzierten Parameter müssen für das CPE eindeutig sein. Die Eindeutigkeit kann nur bestimmt werden, indem Sie auf das CPE zugreifen. Stellen Sie sicher, dass die Parameter in Ihrem CPE gültig sind und keine zuvor konfigurierten Werte überschreiben. Stellen Sie insbesondere sicher, dass die folgenden Werte eindeutig sind:

  • Policy-Namen oder -Nummern
  • Crypto-Zuordnungsnamen und -Folgenummern

  • Schnittstellennamen
  • Zugriffslistennamen oder -nummern (falls zutreffend)

Oracle unterstützt Internet Key Exchange Version 1 (IKEv1) und Version 2 (IKEv2). Wenn Sie die IPSec-Verbindung in der Konsole für die Verwendung von IKEv2 konfigurieren, müssen Sie das CPE so konfigurieren, dass nur IKEv2 und zugehörige IKEv2-Verschlüsselungsparameter verwendet werden, die Ihr CPE unterstützt. Eine Liste der Parameter, die Oracle für IKEv1 oder IKEv2 unterstützt, finden Sie unter Unterstützte IPSec-Parameter.

Oracle stellt für IKEv1 und IKEv2 jeweils eine separate Konfigurationsvorlage bereit.

Oracle stellt außerdem ein Tool bereit, mit dem die Vorlage generiert werden kann. Dabei werden einige der Informationen automatisch eingetragen. Weitere Informationen finden Sie unter CPE-Konfigurations-Helper verwenden.

IKEv1-Konfigurationsvorlage

IKEv1-Konfigurationsvorlage für bessere Lesbarkeit im Vollbildmodus anzeigen.

!-------------------------------------------------------------------------------------------------------------------------------------------------------------
! IKEv1 Configuration Template
! The configuration consists of a single IPSec tunnel.
!-------------------------------------------------------------------------------------------------------------------------------------------------------------
! The configuration template involves setting up the following:
! Access Lists
! ISAKMP Policy
! Base VPN Policy
! IPSec Configuration
! IPSec Tunnel Group Configuration
! IP Routing (BGP or Static)
! Optional: Disable NAT for VPN Traffic
!-------------------------------------------------------------------------------------------------------------------------------------------------------------
! The configuration template has various parameters that you must define before applying the configuration.
!-------------------------------------------------------------------------------------------------------------------------------------------------------------
! PARAMETERS REFERENCED:
! ${OracleInsideTunnelIpAddress1} = Inside tunnel IP address of Oracle-side for the first tunnel. You provide these values when creating the IPSec connection in the Oracle Console.
! ${bgpASN} = Your BGP ASN
! ${cpePublicIpAddress} = The public IP address for the CPE. This is the IP address of your outside interface
! ${outboundAclName} = ACL used to control traffic out of your inside and outside interfaces
! ${oracleHeadend1} = Oracle public IP endpoint obtained from the Oracle Console.
! ${sharedSecret1} = You provide when you set up the IPSec connection in the Oracle Console, or you can use the default Oracle-provided value.
! ${outsideInterface} = The public interface or outside of tunnel interface which is configured with the CPE public IP address.
! ${vcnCidrNetwork} = VCN IP range
! ${vcnCidrNetmask} = Subnet mask for VCN
! ${onPremCidrNetwork} = On-premises IP range
! ${onPremCidrNetmask} = ON-premises subnet mask
! ${cryptoMapAclName} = Name of ACL which will be associated with the IPSec security association.
! ${vcnHostIp} = IP address of a VCN host. Used for IP SLA continuous ping to maintain tunnel UP state.
!-------------------------------------------------------------------------------------------------------------------------------------------------------------
 
! Access Lists
 
! Permit Traffic Between Your ASA and Your Oracle VCN
! Assuming there is an access-list controlling traffic in and out of your Internet facing interface, you will need to permit traffic between your CPE and the Oracle VPN Headend
! WARNING: The new ACL entry you add to permit the traffic between your ASA and VPN headend needs to be above any deny statements you might have in your existing access-list
 
access-list ${outboundAclName} extended permit ip host ${oracleHeadend1} host ${cpePublicIpAddress}
 
! Crypto ACL
! Create an ACL named ${cryptoMapAclName} which will later be associated with the IPSec security association using the 'crypto-map' command. This will define which source/destination traffic needs to be encrypted and sent across the VPN tunnel.
! Keep this ACL to a single entry. In a policy based configuration each ACL line will establish a separate encryption domain.
! The encryption domain used in this configuration sample will have a source/destination of any/VCN CIDR. Refer to the 'Encryption domain for policy-based tunnels' subsection for supported alternatives.
 
access-list ${cryptoMapAclName} extended permit ip any ${vcnCidrNetwork} ${vcnCidrNetmask}
 
! ISAKMP Policy
 
! ISAKMP Phase 1 configuration.
! IKEv1 is enabled on the outside interface.
! IKEv1 policy is created for Phase 1 which specifies to use a Pre-Shared Key, AES256, SHA1, Diffie-Hellman Group 5, and a Phase 1 lifetime of 28800 seconds (8 hours).
! If different parameters are required, modify this template before applying the configuration.
! WARNING: The IKEv1 group policy is created with a priority of 10. Make sure this doesn't conflict with any pre-existing configuration on your ASA.
 
crypto ikev1 enable outside
crypto ikev1 policy 10
 authentication pre-share
 encryption aes-256
 hash sha
 group 5
 lifetime 28800
 
! Base VPN Policy
 
! An internal VPN group policy named 'oracle-vcn-vpn-policy' is created to define some basic VPN tunnel settings
! Idle and session timeouts are disabled to maintain the tunnel UP state and tunnel protocol is set to IKEv1
 
group-policy oracle-vcn-vpn-policy internal
group-policy oracle-vcn-vpn-policy attributes
 vpn-idle-timeout none
 vpn-session-timeout none
 vpn-tunnel-protocol ikev1
 
! IPSec Configuration
 
! Create an IKEv1 transform set named 'oracle-vcn-transform' which defines a combination of IPSec (Phase 2) policy options. Specifically, AES256 for encryption and SHA1 for authentication.
! If different parameters are required, modify this template before applying the configuration.
 
crypto ipsec ikev1 transform-set oracle-vcn-transform esp-aes-256 esp-sha-hmac
 
! A crypto map is used to tie together the important traffic that needs encryption (via crypto map ACL) with defined security policies (from the transform set along with other crypto map statements), and the destination of the traffic to a specific crypto peer.
! In this configuration example, a single crypto map is created named 'oracle-vpn-map-v1' This crypto map references the previously created crypto map ACL, the 'oracle-vcn-transform' transform set and further defines PFS Group 5 and the security association lifetime to 3600 seconds (1 hour).
! WARNING: Make sure your crypto map name and sequence numbers do not overlap with existing crypto maps.
! WARNING: DO NOT use the 'originate-only' option with an Oracle IPSec tunnel. It causes the tunnel's traffic to be inconsistently blackholed. The command is only for tunnels between two Cisco devices. Here's an example of the command that you should NOT use for the Oracle IPSec tunnels: crypto map <map name> <sequence number> set connection-type originate-only
 
crypto map oracle-vpn-map-v1 1 match address ${cryptoMapAclName}
crypto map oracle-vpn-map-v1 1 set pfs group5
crypto map oracle-vpn-map-v1 1 set peer ${oracleHeadend1}
crypto map oracle-vpn-map-v1 1 set ikev1 transform-set oracle-vcn-transform
crypto map oracle-vpn-map-v1 1 set security-association lifetime seconds 3600
 
! WARNING: The below command will apply the 'oracle-vpn-map-v1' crypto map to the outside interface. The Cisco ASA supports a single crypto map per interface. Make sure no other crypto map is applied to the outside interface before using this command.
 
crypto map oracle-vpn-map-v1 interface outside
 
! IPSec Tunnel Group Configuration
 
! This configuration matches the group policy 'oracle-vcn-vpn-policy' with an Oracle VPN headend endpoint.
! The pre-shared key for each Oracle VPN headend is defined in the corresponding tunnel group.
 
tunnel-group ${oracleHeadend1} type ipsec-l2l
tunnel-group ${oracleHeadend1} general-attributes
 default-group-policy oracle-vcn-vpn-policy
tunnel-group ${oracleHeadend1} ipsec-attributes
 ikev1 pre-shared-key ${sharedSecret1}
 
! IP SLA Configuration
 
! The Cisco ASA doesn't establish a tunnel if there's no interesting traffic trying to pass through the tunnel.
! You must configure IP SLA on your device for a continuous ping so that the tunnel remains up at all times.
! You must allow ICMP on the outside interface.
! Make sure that the SLA monitor number used is unique.
 
sla monitor 1
 type echo protocol ipIcmpEcho ${vcnHostIp} interface outside
 frequency 5
sla monitor schedule 1 life forever start-time now
 
icmp permit any ${outsideInterface}
 
! IP Routing
! Pick either dynamic (BGP) or static routing. Uncomment the corresponding commands prior to applying configuration.
 
! Border Gateway Protocol (BGP) Configuration
! Uncomment below lines if you want to use BGP.
 
! router bgp ${bgpASN}
!  address-family ipv4 unicast
!   neighbor ${OracleInsideTunnelIpAddress1} remote-as 31898
!   neighbor ${OracleInsideTunnelIpAddress1} activate
!   network ${onPremCidrNetwork} mask ${onPremCidrNetmask}
!   no auto-summary
!   no synchronization
!  exit-address-family
 
! Static Route Configuration
! Uncomment below line if you want to use static routing.
  
! route outside ${VcnCidrNetwork} ${VcnCidrNetmask} ${OracleInsideTunnelIpAddress1}
 
! Disable NAT for VPN Traffic
 
! If you are using NAT for traffic between your inside and outside interfaces, you might need to disable NAT for traffic between your on-premises network and the Oracle VCN.
! Two objects are created for this NAT exemption. 'obj-OnPrem' represents the on-premises network as a default route, and 'obj-oracle-vcn-1' represents the VCN CIDR block used in Oracle Cloud Infrastructure.
! If different address ranges are required, modify this template before applying the configuration.
 
! object network obj-onprem
!  subnet 0.0.0.0 0.0.0.0
! object network obj-oracle-vcn-1
!  subnet ${vcnCidrNetwork} ${vcnCidrNetmask}
! nat (inside,outside) source static obj-onprem obj-onprem destination static obj-oracle-vcn-1 obj-oracle-vcn-1
IKEv2-Konfigurationsvorlage

IKEv2-Konfigurationsvorlage für bessere Lesbarkeit im Vollbildmodus anzeigen.

!-------------------------------------------------------------------------------------------------------------------------------------------------------------

! IKEv2 Configuration Template
! The configuration consists of a single IPSec tunnel.
!-------------------------------------------------------------------------------------------------------------------------------------------------------------
! The configuration template involves setting up the following:
! Access Lists
! IKEv2 Policy
! Base VPN Policy
! IPSec Configuration
! IPSec Tunnel Group Configuration
! IP Routing (BGP or Static)
! Optional: Disable NAT for VPN Traffic
!-------------------------------------------------------------------------------------------------------------------------------------------------------------
! The configuration template has various parameters that you must define before applying the configuration.
!-------------------------------------------------------------------------------------------------------------------------------------------------------------
! PARAMETERS REFERENCED:
! ${OracleInsideTunnelIpAddress1} = Inside tunnel IP address of Oracle-side for the first tunnel. You provide these values when creating the IPSec connection in the Oracle Console.
! ${bgpASN} = Your BGP ASN
! ${cpePublicIpAddress} = The public IP address for the CPE. This is the IP address of your outside interface
! ${outboundAclName} = ACL used to control traffic out of your inside and outside interfaces
! ${oracleHeadend1} = Oracle public IP endpoint obtained from the Oracle Console.
! ${sharedSecret1} = You provide when you set up the IPSec connection in the Oracle Console, or you can use the default Oracle-provided value.
! ${outsideInterface} = The public interface or outside of tunnel interface which is configured with the CPE public IP address.
! ${vcnCidrNetwork} = VCN IP range
! ${vcnCidrNetmask} = Subnet mask for VCN
! ${onPremCidrNetwork} = On-premises IP range
! ${onPremCidrNetmask} = ON-premises subnet mask
! ${cryptoMapAclName} = Name of ACL which will be associated with the IPSec security association.
! ${vcnHostIp} = IP address of a VCN host. Used for IP SLA continuous ping to maintain tunnel UP state.
!-------------------------------------------------------------------------------------------------------------------------------------------------------------

! Access Lists

! Permit Traffic Between Your ASA and Your Oracle VCN
! Assuming there is an access-list controlling traffic in and out of your Internet facing interface, you will need to permit traffic between your CPE and the Oracle VPN Headend
! WARNING: The new ACL entry you add to permit the traffic between your ASA and VPN headend needs to be above any deny statements you might have in your existing access-list

access-list ${outboundAclName} extended permit ip host ${oracleHeadend1} host ${cpePublicIpAddress}

! Crypto ACL
! Create an ACL named ${cryptoMapAclName} which will later be associated with the IPSec security association using the 'crypto-map' command. This will define which source/destination traffic needs to be encrypted and sent across the VPN tunnel.
! Keep this ACL to a single entry. In a policy based configuration each ACL line will establish a separate encryption domain.
! The encryption domain used in this configuration sample will have a source/destination of any/VCN CIDR. Refer to the 'Encryption domain for policy-based tunnels' subsection for supported alternatives.

access-list ${cryptoMapAclName} extended permit ip any ${vcnCidrNetwork} ${vcnCidrNetmask}

! IKEv2 Policy

! IKEv2 is enabled on the outside interface.
! IKEv2 policy is created and specifies use of a Pre-Shared Key, AES256, SHA1, Diffie-Hellman Group 5, and a lifetime of 28800 seconds (8 hours).
! If different parameters are required, modify this template before applying the configuration.
! WARNING: The IKEv2 group policy is created with a priority of 10. Make sure this doesn't conflict with any pre-existing configuration on your ASA.

crypto ikev2 enable outside
crypto ikev2 policy 10
 encryption aes-256
 integrity sha384
 group 5
 prf sha
 lifetime seconds 28800

! Base VPN Policy

! An internal VPN group policy named 'oracle-vcn-vpn-policy' is created to define some basic VPN tunnel settings
! Idle and session timeouts are disabled to maintain the tunnel UP state and tunnel protocol is set to IKEv2

group-policy oracle-vcn-vpn-policy internal
group-policy oracle-vcn-vpn-policy attributes
 vpn-idle-timeout none
 vpn-session-timeout none
 vpn-tunnel-protocol ikev2

! IPSec Configuration

! Create an IKEv2 IPSec proposal named 'oracle_v2_ipsec_proposal' which defines AES256 for encryption and SHA1 for authentication.
! If different parameters are required, modify this template before applying the configuration.

crypto ipsec ikev2 ipsec-proposal oracle_v2_ipsec_proposal
 protocol esp encryption aes-256
 protocol esp integrity sha-1

! A crypto map is used to tie together the important traffic that needs encryption (via crypto map ACL) with defined security policies (from the IPSec proposal along with other crypto map statements), and the destination of the traffic to a specific crypto peer.
! In this configuration example, a single crypto map is created named 'oracle-vpn-map-v2' This crypto map references the previously created crypto map ACL, the 'oracle_v2_ipsec_proposal' IPSec proposal and further defines PFS Group 5 and the security association lifetime to 3600 seconds (1 hour).
! WARNING: Make sure your crypto map name and sequence numbers do not overlap with existing crypto maps.
! WARNING: DO NOT use the 'originate-only' option with an Oracle IPSec tunnel. It causes the tunnel's traffic to be inconsistently blackholed. The command is only for tunnels between two Cisco devices. Here's an example of the command that you should NOT use for the Oracle IPSec tunnels: crypto map <map name> <sequence number> set connection-type originate-only

crypto map oracle-vpn-map-v2 1 match address ${cryptoMapAclName}
crypto map oracle-vpn-map-v2 1 set pfs group5
crypto map oracle-vpn-map-v2 1 set peer ${oracleHeadend1}
crypto map oracle-vpn-map-v2 1 set ikev2 ipsec-proposal oracle_v2_ipsec_proposal
crypto map oracle-vpn-map-v2 1 set security-association lifetime seconds 3600

! WARNING: The below command will apply the 'oracle-vpn-map-v2' crypto map to the outside interface. The Cisco ASA supports a single crypto map per interface. Make sure no other crypto map is applied to the outside interface before using this command.

crypto map oracle-vpn-map-v2 interface outside

! IPSec Tunnel Group Configuration

! This configuration matches the group policy 'oracle-vcn-vpn-policy' with an Oracle VPN headend endpoint.
! The pre-shared key for each Oracle VPN headend is defined in the corresponding tunnel group.

tunnel-group ${oracleHeadend1} type ipsec-l2l
tunnel-group ${oracleHeadend1} general-attributes
 default-group-policy oracle-vcn-vpn-policy
tunnel-group ${oracleHeadend1} ipsec-attributes
 ikev2 local-authentication pre-shared-key ${sharedSecret1}
 ikev2 remote-authentication pre-shared-key ${sharedSecret1}

! IP SLA Configuration

! The Cisco ASA doesn't establish a tunnel if there's no interesting traffic trying to pass through the tunnel.
! You must configure IP SLA on your device for a continuous ping so that the tunnel remains up at all times.
! You must allow ICMP on the outside interface.
! Make sure that the SLA monitor number used is unique.

sla monitor 1
type echo protocol ipIcmpEcho ${vcnHostIp} interface outside
frequency 5
sla monitor schedule 1 life forever start-time now

icmp permit any ${outsideInterface}

! IP Routing
! Pick either dynamic (BGP) or static routing. Uncomment the corresponding commands prior to applying configuration.

! Border Gateway Protocol (BGP) Configuration
! Uncomment below lines if you want to use BGP.

! router bgp ${bgpASN}
!  address-family ipv4 unicast
!   neighbor ${OracleInsideTunnelIpAddress1} remote-as 31898
!   neighbor ${OracleInsideTunnelIpAddress1} activate
!   network ${onPremCidrNetwork} mask ${onPremCidrNetmask}
!   no auto-summary
!   no synchronization
!  exit-address-family

! Static Route Configuration
! Uncomment below line if you want to use static routing.

! route outside ${VcnCidrNetwork} ${VcnCidrNetmask} ${OracleInsideTunnelIpAddress1}

! Disable NAT for VPN Traffic

! If you are using NAT for traffic between your inside and outside interfaces, you might need to disable NAT for traffic between your on-premises network and the Oracle VCN.
! Two objects are created for this NAT exemption. 'obj-OnPrem' represents the on-premises network as a default route, and 'obj-oracle-vcn-1' represents the VCN CIDR block used in Oracle Cloud Infrastructure.
! If different address ranges are required, modify this template before applying the configuration.

! object network obj-onprem
!  subnet 0.0.0.0 0.0.0.0
! object network obj-oracle-vcn-1
!  subnet ${vcnCidrNetwork} ${vcnCidrNetmask}
! nat (inside,outside) source static obj-onprem obj-onprem destination static obj-oracle-vcn-1 obj-oracle-vcn-1

Verifizierung

Die folgenden ASA-Befehle sind in der grundlegenden Fehlerbehebung enthalten. Ausführlichere Informationen finden Sie im Dokument zur IPSec-Fehlerbehebung von Cisco.

Mit dem folgenden Befehl prüfen Sie, ob ISAKMP-Sicherheitszuordnungen zwischen den beiden Peers erstellt werden.

show crypto isakmp sa

Mit dem folgenden Befehl können Sie den Status aller BGP-Verbindungen prüfen.

show bgp summary

Mit dem folgenden Befehl können Sie die Routentabelle des ASA prüfen.

show route

Ein Monitoring-Service ist auch in Oracle Cloud Infrastructure verfügbar, um Ihre Cloud-Ressourcen aktiv und passiv zu überwachen. Informationen zum Monitoring Ihres Site-to-Site-VPN finden Sie unter Site-to-Site-VPN-Metriken.

Bei Problemen finden Sie weitere Informationen unter Site-to-Site-VPN - Fehlerbehebung.