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 in einem 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 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 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.
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.
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.
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.
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.
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 Government Cloud und BGP-ASN von Oracle. Informationen zur United Kingdom Government Cloud finden Sie unter Regionen.
CPE-Konfiguration
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.
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 für das CPE nur IKEv2 und zugehörige IKEv2-Verschlüsselungsparameter konfigurieren, 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. In dieser Beispieldatei zeigt ein Kommentar, wie IKEv1 oder IKEv2 konfiguriert wird.
Konfigurationsprozess
Im folgenden Konfigurationsprozess wird beschrieben, wie ein routenbasierter Tunnel in Strongswan konfiguriert wird. Die VPN-Headends von Oracle verwenden routenbasierte Tunnel. Es wird empfohlen, Strongswan mit der Virtual Tunnel Interface-(VTI-)Konfigurationssyntax zu 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 der Schnittstelle aktivieren, damit Clients Traffic über Strongswan senden und empfangen werden 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 in Ihrer Schnittstelle (Zeilen 5 und 7) eth0 im folgenden Beispiel.
Wenn Sie verschiedene Schnittstellen verwenden, konfigurieren Sie 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. Entscheiden Sie die Werte, bevor Sie mit der Konfiguration fortfahren.
${cpeLocalIP}: Die IP-Adresse des Strongswan-Geräts.${cpePublicIpAddress}: Die öffentliche IP-Adresse für Strongswan, auch die IP-Adresse der 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 von Oracle bereitgestellten Pre-Shared Keystore verwenden oder Ihren eigene 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 von Oracle bereitgestellten Pre-Shared Keystore verwenden oder Ihren eigene Schlüssel angeben, wenn Sie die IPSec-Verbindung in der Oracle-Konsole einrichten.${vcnCidrNetwork}: VCN-IP-Bereich.
Die Strongswan-Konfiguration verwendet das Konzept von links und rechts, um die Konfigurationsparameter für ein lokales 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: Das lokale Strongswan-CPE
- rechts: Das Oracle-VPN-Headend
Verwenden Sie die folgende Vorlage für das Verzeichnis /etc/strongswan/ipsec.conf. Die Datei definiert die beiden Tunnel, die Oracle erstellt, wenn Sie die IPSec-Verbindung einrichten.
Wenn sich das CPE hinter einem Eins-zu-Eins-NAT-Gerät befindet, entfernen Sie die Kommentarzeichen für den Parameter leftid, und setzen Sie ihn auf ${cpePublicIpAddress}.
# 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 das Verzeichnis /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 die CPE hinter einem NAT-Gerät befindet.-
<mark>muss mit dem für die Verbindung konfigurierten Zeichen übereinstimmen.
Nachdem Sie die VTI erstellt hat, muss sie aktiviert sein (verwenden Sie die Datei ip link set <name> up), und Sie können 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
Nachdem Sie die Konfigurations- und Secret-Dateien eingerichtet haben, müssen Sie den Strongswan-Service erneut starten. 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 ü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.
Statische Routen, die mit dem Befehl "IP route" erstellt werden, werden durch einen Neustart nicht persistiert. Wie Sie die Routen beibehalten, 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.
Sie können auch das OCI-Logging aktivieren, um Zugriff auf VPN-Logs zu erhalten.
Status der Tunnelschnittstelle prüfen
Überprü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 in Zukunft ein Supportticket zu Oracle über den Strongswan-Tunnel öffnen müssen, fügen Ihnen 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
Wir empfehlen die Verwendung von Quagga zur Konfiguration von BGP. Verwenden Sie zum Installieren von Quagga den folgenden Oracle Linux-Befehl. (Wenn Sie eine andere Linux-Distribution verwendet, variieren die 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 des On-Premise-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