Oracle Cloud Infrastructure - Dokumentation

Mit Site-to-Site-VPN arbeiten

Dieses Thema enthält Details zum Arbeiten mit Site-to-Site-VPN und den zugehörigen Komponenten. Weitere Informationen finden Sie in den folgenden Themen:

Statische Routen ändern

Sie können die statischen Routen für eine vorhandene IPSec-Verbindung ändern. Sie können bis zu 10 statische Routen angeben.

Beachten Sie, dass eine IPSec-Verbindung statisches Routing, dynamisches BGP-Routing oder Policy-basiertes Routing verwenden kann. Wenn Sie statisches Routing verwenden, verknüpfen Sie die statischen Routen mit der gesamten IPSec-Verbindung und nicht den einzelnen Tunneln. Wenn einer IPSec-Verbindung statische Routen zugeordnet sind, verwendet Oracle sie nur zum Routing des Traffics eines Tunnels, wenn für den Tunnel selbst statisches Routing konfiguriert ist. Wenn für den Tunnel dynamisches BGP-Routing konfiguriert ist, werden die statischen Routen der IPSec-Verbindung ignoriert.

Wichtig

Die Verbindung IPSec wird heruntergefahren, während die Änderungen an den statischen Routen erneut durch Provisioning bereitgestellt werden.

Die erforderlichen Schritte zum Ändern der statischen Routen finden Sie unter IPSec-Verbindung aktualisieren.

Von statischem Routing zu dynamischem BGP-Routing wechseln

Informationen zum Ändern eines vorhandenen Site-to-Site-VPNs von statischem Routing zu dynamischem BGP-Routing finden Sie unter Aktualisieren eines IPSec-Tunnels.

Achtung

Wenn Sie den Routingtyp eines Tunnels ändern, ändert sich der Status IPSec des Tunnels beim erneuten Provisioning nicht. Das Routing durch den Tunnel ist jedoch betroffen. Der Traffic wird vorübergehend unterbrochen, bis ein Netzwerkingenieur das CPE-Gerät in Übereinstimmung mit der Routingtypänderung konfiguriert hat. Wenn ein vorhandenes Site-to-Site-VPN so konfiguriert ist, dass nur ein einzelner Tunnel verwendet wird, unterbricht dieser Prozess die Verbindung zu Oracle. Wenn ein Site-to-Site-VPN stattdessen mehrere Tunnel verwendet, wird empfohlen, jeweils nur einen Tunnel gleichzeitig zu konfigurieren, um zu vermeiden, dass die Verbindung zu Oracle unterbrochen wird.

Zu Policy-basiertem VPN migrieren

Der Site-to-Site-VPN-Service v2 von Oracle Cloud Infrastructure unterstützt Policy-basierte IPSec-VPNs mit bis zu 50 Verschlüsselungsdomains pro Tunnel vollständig.

Um potenzielle Trafficunterbrechungen zu vermeiden, ändern Sie die Tunnelkonfigurationen auf der OCI-Seite der Verbindung so, dass sie der CPE-Konfiguration entsprechen, wenn Sie vom Site-to-Site-VPN-Service v1 zu Site-to-Site-VPN v2 migriert wurden und ein CPE mit mehreren Verschlüsselungsdomains konfiguriert haben. In diesem Artikel wird erläutert, warum diese Änderung so wichtig ist, und die erforderlichen Schritte zur Konfiguration von OCI für die Verwendung von Policy-basierten IPSec-VPNs.

Gründe für die Migration zur Policy-basierten VPN-Funktion

Der Site-to-Site-VPN-Service v1 ist immer als routenbasiertes VPN konfiguriert und verwendet eine beliebige/beliebige Verschlüsselungsdomain sowohl für BGP- als auch für statische Routingtypen. Für die Policy-basierte VPN-Interoperabilität unterstützt das Site-to-Site-VPN v1 ein CPE, das für Policy-basierte VPNs konfiguriert ist, wenn das CPE als Initiator fungiert, und nur eine einzige Verschlüsselungsdomain wird an OCI gesendet. Die Konfiguration mehrerer Verschlüsselungsdomänen in diesem Szenario führt zu einer Instabilität des Tunnels, bei der Sie das Flatschen des Tunnels beobachten oder der Verkehr, der den Tunnel durchläuft, eine instabile Erreichbarkeit aufweist.

Der Site-to-Site-VPN-Service v2 verwendet zusätzlich zu den BGP- und statischen Routingtypen eine Policy-basierte Routingtypoption. Die BGP- und statischen Routingtypen von Site-to-Site-VPN v2 bleiben routenbasiert und unterstützen eine einzelne beliebige/jede Verschlüsselungsdomain. Diese Optionen funktionieren mit einer Policy-basierten CPE-Konfiguration einer einzelnen Verschlüsselungsdomain. Dies wird jedoch nicht empfohlen, und das Senden mehrerer Verschlüsselungsdomänen führt zu Tunnelinstabilität.

Der Policy-basierte Routingtyp, der für das Site-to-Site-VPN v2 verfügbar ist, ist ein Policy-basiertes VPN mit vollem Funktionsumfang, mit dem Sie die OCI-Seite so konfigurieren können, dass sie vollständig mit der Policy-basierten Konfiguration eines CPE übereinstimmt, und alle einzelnen Sicherheitszuordnungen (SAs) akzeptieren, die für einen stabilen IPSec-VPN-Tunnel erforderlich sind.

Weitere Informationen zu Verschlüsselungsdomains und den verschiedenen IPSec-VPN-Tunneltypen finden Sie unter Unterstützte Verschlüsselungsdomain oder Proxy-ID.

Nachdem die Tunnel von Site-to-Site-VPN v1 zu v2 migriert wurden, verwenden sie weiterhin denselben Routingtyp (BGP oder statisch), wie vor der Migration konfiguriert. Der Schritt-für-Schritt-Prozess zum Ändern vorhandener routenbasierter Tunnel zur Verwendung von richtlinienbasiertem Routing wird beschrieben.

Unter IPSec-Tunnel aktualisieren finden Sie bestimmte Schritte für die Migration zu einem richtlinienbasierten VPN.

Von Oracle verwendete CPE-IKE-ID ändern

Wenn sich das CPE hinter einem NAT-Gerät befindet, müssen Sie Oracle möglicherweise die CPE-IKE-ID angeben. Sie können sie entweder beim Erstellen der IPSec-Verbindung angeben oder die IPSec-Verbindung später bearbeiten und den entsprechenden Wert ändern. Oracle erwartet, dass der Wert eine IP-Adresse oder ein vollqualifizierter Domainname (FQDN) ist. Wenn Sie den Wert angeben, geben Sie auch den entsprechenden Typ an.

Wichtig

Die Verbindung IPSec wird heruntergefahren, während sie für die Verwendung der IKE-ID des CPE neu bereitgestellt wird.

Die erforderlichen Schritte zum Ändern der von Oracle verwendeten CPE-IKE-ID finden Sie unter IPSec-Verbindung aktualisieren.

Verwenden von IKEv2

Oracle unterstützt Internet Key Exchange (IKE) Version 1 und Version 2 (IKEv2).

Um IKEv2 mit einem CPE zu verwenden, das es unterstützt, müssen Sie:

  • Konfigurieren Sie jeden IPSec-Tunnel, um IKEv2 in der Oracle-Konsole zu verwenden. Siehe IPSec-Verbindung erstellen.
  • Konfigurieren Sie das CPE so, dass IKEv2-Verschlüsselungsparameter verwendet werden, die das CPE unterstützt. Eine Liste der von Oracle unterstützten Parameter finden Sie unter Unterstützte IPSec-Parameter.

Neue IPSec-Verbindung mit IKEv2

Hinweis

Wenn Sie eine neue IPSec-Verbindung manuell erstellen, können Sie IKEv2 beim Erstellen der IPSec-Verbindung in der Oracle-Konsole angeben.

Wenn Sie stattdessen den VPN-Schnellstartworkflow verwenden, wird die IPSec-Verbindung nur für IKEv1 konfiguriert. Nach Abschluss des Workflows können Sie jedoch die resultierenden IPSec-Tunnel in der Oracle-Konsole bearbeiten und ändern, dass sie IKEv2 verwenden.

Vorhandene IPSec-Verbindung auf IKEv2 upgraden

Wichtig

Es wird empfohlen, den folgenden Prozess für jeweils einen Tunnel auszuführen, um eine Unterbrechung einer IPSec-Verbindung zu vermeiden. Wenn die Verbindung nicht redundant ist (z.B. nicht über redundante Tunnel verfügt), müssen Sie mit einer Ausfallzeit rechnen, während Sie ein Upgrade auf IKEv2 durchführen.
  1. Ändern Sie die IKE-Version des Tunnels in der Oracle-Konsole, um IKEv2 und die zugehörigen Verschlüsselungsparameter zu verwenden, die das CPE unterstützt. Eine Liste der von Oracle unterstützten Parameter finden Sie unter Unterstützte IPSec-Parameter.
  2. Wenn die Sicherheitszuordnungen keine sofort neue Schlüssel erstellt haben, erzwingen sie ein Rekeying für den Tunnel auf dem CPE. Löschen Sie dazu die Sicherheitszuordnungen der Phase 1 und Phase 2, und warten Sie noch nicht, bis sie ablaufen. Einige CPE-Geräte warten, bis die Sicherheitszuordnungen ablaufen, bevor sie ein Rekeying ausführen. Durch Erzwingen der erneuten Schlüsselerstellung bestätigen Sie sofort, dass die Konfiguration der IKE-Version korrekt ist.
  3. Um dies zu prüfen, stellen Sie sicher, dass das Rekeying der Sicherheitszuordnungen für den Tunnel korrekt ausgeführt wird. Wenn nicht, bestätigen Sie, dass die korrekte IKE-Version in der Oracle-Konsole und auf dem CPE festgelegt ist, und dass das CPE die entsprechenden Parameter verwendet.

Nachdem Sie bestätigt haben, dass der erste Tunnel erneut hochgefahren wurde, wiederholen Sie die vorherigen Schritte für den zweiten Tunnel.

Von einem IPSec-Tunnel verwendetes Shared Secret ändern

Wenn Sie ein Site-to-Site-VPN einrichten, stellt Oracle standardmäßig das Shared Secret jedes Tunnels bereit (auch als Pre-Shared Key bezeichnet). Möglicherweise haben Sie ein bestimmtes Shared Secret, das Sie stattdessen verwenden möchten. Sie können das Shared Secret jedes Tunnels beim Erstellen der IPSec-Verbindung angeben, oder Sie können die Tunnel bearbeiten und die einzelnen neuen Shared Secrets dann bereitstellen. Für das Shared Secret sind nur Zahlen, Buchstaben und Leerzeichen zulässig. Wir empfehlen, für jeden Tunnel ein anderes Shared Secret zu verwenden.

Wichtig

Wenn Sie das Shared Secret eines Tunnels ändern, werden sowohl die gesamte IPSec-Verbindung als auch der Tunnel in den Status "Provisioning wird ausgeführt" versetzt, während der Tunnel mit dem neuen Shared Secret erneut bereitgestellt wird. Der andere Tunnel in der IPSec-Verbindung verbleibt im Status "Verfügbar". Sie können die Konfiguration des zweiten Tunnels jedoch nicht ändern, während der erste Tunnel neu bereitgestellt wird.

Schritte zum Ändern des Shared Secrets, das ein IPSec-Tunnel verwendet, finden Sie unter Details eines IPSec-Tunnels abrufen.

Site-to-Site-VPN überwachen

Mit Metriken, Alarmen und Benachrichtigungen können Sie den Zustand, die Kapazität und die Performance von Oracle Cloud Infrastructure-Ressourcen überwachen. Weitere Informationen finden Sie unter Monitoring und Notifications.

Informationen zum Monitoring einer Verbindung finden Sie unter Site-to-Site-VPN.

Site-to-Site-VPN-Logmeldungen

Sie können das Logging aktivieren und die Logmeldungen anzeigen, die für verschiedene betriebliche Aspekte von Site-to-Site-VPN generiert wurden, wie z.B. die Aushandlungen beim Hochfahren eines IPSec-Tunnels. Die Logmeldungen für Site-to-Site-VPN können über Site-to-Site-VPN oder den Logging-Service aktiviert und abgerufen werden.

  • Einen allgemeinen Überblick über den Logging-Service finden Sie unter Logging - Überblick.
  • Einzelheiten zum Aktivieren und Aufrufen der Logmeldungen für Site-to-Site-VPNs mit dem Logging-Service finden Sie unter Servicelogs.

  • Einzelheiten zum Schema der Site-to-Site-VPN-Logmeldung finden Sie unter Details zu Site-to-Site-VPN.

Informationen zum Aktivieren des Nachrichtenlogs finden Sie unter Verbindungsdetails für IPSec abrufen.

Informationen zum Anzeigen von Logmeldungen finden Sie unter Verbindungsdetails für IPSec abrufen.

IPSec-Verbindung oder CPE-Objekt in ein anderes Compartment verschieben

Sie können Ressourcen von einem Compartment in ein anderes verschieben. Nachdem Sie die Ressource in das neue Compartment verschoben haben, werden umgehend inhärente Policys wirksam, die sich auf den Zugriff auf die Ressource über die Konsole auswirken. Das Verschieben des CPE-Objekts in ein anderes Compartment wirkt sich nicht auf die Verbindung zwischen einem On-Premise-Data Center und Oracle Cloud Infrastructure aus. Weitere Informationen finden Sie unter Mit Compartments arbeiten.

Weitere Informationen finden Sie unter IPSec-Verbindung zwischen Compartments verschieben und CPE in ein anderes Compartment verschieben.

Verwalten von IPSec-Tunneln

Um die Sicherheit, Stabilität und Performance unseres Systems zu gewährleisten, aktualisiert Oracle Software regelmäßig auf der gesamten OCI-Plattform. Diese Updates umfassen kritische Korrekturen wie Schwachstellenpatches, neue Funktionen und Fehlerkorrekturen, was die allgemeine Funktionalität und Zuverlässigkeit verbessert. Während des Aktualisierungsprozesses wird ein IPSec-Tunnel von einem VPN-Headend zu einem anderen Headend verschoben, was dazu führt, dass die IPSec-Verbindung zurückgesetzt wird, wenn nur ein Tunnel verwendet wird. Es wird nur ein IPSec-Tunnel in einer IPSec-Verbindung verschoben. Obwohl wir diese kurze Unterbrechung des Tunnels nicht verhindern können, haben wir den Aktualisierungsmechanismus optimiert, um die Ausfallzeit zu minimieren. Wenn das Customer Premise Equipment (CPE) kontinuierlich versucht, die Verbindung wiederherzustellen, beträgt die normale IPSec-Tunnelausfallzeit unter einer Minute. Mit diesem Design kann Oracle das Gleichgewicht zwischen der Sicherheit und Zuverlässigkeit des Systems wahren und gleichzeitig die Unterbrechung der Konnektivität minimieren. Manchmal kann das Wiederherstellen des Tunnels IPSec bis zu 10 Minuten dauern:

  • Wenn der Tunnel nur auf OCI-Seite als Responder festgelegt ist und das CPE nicht versucht, den Tunnel sofort hochzufahren
  • Wenn das CPE nicht auf die von der OCI-Seite gestartete IKE-Aushandlung reagiert

Während die IPSec-Tunnelklappe bei Softwareupdates unvermeidbar ist, stellt OCI redundante Tunnel bereit. Diese redundanten Tunnel sind so konzipiert, dass sie einen kontinuierlichen Verkehrsfluss aufrechterhalten, selbst während der kurzen Zeit, in der ein Tunnel Ausfallzeiten erfährt. Wenn die Redundanz korrekt eingerichtet wurde, wechselt der gesamte Verkehr, der durch den primären Tunnel geleitet wird, während einer Tunnelklappe nahtlos zu dem redundanten Tunnel. Dieser Failover-Mechanismus stellt sicher, dass die Services ununterbrochen bleiben und der Verkehrsfluss ohne wesentliche Verzögerungen erhalten bleibt. OCI stellt sicher, dass die redundanten Tunnel auf zwei unterschiedlichen VPN-Headends landen. Während unserer Softwareupdates ist jeweils nur ein Tunnel betroffen.

Wir empfehlen und erwarten, dass Sie die Redundanz testen, indem Sie den primären VPN-Tunnel sowohl während der ersten Einrichtung als auch danach in regelmäßigen Abständen herunterfahren. Stellen Sie sicher, dass VCN-Instanzen erreichbar bleiben, während der primäre Tunnel offline ist und der Traffic in den redundanten Tunnel verlagert wird. Der Abschnitt "VPN-Redundanz" in diesem Redundanzhandbuch bietet einen besseren Einblick in die Einrichtung der Redundanz für VPN-Tunnel in verschiedenen Anwendungsfällen.

Mit den folgenden Schritten können Sie einen Tunnel selbst vorübergehend deaktivieren, um Redundanz-Failover von einem primären IPSec-Tunnel zu einem sekundären IPSec-Tunnel zu testen:

  1. Gehen Sie zur Seite mit den Tunneldetails, wie unter Aktualisieren eines IPSec-Tunnels beschrieben, und bearbeiten Sie das Shared Secret.
  2. So deaktivieren Sie einen Tunnel vorübergehend:
    1. Schneiden Sie den Text in das Shared Secret-Feld aus, und ersetzen Sie ihn durch einige zufällige Buchstaben oder Zahlen. Dadurch wird die BGP-Session heruntergefahren, und der Traffic kann durch Failover in den anderen Tunnel geleitet werden. Dieses Feld darf nicht leer sein.
      Fügen Sie die ursprüngliche Zeichenfolge in das Shared Secret-Feld in eine Textdatei ein. Damit können Sie die BGP-Session wiederherstellen, nachdem Sie bestätigt haben, dass die Redundanz wie erwartet funktioniert.
    2. Wählen Sie Speichern aus.
    3. Stellen Sie sicher, dass der Traffic noch im sekundären IPSec-Tunnel in der Verbindung fließt.
  3. So stellen Sie einen vorübergehend deaktivierten Tunnel wieder her:
    1. Gehen Sie zur Seite mit den Tunneldetails, wie unter Aktualisieren eines IPSec-Tunnels beschrieben, und bearbeiten Sie das Shared Secret.
    2. Fügen Sie den ursprünglichen Text in das Shared Secret-Feld ein.
    3. Wählen Sie Speichern aus.
    4. Warten Sie, bis die BGP-Session wiederhergestellt ist.