Strongswan
Strongswan ist eine IPsec-basierte Open-Source-VPN-Lösung. Die meisten Linux-Distributionen enthalten Strongswan oder ermöglichen eine einfache Installation. Die Installation kann auf Hosts in einem On-Premise-Netzwerk oder Cloud-Providernetzwerk ausgeführt werden.
Dieses Thema enthält Informationen zur Konfiguration für ein CPE, auf dem Strongswan ausgeführt wird. Die Strongswan 5.x-Verzweigung unterstützt die Schlüsselaustauschprotokolle IKEv1 und IKEv2 mit dem nativen NETKEY-IPsec-Stack des Linux-Kernels.
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.
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 in diesem Diagramm verwendeten IP-Adressen dienen lediglich als Beispiel.
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 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.
Hinweise und Einschränkungen
In diesem Abschnitt werden die allgemeinen wichtigen 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.
Routenbasiertes oder policybasiertes Site-to-Site-VPN
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.
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.
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.
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
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.
Strongswan-Standardkonfigurationsdateien
Bei der standardmäßigen Strongswan-Installation werden die folgenden Dateien erstellt:
etc/strongswan/ipsec.conf: Root der Strongswan-Konfiguration./etc/strongswan/ipsec.secrets: Root des Speicherorts, in dem Strongswan nach Secrets (Tunnel-Pre-Shared Keys) sucht.
Die Standarddatei etc/strongswan/ipsec.conf enthält die folgende Zeile:
Include /etc/strongswan/*.confDie Standarddatei etc/strongswan/ipsec.secrets enthält die folgende Zeile:
include /etc/strongswan/ipsec.d/*.secretsDie vorherigen Zeilen führen automatisch alle .conf- und .secrets-Dateien im Verzeichnis /etc/strongswan in den Hauptkonfigurations- und Secrets-Dateien zusammen, die Strongswan 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 Ihr 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 enthält einen Kommentar zur Konfiguration von IKEv1 und IKEv2.
Konfigurationsprozess
Im folgenden Konfigurationsprozess wird beschrieben, wie ein routenbasierter Tunnel in Strongswan konfiguriert wird. Die VPN-Headends von Oracle verwenden routenbasierte Tunnel. Oracle empfiehlt, dass Sie Strongswan 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.
Je nach verwendeter Linux-Distribution müssen Sie möglicherweise die IP-Weiterleitung auf Ihrer Schnittstelle aktivieren, damit Clients Traffic über Strongswan 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 Ihre Schnittstelle (Zeilen 5 und 7).
Wenn Sie mehrere Schnittstellen verwenden, konfigurieren Sie auch die Zeilen 5 und 7 für diese Schnittstelle.
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.ens3.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.ens3.accept_redirects = 0
In der Strongswan-Konfiguration werden die folgenden Variablen verwendet. Ermitteln Sie die Werte, bevor Sie mit der Konfiguration fortfahren.
${cpeLocalIP}: IP-Adresse Ihres Strongswan-Geräts.${cpePublicIpAddress}: Die öffentliche IP-Adresse für Strongswan, auch die IP-Adresse Ihrer externen Schnittstelle. Je nach 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.${sharedSecret1}: Pre-Shared Key für den ersten Tunnel. Sie können den standardmäßig von Oracle bereitgestellten Pre-Shared Key verwenden oder Ihren eigenen Schlüssel angeben, wenn Sie die IPSec-Verbindung 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 Ihren eigenen Schlüssel angeben, wenn Sie die IPSec-Verbindung in der Oracle-Konsole einrichten.${vcnCidrNetwork}: VCN-IP-Bereich.
Bei der Strongswan-Konfiguration wird das Konzept von links und rechts verwendet, um die Konfigurationsparameter für das lokale CPE-Gerät und das Remotegateway zu definieren. Beide Seiten der Verbindung (conn in der Strongswan-Konfiguration) können links oder rechts sein, die Konfiguration für diese Verbindung muss jedoch konsistent sein. In diesem Beispiel:
- links: Ihr lokales Strongswan-CPE
- rechts: Das Oracle-VPN-Headend
Verwenden Sie die folgende Vorlage für die Datei /etc/strongswan/ipsec.conf. Die Datei definiert die beiden Tunnel, die Oracle erstellt, wenn Sie die IPSec-Verbindung einrichten.
Wenn Ihr CPE sich hinter einem 1-1 NAT-Gerät befindet, entfernen Sie den Parameter leftid, und setzen Sie ihn mit dem Wert ${cpePublicIpAddress} gleich.
# basic configuration
config setup
conn %default
ikelifetime=28800s
keylife=3600s
rekeymargin=3m
keyingtries=%forever
mobike=no
ike=aes256-sha2_384-ecp384!
esp=aes256gcm16-modp1536!
conn oci-tunnel-1
left=${cpeLocalIP}
#leftid=${cpePublicIpAddress} # See preceding note about 1-1 NAT device
leftsubnet=0.0.0.0/0
leftauth=psk
right=${oracleHeadend1}
rightid=${oracleHeadend1}
rightsubnet=0.0.0.0/0
rightauth=psk
type=tunnel
keyexchange=ikev1 # To use IKEv2, change to ikev2
auto=start
dpdaction=restart
mark=13 # Needs to be unique across all tunnels
conn oci-tunnel-2
left={cpeLocalIP}
#leftid=${cpePublicIpAddress}
leftsubnet=0.0.0.0/0
leftauth=psk
right=${oracleHeadend2}
rightid=${oracleHeadend2}
rightsubnet=0.0.0.0/0
rightauth=psk
type=tunnel
keyexchange=ikev1 # To use IKEv2, change to ikev2
auto=start
dpdaction=restart
mark=14 # Needs to be unique across all tunnels
Anweisungen wie ike= und esp= können für bestimmte Parameter basierend auf den unterstützten IPsec-Parametern geändert werden.
Verwenden Sie die folgende Vorlage für die Datei /etc/strongswan/ipsec.secrets . Sie enthält zwei Zeilen pro IPSec-Verbindung (eine Zeile pro Tunnel).
${cpePublicIpAddress} ${oracleHeadend1}: PSK "${sharedSecret1}"
${cpePublicIpAddress} ${oracleHeadend2}: PSK "${sharedSecret2}"
Mit dem folgenden Befehl wird eine VTI-Schnittstelle mit dem definierten Namen erstellt und über lokale und Remote-IPs an den Tunnel gebunden.
ip tunnel add <name> local <local IP> remote <remote IP> mode vti key <mark><name>kann ein beliebiger gültiger Gerätename sein (ipsec0, vti0 usw.). Der ip-Befehl behandelt Namen, die mitvtibeginnen, in einigen Instanzen als besonders (z.B. beim Abrufen von Gerätestatistiken). Die IP-Adressen sind die Endpunkte des IPsec-Tunnels. Eine private IP kann verwendet werden, wenn sich das CPE hinter einem NAT-Gerät befindet.-
<mark>muss mit der für die Verbindung konfigurierten Markierung übereinstimmen.
Nachdem Sie die VTI erstellt haben, muss sie aktiviert sein (verwenden Sie ip link set <name> up). Anschließend können Sie Routen installieren und Routingprotokolle verwenden, wie im folgenden Beispiel dargestellt.
ip tunnel add vti1 mode vti local 10.0.3.78 remote 193.123.68.187 key 13
ip link set vti1 upDie Option für die Routeninstallation durch den IKE-Daemon muss deaktiviert werden. Ändern Sie dazu charon.conf wie gezeigt.
Directory - /etc/strongswan/strongswan.d/Charon.conf
#Uncomment below statement
install_routes = no
Nach der Einrichtung der Konfigurations- und Secret-Dateien muss der Strongswan-Service erneut gestartet werden. Verwenden Sie den folgenden Befehl:
Strongswan restart
Ein Neustart des Strongswan-Service kann sich auf vorhandene Tunnel auswirken.
Verwenden Sie den folgenden ip-Befehl, um statische Routen zu erstellen, die den Traffic über die IPSec-Tunnel an das VCN senden. Wenn Sie mit einem nicht berechtigten Benutzeraccount angemeldet sind, müssen Sie vor dem Befehl möglicherweise sudo verwenden.
Statische Routen, die mit dem Befehl "ip route" erstellt werden, werden nicht durch einen Neustart persistiert. In der Dokumentation Ihrer Linux-Distribution finden Sie weitere Informationen dazu, wie Ihre Routen beibehalten werden können.
ip route add ${VcnCidrBlock} nexthop dev ${vti1} nexthop dev ${vti2}
ip route show
Verifizierung
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.
Sie können auch das OCI-Logging aktivieren, um Zugriff auf VPN-Logs zu erhalten.
Status der Tunnelschnittstelle prüfen
Prüfen Sie den aktuellen Status der Strongswan-Tunnel mit dem folgenden Befehl.
strongswan statusWenn die zurückgegebene Ausgabe dem folgenden Beispiel ähnelt, wird der Tunnel eingerichtet.
oci-tunnel-1[591]: ESTABLISHED 43 minutes ago, 10.0.3.78[129.148.216.212]...193.123.68.187[193.123.68.187]
oci-tunnel-1{399}: INSTALLED, TUNNEL, reqid 102, ESP in UDP SPIs: ce6a1525_i 4829c65c_o
oci-tunnel-1{399}: 0.0.0.0/0 === 0.0.0.0/0
Wenn Sie zu einem späteren Zeitpunkt ein Oracle-Supportticket zu Ihrem Strongswan-Tunnel erstellen müssen, fügen Sie dem Ticket die gesamte Ausgabe des Befehls strongswan status 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 Strongswan-Implementierung, in der die verfügbaren VTIs angezeigt werden.
ifconfig
<output trimmed>
vti1: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 8980
inet 10.10.10.1 netmask 255.255.255.252 destination 10.10.10.1
inet6 fe80::5efe:a00:34e prefixlen 64 scopeid 0x20<link>
tunnel txqueuelen 1000 (IPIP Tunnel)
RX packets 69209 bytes 4050022 (3.8 MiB)
RX errors 54 dropped 54 overruns 0 frame 0
TX packets 50453 bytes 3084997 (2.9 MiB)
TX errors 1016 dropped 0 overruns 0 carrier 1016 collisions 0
vti2: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 8980
inet 192.168.10.1 netmask 255.255.255.252 destination 192.168.10.1
inet6 fe80::5efe:a00:34e prefixlen 64 scopeid 0x20<link>
tunnel txqueuelen 1000 (IPIP Tunnel)
RX packets 101256 bytes 6494872 (6.1 MiB)
RX errors 12 dropped 12 overruns 0 frame 0
TX packets 70023 bytes 4443597 (4.2 MiB)
TX errors 2142 dropped 0 overruns 0 carrier 2142 collisions 0
Beispiel für die ip link show-Ausgabe:
ip link show
<output trimmed>
vti2@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8980 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ipip 10.0.3.78 peer 139.185.34.172
14: vti1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8980 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ipip 10.0.3.78 peer 193.123.68.187
Dynamisches Routing mit Strongswan konfigurieren
Oracle empfiehlt die Verwendung von Quagga zur Konfiguration von BGP. Verwenden Sie zur Installation von Quagga den folgenden Oracle Linux-Befehl (wenn Sie eine andere Linux-Distribution verwenden, variieren Ihre Befehle möglicherweise etwas):
sudo yum -y install quaggaÄndern Sie die Zebra-Konfiguration (/etc/quagga/zebra.conf), um die VTI-IP-Adresse zu definieren, die erforderlich ist, weil BGP Peering verwendet. Definieren Sie die folgenden Variablen für Zebra:
${vti_name1}: Name der ersten verwendeten VTI. Beispiel: vti1.${vti_name2}: Name der zweiten verwendeten VTI. Beispiel: vti2.${vti_ipaddress1}: Die IP-Adresse, die der ersten verwendeten VTI zugewiesen ist.${vti_ipaddress2}: Die IP-Adresse, die der zweiten verwendeten VTI zugewiesen ist.${local_subnet}: Das lokale CPE-Subnetz.
Diese Variablen werden im folgenden Konfigurationsdateiauszug verwendet:
!
hostname strongswan-centos
log file /var/log/quagga/quagga.log
!
interface ens3
ipv6 nd suppress-ra
!
interface ens5
ipv6 nd suppress-ra
!
interface lo
!
interface <Vti_name1>
ip address ${vti_ipaddress1}
ipv6 nd suppress-ra
!
interface <Vti_name2>
ip address ${vti_ipaddress2}
ipv6 nd suppress-ra
!
ip route ${local_subnet} <Vti_name1>
ip route ${local_subnet} <Vti_name2>
!
ip forwarding
!
!
line vty
!
Die bgpd-Konfigurationsdatei ist auch für die BGP-Konfiguration erforderlich. Definieren Sie die folgenden Variablen für bgpd:
${LOCAL_ASN}: Die BGP-ASN Ihres lokalen Netzwerks.${router-id_ipaddress}: Die BGP-ID des lokalen Netzwerks.${local_subnet}: Das lokale Subnetz, das angeboten werden soll.${bgp_peer-IP _network}: /30-CIDR für das Peer-IP-Netzwerk in OCI.${neighbor_peer_ip_address}: Die OCI-BGP-Peer-IP-Adresse.
Diese Variablen werden im folgenden Konfigurationsdateiauszug aus /etc/quagga/bgpd.conf verwendet:
hostname <host-name>
router bgp ${LOCAL_ASN}
bgp router-id ${router-id_ipaddress}
network ${bgp_peer-ip _network}
network ${bgp_peer-ip _network}
network ${local_subnet}
neighbor ${neighbour_peer_ip_address} remote-as 31898
neighbor ${neighbour_peer_ip_address} ebgp-multihop 255
neighbor ${neighbour_peer_ip_address} next-hop-self
neighbor ${neighbour_peer_ip_address} remote-as 31898
neighbor ${neighbour_peer_ip_address} ebgp-multihop 255
neighbor ${neighbour_peer_ip_address} next-hop-self
log file bgpd.log
log stdout
Damit Strongswan Routen und virtuelle IPs verwenden kann, müssen Sie /etc/strongswan/strongswan.d/Charon.conf ändern.
Entfernen Sie die Kommentare für die Zeilen mit #install_routes = yes und #install_virtual_ip = yes, und ändern Sie die Werte wie folgt in "no":
#Tunnels
install_routes = no
#Install virtual IP addresses.
install_virtual_ip = no
Mit den folgenden Befehlen können Sie den Service für Zebra und BGPD aktivieren und starten:
systemctl start zebra
systemctl enable zebra
systemctl start bgpd
systemctl enable bgpd