Libreswan

Libreswan ist eine quelloffene IPSec-Implementierung, die auf FreeS/WAN und Openswan basiert. Die meisten Linux-Distributionen enthalten Libreswan oder ermöglichen eine einfache Installation. Sie können die Installation auf Hosts in einem On-Premise-Netzwerk oder Cloud-Providernetzwerk ausführen. Ein Beispiel für die Einrichtung eines Libreswan-Hosts in einem anderen Cloud-Provider zur Verbindung mit einem Oracle Cloud Infrastructure-VCN finden Sie unter Auf andere Clouds mit Libreswan zugreifen.

Dieses Thema enthält Informationen zur Konfiguration für ein CPE, auf dem Libreswan ausgeführt wird. Für die Unterstützung der virtuellen Tunnelschnittstelle (VTI) für diese routenbasierte Konfiguration sind mindestens Libreswan Version 3.18 und ein aktueller Linux 3.x- oder 4.x-Kernel erforderlich. Diese Konfiguration wurde mit Libreswan Version 3.29. validiert.

Wichtig

Oracle bietet Konfigurationsanweisungen für eine getestete Gruppe von Herstellern und Geräten. Verwenden Sie die richtige Konfiguration für den Hersteller und die Softwareversion.

Wenn das Gerät oder die Softwareversion, die Oracle zur Überprüfung der Konfiguration verwendet hat, nicht exakt mit dem Gerät oder der Software übereinstimmt, können Sie dennoch die erforderliche Konfiguration auf dem Gerät erstellen. Lesen Sie die Dokumentation des Herstellers, und nehmen Sie die erforderlichen Änderungen vor.

Wenn das Gerät von einem Hersteller stammt, der nicht in der Liste der verifizierten Hersteller und Geräte enthalten ist, oder wenn Sie bereits mit der Konfiguration des Geräts für IPSec vertraut sind, finden Sie weitere Informationen in der Liste der IPSec-Parameter und in der Dokumentation des Herstellers.

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

Das folgende Diagramm zeigt eine IPSec-Basisverbindung mit Oracle Cloud Infrastructure mit redundanten Tunneln. Die in diesem Diagramm verwendeten IP-Adressen dienen lediglich als Beispiel.

In diesem Bild wird das allgemeine Layout eines On-Premise-Netzwerks, der Site-to-Site-VPN-IPSec-Tunnel und des VCN zusammengefasst.

Best Practices

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

Alle Tunnel für jede IPSec-Verbindung konfigurieren

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

Redundante CPEs an On-Premise-Netzwerkspeicherorten

Wir empfehlen, dass jede Site, die eine Verbindung mit IPSec zu Oracle Cloud Infrastructure herstellt, über redundante Edge-Geräte (auch als Customer-Premises-Equipment (CPE) bezeichnet) verfügt. Sie fügen jedes CPE zur Oracle-Konsole hinzu und erstellen eine separate IPSec-Verbindung zwischen einem dynamischen Routinggateway (DRG) und jedem CPE. 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 Site-to-Site-VPN-IPSec-Verbindung erstellen, verfügt sie über zwei redundante IPSec-Tunnel. Oracle empfiehlt Ihnen, das CPE so zu konfigurieren, dass beide Tunnel verwendet werden (wenn das CPE dies unterstützt). 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. Das DRG lernt die Routen aus dem On-Premise-Netzwerk dynamisch. 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 dem On-Premise-Netzwerk an, über die das VCN wissen 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.
  • Policy-basiertes Routing: Wenn Sie die IPSec-Verbindung zum DRG einrichten, geben Sie die spezifischen Routen zu dem On-Premise-Netzwerk an, über die das VCN wissen 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 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 im 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 berücksichtigen, stellen Sie sicher, dass das CPE so konfiguriert ist, dass Traffic von dem 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. Wie Sie das symmetrische Routing konfigurieren, finden Sie unter Routing für Site-to-Site-VPN.

Hinweise und Einschränkungen

In diesem Abschnitt werden die allgemeinen wichtigen Merkmale und Einschränkungen von Site-to-Site-VPN beschrieben. In den Servicelimits finden Sie eine Liste der jeweiligen Limits sowie Anweisungen dazu, wie Sie eine Erhöhung beantragen.

Asymmetrisches Routing

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

Wenn Sie mehrere Tunnel zu Oracle Cloud Infrastructure verwenden, wird empfohlen, das Routing so zu konfigurieren, dass der Traffic deterministisch durch den bevorzugten Tunnel geleitet wird. Um einen IPSec-Tunnel als primär und einen anderen als Backup zu verwenden, konfigurieren Sie spezifischere Routen für den primären Tunnel (BGP) und weniger spezifische Routen (zusammenfassende oder Standardrouten) für den Backuptunnel (BGP/static). Wenn Sie dieselbe Route (z.B. eine Standardroute) über alle Tunnel anbieten, wird der Traffic von einem VCN zu einem 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.

Routenbasiertes oder policybasiertes Site-to-Site-VPN

Das IPSec-Protokoll verwendet Security Associations (SAs), um zu entscheiden, 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.

Beachten Sie, dass

andere Hersteller oder die Branchendokumentation die Begriffe Proxy-ID, Sicherheitsparameterindex (SPI) oder Trafficselektor beim Verweisen auf SAs oder Verschlüsselungsdomains verwenden können.

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.

Hinweis zu Libreswan 3.25

Wenn ein CPE-Gerät Libreswan 3.25 oder früher verwendet und Sie versuchen, eine IKEv1-Verbindung mit einem CPE als Responder einzurichten, müssen Sie den Parameter der Phase 2 explizit in einer CPE-Konfiguration festlegen, damit der IPSec-Tunnel hochgefahren wird. Beispiel: Mit dem aktuellen empfohlenen Verschlüsselungsalgorithmus AES-256-gcm und PFS group5 müssen Sie den Parameter phase2alg="aes_gcm256;modp1536" der Phase 2 auf dem CPE-Gerät konfigurieren.

Dieses Problem tritt in späteren Libreswan-Releases nicht mehr auf.

Verschlüsselungsdomain für routenbasierte Tunnel

Wenn das CPE routenbasierte Tunnel unterstützt, konfigurieren Sie den Tunnel mit dieser Methode. Dies ist 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 zusammenfassende Route für 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-Sicherheitszuordnung (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 und deren Anzahl.
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 vorherigen 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.
  • Je nachdem, wann ein Tunnel erstellt wurde, können Sie einen vorhandenen Tunnel möglicherweise nicht bearbeiten, um richtlinienbasiertes Routing zu verwenden, und 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 am On-Premise-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 angeben, wenn Sie das CPE-Objekt in der Oracle-Konsole erstellen. Wenn sich ein CPE jedoch hinter einem NAT-Gerät befindet, kann es sich bei der am On-Premise-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

Bei einigen CPE-Plattformen können Sie die lokale IKE-ID nicht ändern. In diesem Fall müssen Sie die entfernte IKE-ID in der Oracle-Konsole so ändern, dass sie mit der lokalen IKE-ID des 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.

CPE-Konfiguration

Wichtig

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

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

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

Libreswan-Standardkonfigurationsdateien

Bei der standardmäßigen Libreswan-Installation werden die folgenden Dateien erstellt:

  • etc/ipsec.conf: Root der Libreswan-Konfiguration.
  • /etc/ipsec.secrets: Root des Speicherorts, in dem Libreswan nach Secrets (Tunnel-Pre-Shared Keys) sucht.
  • /etc/ipsec.d/: Verzeichnis zum Speichern der Dateien .conf und .secrets für die Oracle Cloud Infrastructure-Tunnel (Beispiel: oci-ipsec.conf und oci-ipsec.secrets). Libreswan empfiehlt, dass Sie diese Dateien in diesem Ordner erstellen.

Die Standarddatei etc/ipsec.conf enthält die folgende Zeile:

include /etc/ipsec.d/*.conf

Die Standarddatei etc/ipsec.secrets enthält die folgende Zeile:

include /etc/ipsec.d/*.secrets

Die vorherigen Zeilen führen automatisch alle .conf- und .secrets-Dateien im Verzeichnis /etc/ipsec.d in den Hauptkonfigurations- und Secrets-Dateien zusammen, die Libreswan verwendet.

IKEv2 verwenden

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 das CPE unterstützt. Eine Liste der Parameter, die Oracle für IKEv1 oder IKEv2 unterstützt, finden Sie unter Unterstützte IPSec-Parameter.

Sie geben die IKE-Version an, wenn Sie die IPSec-Konfigurationsdatei in Aufgabe 3 im nächsten Abschnitt einrichten. Diese Beispieldatei zeigt einen Kommentar, der zeigt, wie IKEv1 im Vergleich zu IKEv2 konfiguriert wird.

Konfigurationsprozess

Libreswan unterstützt sowohl routenbasierte als auch policy-basierte Tunnel. Die Tunneltypen können zusammen verwendet werden, ohne einander zu beeinträchtigen. Die VPN-Headends von Oracle verwenden routenbasierte Tunnel. Es wird empfohlen, dass Sie Libreswan mit der Virtual Tunnel Interface-(VTI-)Konfigurationssyntax konfigurieren.

Weitere Informationen zu den spezifischen Parametern, die in diesem Dokument verwendet werden, finden Sie unter Unterstützte IPSec-Parameter.

Aufgabe 1: Libreswan-Instanz vorbereiten

Abhängig von der verwendeten Linux-Distribution müssen Sie möglicherweise die IP-Weiterleitung auf einer Schnittstelle aktivieren, damit Clients Traffic über Libreswan senden und empfangen können. Legen Sie in der Datei /etc/sysctl.conf die folgenden Werte fest, und wenden Sie die Aktualisierungen mit sudo sysctl -p an.

Wenn Sie eine andere Schnittstelle als eth0 verwenden, ändern Sie eth0 im folgenden Beispiel in die Schnittstelle (Zeilen 5 und 7).

net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
Aufgabe 2: Entscheiden Sie die erforderlichen Konfigurationswerte

In der Libreswan-Konfiguration werden die folgenden Variablen verwendet. Entscheiden Sie die Werte, bevor Sie mit der Konfiguration fortfahren.

  • ${cpeLocalIP}: IP-Adresse des Libreswan-Geräts.
  • ${cpePublicIpAddress}: Öffentliche IP-Adresse für Libreswan. Dies ist die IP-Adresse der äußeren Schnittstelle. Abhängig von der Netzwerktopologie kann sich der Wert von ${cpeLocalIP} unterscheiden.
  • ${oracleHeadend1}: Öffentlicher Oracle-IP-Endpunkt für den ersten Tunnel, der aus der Oracle-Konsole abgerufen wird.
  • ${oracleHeadend2}: Öffentlicher Oracle IP-Endpunkt für den zweiten Tunnel, der aus der Oracle-Konsole abgerufen wird.
  • ${vti1}: Name der ersten verwendeten VTI. Beispiel: vti1.
  • ${vti2}: Name der zweiten verwendeten VTI. Beispiel: vti2.
  • ${sharedSecret1}: Pre-Shared Key für den ersten Tunnel. Sie können den standardmäßig von Oracle bereitgestellten Pre-Shared Key verwenden oder einen Schlüssel angeben, wenn Sie die Verbindung IPSec in der Oracle-Konsole einrichten.
  • ${sharedSecret2}: Pre-Shared Key für den zweiten Tunnel. Sie können den standardmäßig von Oracle bereitgestellten Pre-Shared Key verwenden oder einen Schlüssel angeben, wenn Sie die Verbindung IPSec in der Oracle-Konsole einrichten.
  • ${vcnCidrNetwork}: VCN-IP-Bereich.
Aufgabe 3: Konfigurationsdatei einrichten

Bei der Libreswan-Konfiguration wird das Konzept von links und rechts verwendet, um die Konfigurationsparameter für ein lokales CPE-Gerät und das Remotegateway zu definieren. Beide Seiten der Verbindung (conn in der Libreswan-Konfiguration) können links oder rechts sein, die Konfiguration für diese Verbindung muss jedoch konsistent sein. In diesem Beispiel:

  • links: Das lokale Libreswan-CPE
  • rechts: Das Oracle-VPN-Headend

Verwenden Sie die folgende Vorlage für die Datei /etc/ipsec.d/oci-ipsec.conf. Die Datei definiert die beiden Tunnel, die Oracle erstellt, wenn Sie die IPSec-Verbindung einrichten.

Wichtig

Wenn sich das CPE hinter einem 1-1 NAT-Gerät befindet, entfernen Sie den Parameter leftid, und setzen Sie ihn mit dem Wert ${cpePublicIpAddress} gleich.

conn oracle-tunnel-1
     left=${cpeLocalIP}
     # leftid=${cpePublicIpAddress} # See preceding note about 1-1 NAT device
     right=${oracleHeadend1}
     authby=secret
     leftsubnet=0.0.0.0/0 
     rightsubnet=0.0.0.0/0
     auto=start
     mark=5/0xffffffff # Needs to be unique across all tunnels
     vti-interface=${vti1}
     vti-routing=no
     ikev2=no # To use IKEv2, change to ikev2=insist 
     ike=aes_cbc256-sha2_384;modp1536
     phase2alg=aes_gcm256;modp1536
     encapsulation=yes
     ikelifetime=28800s
     salifetime=3600s
conn oracle-tunnel-2
     left=${cpeLocalIP}
     # leftid=${cpePublicIpAddress} # See preceding note about 1-1 NAT device
     right=${oracleHeadend2}
     authby=secret
     leftsubnet=0.0.0.0/0
     rightsubnet=0.0.0.0/0
     auto=start
     mark=6/0xffffffff # Needs to be unique across all tunnels
     vti-interface=${vti2}
     vti-routing=no
     ikev2=no # To use IKEv2, change to ikev2=insist 
     ike=aes_cbc256-sha2_384;modp1536
     phase2alg=aes_gcm256;modp1536 
     encapsulation=yes
     ikelifetime=28800s
     salifetime=3600s
Aufgabe 4: Secrets-Datei einrichten

Verwenden Sie die folgende Vorlage für die Datei /etc/ipsec.d/oci-ipsec.secrets. Sie enthält zwei Zeilen pro IPSec-Verbindung (eine Zeile pro Tunnel).

${cpePublicIpAddress} ${oracleHeadend1}: PSK "${sharedSecret1}"
${cpePublicIpAddress} ${oracleHeadend2}: PSK "${sharedSecret2}"
Aufgabe 5: Libreswan-Konfiguration neu starten

Nach der Einrichtung der Konfigurations- und Secret-Dateien muss der Libreswan-Service neu gestartet werden.

Wichtig

Der Neustart des Libreswan-Service kann sich auf vorhandene Tunnel auswirken.

Der folgende Befehl liest die Konfigurationsdatei erneut und startet den Libreswan-Service neu.

service ipsec restart
Aufgabe 6: IP-Routing konfigurieren

Verwenden Sie den folgenden ip-Befehl, um statische Routen zu erstellen, die über die IPSec-Tunnel Traffic an ein VCN senden. Wenn Sie mit einem nicht berechtigten Benutzeraccount angemeldet sind, müssen Sie vor dem Befehl möglicherweise sudo verwenden.

Wichtig

Statische Routen, die mit dem Befehl ip route erstellt werden, werden nicht durch einen Neustart persistiert. Informationen dazu, wie die Routen beibehalten werden sollen, finden Sie in der Dokumentation der Linux-Distribution Ihrer Wahl.
ip route add ${VcnCidrBlock} nexthop dev ${vti1} nexthop dev ${vti2}
ip route show

Verifizierung

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

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

Libreswan-Status prüfen

Prüfen Sie den aktuellen Status von Libreswan-Tunneln mit dem folgenden Befehl.

ipsec status

Der Tunnel wurde eingerichtet, wenn eine Zeile mit folgendem Inhalt angezeigt wird:

STATE_MAIN_I4: ISAKMP SA established

Wenn Sie IKEv2 verwenden, wird Folgendes angezeigt:

STATE_V2_IPSEC_I (IPsec SA established)

Wenn Sie zu einem späteren Zeitpunkt ein Oracle-Supportticket zu einem Libreswan-Tunnel erstellen müssen, fügen Sie dem Ticket die Ausgabe des vorherigen ipsec status-Befehls hinzu.

Status der Tunnelschnittstelle prüfen

Stellen Sie mit den Befehlen ifconfig oder ip link show sicher, dass die virtuellen Tunnelschnittstellen hochgefahren oder heruntergefahren sind. Sie können auch Anwendungen wie tcpdump mit den Schnittstellen verwenden.

Im Folgenden finden Sie ein Beispiel der ifconfig-Ausgabe mit einer Libreswan-Implementierung, in der die verfügbaren VTIs angezeigt werden.

ifconfig
<output trimmed>
				
vti01: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 8980
     inet6 fe80::5efe:a00:2 prefixlen 64 scopeid 0x20<link>
     tunnel txqueuelen 1000 (IPIP Tunnel)
     RX packets 0 bytes 0 (0.0 B)
     RX errors 0 dropped 0 overruns 0 frame 0
     TX packets 0 bytes 0 (0.0 B)
     TX errors 10 dropped 0 overruns 0 carrier 10 collisions 0

vti02: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 8980
     inet6 fe80::5efe:a00:2 prefixlen 64 scopeid 0x20<link>
     tunnel txqueuelen 1000 (IPIP Tunnel)
     RX packets 0 bytes 0 (0.0 B)
     RX errors 0 dropped 0 overruns 0 frame 0
     TX packets 0 bytes 0 (0.0 B)
     TX errors 40 dropped 0 overruns 0 carrier 40 collisions 0

Beispiel für die ip link show-Ausgabe:

ip link show
<output trimmed>

9: vti01@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8980 qdisc noqueue
state UNKNOWN mode DEFAULT group default qlen 1000
   link/ipip 10.0.0.2 peer 129.213.240.52

10: vti02@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8980 qdisc noqueue
state UNKNOWN mode DEFAULT group default qlen 1000
   link/ipip 10.0.0.2 peer 129.213.240.51

Außerdem sollte jeder IPSec-Tunnel in der Oracle Konsole den Status "UP" haben.