strongSwan
strongSwan est une solution VPN open source basée sur une connexion IPSec. La plupart des distributions Linux incluent strongSwan ou facilitent son installation. Vous pouvez l'installer sur des hôtes dans votre réseau sur site ou sur le réseau d'un fournisseur cloud.
Cette rubrique propose une configuration pour un CPE exécutant strongSwan. La branche strongSwan 5.x prend en charge les protocoles d'échange de clés IKEv1 et IKEv2 avec la pile IPSec NETKEY native du noyau Linux.
Oracle fournit des instructions de configuration pour un ensemble testé de vendeurs et de dispositifs. Utilisez la configuration qui convient à votre fournisseur et à votre version du logiciel.
Si la version du dispositif ou du logiciel qu'Oracle utilise pour vérifier la configuration ne correspond pas exactement à votre dispositif ou logiciel, vous pouvez néanmoins créer la configuration nécessaire sur votre dispositif. Consultez la documentation de votre fournisseur et effectuez tous les ajustements nécessaires.
Si votre dispositif correspond à un fournisseur ne figurant pas dans la liste des fournisseurs et des dispositifs vérifiés, ou si vous savez déjà configurer votre dispositif pour IPSec, consultez la liste des paramètres IPSec pris en charge et la documentation de votre fournisseur afin d'obtenir de l'aide.
Oracle Cloud Infrastructure offre un VPN site à site, connexion IPSec sécurisée entre votre réseau sur site et un réseau cloud virtuel.
Le diagramme suivant présente une connexion IPSec de base à Oracle Cloud Infrastructure avec des tunnels redondants. Les adresses IP utilisées dans ce diagramme sont fournies à titre d'exemple uniquement.
Meilleures pratiques
Cette section présente les remarques et les meilleures pratiques générales relatives à l'utilisation d'un VPN site à site.
Configuration de tous les tunnels pour chaque connexion IPSec
Oracle déploie deux têtes de réseau IPSec pour chacune de vos connexions afin d'offrir une haute disponibilité à vos charges globales stratégiques. Côté Oracle, ces deux têtes de réseau se trouvent sur des routeurs différents à des fins de redondance. Pour une redondance maximale, Oracle recommande de configurer tous les tunnels disponibles. Il s'agit d'une notion clé de la philosophie "Design for Failure".
Présence de CPE redondants dans les emplacements réseau sur site
Chacun de vos sites se connectant à Oracle Cloud Infrastructure via IPSec doit disposer de dispositifs en périphérie redondants (également appelés CPE, pour Customer-Premises Equipment). Vous ajoutez chaque CPE à la console Oracle et créez une connexion IPSec distincte entre la passerelle de routage dynamique et chaque CPE. Pour chaque connexion IPSec, Oracle fournit deux tunnels sur des têtes de réseau IPSec géographiquement redondantes. Pour plus d'informations, reportez-vous au guide pour la redondance de la connectivité (PDF).
Remarques concernant le protocole de routage
Lorsque vous créez une connexion IPSec de VPN site à site, cette dernière possède deux tunnels IPSec redondants. Oracle vous recommande de configurer le CPE de manière à ce qu'il utilise les deux tunnels (s'il prend en charge cette configuration). Par le passé, Oracle a créé des connexions IPSec comportant jusqu'à quatre tunnels IPSec.
Les trois types de routage suivants sont disponibles. Vous choisissez le type de routage de chaque tunnel du VPN site à site séparément :
- Routage dynamique BGP : les routages disponibles sont appris dynamiquement via BGP. La passerelle de routage dynamique apprend dynamiquement les routages à partir du réseau sur site. Côté Oracle, la passerelle de routage dynamique publie les sous-réseaux du réseau cloud virtuel.
- Routage statique : lorsque vous configurez la connexion IPSec à la passerelle de routage dynamique, vous indiquez les routages spécifiques vers le réseau sur site que le réseau cloud virtuel doit connaître. Vous devez également configurer votre dispositif CPE avec des routages statiques vers les sous-réseaux du réseau cloud virtuel. Ces routages ne sont pas appris dynamiquement.
- Routage basé sur une stratégie : lorsque vous configurez la connexion IPSec à la passerelle de routage dynamique, vous indiquez les routages spécifiques vers le réseau sur site que le réseau cloud virtuel doit connaître. Vous devez également configurer votre dispositif CPE avec des routages statiques vers les sous-réseaux du réseau cloud virtuel. Ces routages ne sont pas appris dynamiquement.
Pour obtenir plus d'informations sur le routage avec un VPN site à site, notamment des recommandations Oracle sur la façon d'utiliser l'algorithme de sélection du meilleur chemin BGP, reportez-vous à Routage du VPN site à site.
Autres configurations de CPE importantes
Assurez-vous que les listes d'accès sur le CPE sont configurées correctement afin de ne pas bloquer le trafic nécessaire depuis et vers Oracle Cloud Infrastructure.
Si plusieurs tunnels fonctionnent simultanément, le routage peut être asymétrique. Afin d'autoriser le routage asymétrique, assurez-vous que le CPE est configuré pour gérer le trafic provenant de votre réseau cloud virtuel sur l'un des tunnels. Par exemple, vous devez désactiver l'inspection ICMP, configurer le contournement de l'état TCP. Pour plus d'informations sur la configuration appropriée, contactez le support technique du fournisseur du CPE. Pour configurer le routage de sorte qu'il soit symétrique, reportez-vous à Routage du VPN site à site.
Avertissements et limites
Cette section présente les caractéristiques et les limites générales importantes du VPN site à site. Reportez-vous à Limites de service pour obtenir la liste des limites applicables et consulter les instructions permettant de demander une augmentation de limite.
Routage asymétrique
Oracle utilise un routage asymétrique sur les différents tunnels qui constituent la connexion IPSec. Configurez les pare-feu en conséquence. Sinon, les tests ping ou le trafic d'application sur la connexion ne fonctionnent pas de façon fiable.
Lorsque vous utilisez plusieurs tunnels vers Oracle Cloud Infrastructure, Oracle vous recommande de configurer votre routage de façon à acheminer le trafic de manière déterministe via le tunnel préféré. Si vous souhaitez utiliser un tunnel IPSec comme tunnel principal et un autre comme tunnel de sauvegarde, configurez des routages plus spécifiques pour le tunnel principal (BGP) et des routages moins spécifiques (récapitulatifs ou par défaut) pour le tunnel de sauvegarde (BGP/statique). Sinon, si vous publiez le même routage (par exemple, un routage par défaut) via tous les tunnels, le trafic renvoyé du réseau cloud virtuel vers le réseau sur site est acheminé vers n'importe lequel des tunnels disponibles. En effet, Oracle utilise un routage asymétrique.
Pour consulter des recommandations de routage Oracle spécifiques sur la façon de forcer le routage symétrique, reportez-vous à Routage du VPN site à site.
VPN site à site basé sur un routage ou sur une stratégie
Le protocole IPSec utilise des associations de sécurité pour déterminer comment crypter les paquets. Au sein de chaque association de sécurité, vous définissez des domaines de cryptage pour mettre en correspondance le type de protocole et les adresses IP source et de destination d'un paquet avec une entrée de la base de données d'association de sécurité afin de définir le mode de cryptage ou de décryptage du paquet.
Les termes ID de proxy, index de paramètre de sécurité (SPI) ou sélecteur de trafic peuvent être utilisés par d'autres fournisseurs ou dans la documentation du secteur pour faire référence aux associations de sécurité ou aux domaines de cryptage.
Il existe deux méthodes générales pour l'implémentation des tunnels IPSec :
- Tunnels basés sur un routage : également appelés tunnels basés sur le saut suivant. Une recherche de table de routage est effectuée sur l'adresse IP de destination d'un paquet. Si l'interface sortante du routage est un tunnel IPSec, le paquet est crypté et envoyé à l'autre extrémité du tunnel.
- Tunnels basés sur une stratégie : le protocole et les adresses IP source et de destination du paquet sont mis en correspondance avec la liste des instructions de stratégie. Si une correspondance est trouvée, le paquet est crypté selon les règles de l'instruction de stratégie.
Les têtes de réseau du VPN site à site Oracle utilisent des tunnels basés sur un routage. Elles peuvent fonctionner avec des tunnels basés sur une stratégie, mais cela donne lieu à des avertissements, répertoriés dans les sections suivantes.
Si le CPE est derrière un dispositif NAT
En général, l'identificateur IKE CPE configuré au niveau de votre extrémité de la connexion doit correspondre à celui utilisé par Oracle. Par défaut, Oracle utilise l'adresse IP publique du CPE, que vous fournissez lors de la création de l'objet CPE dans la console Oracle. Toutefois, si le CPE se trouve derrière un dispositif NAT, l'identificateur IKE CPE configuré de votre côté peut être l'adresse IP privée du CPE, comme indiqué dans le diagramme suivant.
Certaines plates-formes CPE ne vous autorisent pas à modifier l'identificateur IKE local. Si c'est le cas, vous devez modifier l'ID IKE distant dans la console Oracle pour qu'il corresponde à l'ID IKE local de votre CPE. Vous pouvez fournir cette valeur lors de la configuration de la connexion IPSec ou ultérieurement en modifiant cette dernière. Oracle s'attend à ce que la valeur soit une adresse IP ou un nom de domaine qualifié complet tel que cpe.example.com. Pour obtenir des instructions, reportez-vous à Modification de l'identificateur IKE CPE utilisé par Oracle.
Paramètres IPSec pris en charge
Pour obtenir la liste des paramètres IPSec pris en charge (indépendamment du fournisseur) pour toutes les régions, reportez-vous à Paramètres IPSec pris en charge.
Le numéro ASN BGP Oracle pour le domaine de cloud commercial est 31898. Si vous configurez un VPN site à site pour US Government Cloud, reportez-vous à Paramètres de VPN site à site requis pour Government Cloud et à Numéro ASN BGP d'Oracle. Pour United Kingdom Government Cloud, reportez-vous à Numéro ASN BGP d'Oracle.
Configuration du CPE
Les instructions de configuration de cette section sont fournies par Oracle Cloud Infrastructure pour votre CPE. Si vous avez besoin d'une aide supplémentaire, contactez directement le support technique du fournisseur du CPE.
La figure suivante illustre la disposition de base de la connexion IPSec.
Fichiers de configuration strongSwan par défaut
L'installation par défaut de strongSwan crée les fichiers suivants :
etc/strongswan/ipsec.conf: racine de la configuration strongSwan./etc/strongswan/ipsec.secrets: racine de l'emplacement où strongSwan recherche les clés secrètes (les clés prépartagées du tunnel).
Le fichier etc/strongswan/ipsec.conf par défaut inclut la ligne suivante :
Include /etc/strongswan/*.confLe fichier etc/strongswan/ipsec.secrets par défaut inclut la ligne suivante :
include /etc/strongswan/ipsec.d/*.secretsLes lignes précédentes fusionnent automatiquement tous les fichiers .conf et .secrets du répertoire /etc/strongswan dans les fichiers de configuration et de clés secrètes principaux utilisés par strongSwan.
A propos de l'utilisation d'IKEv2
Oracle prend en charge Internet Key Exchange version 1 (IKEv1) et version 2 (IKEv2). Si vous configurez la connexion IPSec dans la console pour qu'elle utilise IKEv2, vous devez configurer le CPE afin qu'il utilise uniquement IKEv2 et les paramètres de cryptage IKEv2 associés pris en charge par votre CPE. Pour obtenir la liste des paramètres pris en charge par Oracle pour IKEv1 ou IKEv2, reportez-vous à Paramètres IPSec pris en charge.
La version IKE est spécifiée lors de la configuration du fichier de configuration IPSec dans la tâche 3 de la section suivante. Dans cet exemple de fichier, il existe un commentaire expliquant comment configurer IKEv1 et IKEv2.
Processus de configuration
Le processus de configuration suivant explique comment configurer un tunnel basé sur un routage sur strongSwan. Les têtes de réseau du VPN Oracle utilisent des tunnels basés sur un routage. Oracle recommande de configurer strongSwan avec la syntaxe de configuration d'interface de tunnel virtuel.
Pour plus de détails sur les paramètres spécifiques utilisés dans ce document, reportez-vous à Paramètres IPSec pris en charge.
Selon la distribution Linux que vous utilisez, vous devrez peut-être activer le transfert IP sur votre interface pour permettre aux clients d'envoyer et de recevoir du trafic via strongSwan. Dans le fichier /etc/sysctl.conf, définissez les valeurs suivantes et appliquez les mises à jour avec sudo sysctl -p.
Si vous utilisez une interface autre qu'eth0, remplacez eth0 dans l'exemple suivant par votre interface (lignes 5 et 7).
Si vous utilisez plusieurs interfaces, configurez également les lignes 5 et 7 pour cette interface.
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
La configuration strongSwan utilise les variables suivantes. Déterminez les valeurs avant de procéder à la configuration.
${cpeLocalIP}: adresse IP de votre appareil strongSwan.${cpePublicIpAddress}: adresse IP publique de strongSwan. Il s'agit également de l'adresse IP de votre interface externe. Selon la topologie du réseau, la valeur peut être différente de${cpeLocalIP}.${oracleHeadend1}: pour le premier tunnel, adresse IP publique Oracle obtenue à partir de la console Oracle.${oracleHeadend2}: pour le deuxième tunnel, adresse IP publique Oracle obtenue à partir de la console Oracle.${sharedSecret1}: clé prépartagée du premier tunnel. Vous pouvez utiliser la clé prépartagée par défaut fournie par Oracle ou indiquer votre propre clé lors de la configuration de la connexion IPSec dans la console Oracle.${sharedSecret2}: clé prépartagée du deuxième tunnel. Vous pouvez utiliser la clé prépartagée par défaut fournie par Oracle ou indiquer votre propre clé lors de la configuration de la connexion IPSec dans la console Oracle.${vcnCidrNetwork}: plage d'adresses IP du réseau cloud virtuel.
La configuration strongSwan utilise le concept de gauche et de droite pour définir les paramètres de configuration de l'appareil CPE local et de la passerelle distante. Chaque côté de la connexion (appelée conn dans la configuration strongSwan) peut être un côté gauche ou droit, mais la configuration de cette connexion doit être cohérente. Dans cet exemple :
- left : CPE strongSwan local
- right : tête de réseau du VPN Oracle
Utilisez le modèle suivant pour votre fichier /etc/strongswan/ipsec.conf. Le fichier définit les deux tunnels créés par Oracle lors de la configuration de la connexion IPSec.
Si le CPE se trouve derrière un appareil NAT 1 à 1, annulez la mise en commentaire du paramètre leftid et définissez-le sur ${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
Des instructions telles que ike= et esp= peuvent être modifiées pour des paramètres spécifiques en fonction des paramètres IPSec pris en charge.
Utilisez le modèle suivant pour votre fichier /etc/strongswan/ipsec.secrets. Il contient deux lignes par connexion à IPSec (une ligne par tunnel).
${cpePublicIpAddress} ${oracleHeadend1}: PSK "${sharedSecret1}"
${cpePublicIpAddress} ${oracleHeadend2}: PSK "${sharedSecret2}"
La commande suivante crée une interface de tunnel virtuel portant le nom défini et la lie au tunnel à l'aide d'adresses IP locales et distantes.
ip tunnel add <name> local <local IP> remote <remote IP> mode vti key <mark><name>peut être n'importe quel nom d'appareil valide (ipsec0, vti0, etc.). La commande ip considère les noms commençant parvticomme spéciaux dans certaines instances (par exemple lors de l'extraction des statistiques d'appareil). Les adresses IP sont les adresses du tunnel IPSec. Une adresse IP privée peut être utilisée lorsque le CPE se trouve derrière un appareil NAT.-
<mark>doit correspondre à la marque configurée pour la connexion.
Une fois l'interface de tunnel virtuel créée, elle doit être activée (utilisez ip link set <name> up). Vous pouvez ensuite installer des routages et utiliser des protocoles de routage comme indiqué dans l'exemple suivant.
ip tunnel add vti1 mode vti local 10.0.3.78 remote 193.123.68.187 key 13
ip link set vti1 upL'installation du routage par le démon IKE doit être désactivée. Pour ce faire, modifiez charon.conf comme indiqué.
Directory - /etc/strongswan/strongswan.d/Charon.conf
#Uncomment below statement
install_routes = no
Après avoir configuré vos fichiers de configuration et de clés secrètes, vous devez redémarrer le service strongSwan. Pour ce faire, utilisez la commande suivante :
Strongswan restart
Le redémarrage du service strongSwan peut avoir une incidence sur les tunnels existants.
Utilisez la commande ip suivante pour créer des routages statiques qui envoient le trafic vers votre réseau cloud virtuel par le biais des tunnels IPSec. Si vous êtes connecté avec un compte utilisateur sans privilège, vous devrez peut-être utiliser sudo avant la commande.
Les routages statiques créés avec la commande de routage IP ne sont pas persistants en cas de redémarrage. Pour savoir comment rendre vos routages persistants, reportez-vous à la documentation de votre distribution Linux.
ip route add ${VcnCidrBlock} nexthop dev ${vti1} nexthop dev ${vti2}
ip route show
Vérification
Le service Monitoring est également disponible auprès d'Oracle Cloud Infrastructure pour surveiller de façon active et passive vos ressources cloud. Pour plus d'informations sur la surveillance du VPN site à site, reportez-vous à Mesures de VPN site à site.
Si vous rencontrez des problèmes, reportez-vous à Dépannage de VPN site à site.
Vous pouvez également activer la journalisation OCI pour accéder à des journaux VPN.
Vérification du statut de l'interface de tunnel
Vérifiez l'état actuel des tunnels Strongswan à l'aide de la commande suivante.
strongswan statusSi la sortie renvoyée est semblable à l'exemple suivant, le tunnel est établi.
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
Si vous devez plus tard créer un ticket d'assistance auprès d'Oracle pour votre tunnel strongSwan, incluez la sortie complète de la commande strongswan status.
Vérification du statut de l'interface de tunnel
Vérifiez que les interfaces de tunnel virtuel sont démarrées ou arrêtées à l'aide de la commande ifconfig ou ip link show. Vous pouvez également utiliser des applications telles que tcpdump avec les interfaces.
Voici un exemple de sortie ifconfig avec une implémentation strongSwan fonctionnelle indiquant les interfaces de tunnel virtuel disponibles.
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
Voici un exemple de sortie ip link show :
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
Configuration du routage dynamique avec strongSwan
Oracle recommande d'utiliser Quagga pour configurer BGP. Pour installer Quagga, utilisez la commande Oracle Linux suivante (si vous utilisez une autre distribution Linux, les commandes peuvent varier légèrement) :
sudo yum -y install quaggaModifiez la configuration de zebra (/etc/quagga/zebra.conf) pour définir l'adresse IP d'interface de tunnel virtuel. BGP utilisant l'appairage, cette dernière est en effet requise. Définissez les variables suivantes pour zebra :
${vti_name1}: nom de la première interface de tunnel virtuel utilisée. Par exemple, vti1.${vti_name2}: nom de la seconde interface de tunnel virtuel utilisée. Par exemple, vti2.${vti_ipaddress1}: adresse IP allouée à la première interface de tunnel virtuel utilisée.${vti_ipaddress2}: adresse IP allouée à la seconde interface de tunnel virtuel utilisée.${local_subnet}: sous-réseau de CPE local.
Ces variables sont utilisées dans l'extrait de fichier de configuration suivant :
!
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
!
Le fichier de configuration bgpd est également requis pour la configuration de BGP. Définissez les variables suivantes pour bgpd :
${LOCAL_ASN}: numéro ASN BGP du réseau local.${router-id_ipaddress}: ID BGP du réseau local.${local_subnet}: sous-réseau local devant être publié.${bgp_peer-ip _network}: CIDR /30 du réseau IP homologue dans OCI.${neighbor_peer_ip_address}: adresse IP de l'homologue BGP OCI.
Ces variables sont utilisées dans l'extrait suivant du fichier de configuration /etc/quagga/bgpd.conf :
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
Pour que strongSwan puisse utiliser des routages et des adresses IP virtuelles, des modifications doivent être apportées à /etc/strongswan/strongswan.d/Charon.conf.
Annulez la mise en commentaire des lignes #install_routes = yes et #install_virtual_ip = yes, et remplacez les valeurs par "no", comme indiqué ci-dessous :
#Tunnels
install_routes = no
#Install virtual IP addresses.
install_virtual_ip = no
Utilisez les commandes suivantes afin d'activer et de démarrer le service pour zebra et BGPD :
systemctl start zebra
systemctl enable zebra
systemctl start bgpd
systemctl enable bgpd