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 sur un réseau sur site ou sur un réseau de 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 fournisseurs et de dispositifs. Utilisez la configuration appropriée pour le fournisseur et la version du logiciel.
Si la version de l'appareil ou du logiciel qu'Oracle utilise pour vérifier la configuration ne correspond pas exactement à l'appareil ou au logiciel, vous pouvez néanmoins créer la configuration nécessaire sur l'appareil. Consultez la documentation du fournisseur et apportez les modifications nécessaires.
Si le périphérique provient d'un fournisseur ne figurant pas dans la liste des fournisseurs et des périphériques vérifiés, ou si vous savez déjà configurer le périphérique pour IPSec, reportez-vous à la liste des paramètres IPSec pris en charge et à la documentation du fournisseur pour obtenir de l'aide.
Oracle Cloud Infrastructure propose un VPN site à site, une connexion IPSec sécurisée entre un réseau sur site et un réseau cloud virtuel (VCN).
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 les connexions afin de fournir une haute disponibilité pour les charges de travail stratégiques. Côté Oracle, ces deux têtes de réseau se trouvent sur des routeurs différents à des fins de redondance. Nous vous recommandons de configurer tous les tunnels disponibles pour une redondance maximale. 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
Nous recommandons que chaque site se connectant à IPSec via Oracle Cloud Infrastructure dispose de dispositifs en périphérie redondants (également appelés CPE). Ajoutez chaque CPE à la console Oracle et créez une connexion IPSec distincte entre une passerelle de routage dynamique (DRG) 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 de VPN site à site IPSec, celle-ci possède deux tunnels IPSec redondants. Oracle vous encourage à configurer le CPE de sorte qu'il utilise les deux tunnels (si le CPE le prend en charge). Par le passé, Oracle a créé des connexions IPSec comportant jusqu'à quatre tunnels IPSec.
Les trois types de routage suivants sont disponibles. Vous sélectionnez 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. Le DRG 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 au DRG, vous spécifiez les routages particuliers vers le réseau sur site que vous souhaitez que le VCN connaisse. Vous devez également configurer le dispositif CPE avec des routages statiques vers les sous-réseaux du VCN. Ces routes ne sont pas apprises dynamiquement.
- Routage basé sur une stratégie : lorsque vous configurez la connexion IPSec au DRG, vous indiquez les routages spécifiques au réseau sur site que le VCN doit connaître. Vous devez également configurer le dispositif CPE avec des routages statiques vers les sous-réseaux du VCN. Ces routes ne sont pas apprises 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 à Racheminement 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. Pour prendre en compte le routage asymétrique, assurez-vous que le CPE est configuré pour gérer le trafic provenant du VCN 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 aux limites de service pour obtenir la liste des limites applicables et des instructions de demande d'augmentation de limite.
Routage asymétrique
Oracle utilise un routage asymétique sur les tunnels qui constituent la connexion IPSec. Configurez les pare-feu en gardant cela à l'esprit. 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, nous vous recommandons de configurer le routage pour acheminer le trafic de manière déterministe via le tunnel préféré. Afin d'utiliser un tunnel IPSec en tant que tunnel principal et un autre en tant que tunnel de sauvegarde, configurez des routages plus spécifiques pour le tunnel principal (BGP) et des routages moins spécifiques (récapitulatif ou par défaut) pour le tunnel de sauvegarde (BGP/statique). Sinon, si vous publiez la même route (par exemple, une route par défaut) via tous les tunnels, renvoyez le trafic d'un VCN vers des routes réseau sur site vers l'un 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écider 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 se trouve derrière un périphérique NAT
En général, l'identificateur IKE CPE configuré sur l'extrémité sur site 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 un CPE se trouve derrière un dispositif NAT, l'identificateur IKE CPE configuré sur l'extrémité sur site peut être l'adresse IP privée du CPE, comme indiqué dans le diagramme suivant.
Certaines plates-formes de CPE ne vous permettent pas de modifier l'identificateur IKE local. Si ce n'est pas le cas, vous devez modifier l'ID IKE distant dans la console Oracle pour correspondre à l'ID IKE local du 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 à Régions.
Configuration du CPE
Les instructions de configuration de cette section sont fournies par Oracle Cloud Infrastructure pour ce CPE. Si vous avez besoin d'assistance ou d'une aide supplémentaire, contactez directement le support 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 un CPE afin qu'il utilise uniquement IKEv2 et les paramètres du cryptage IKEv2 associés que le CPE prend en charge. 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, un commentaire indique comment configurer IKEv1 ou 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. Nous vous recommandons de configurer Strongswan avec la syntaxe de configuration de l'interface de tunnel virtuel (VTI).
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 la transmission IP sur l'interface pour permettre aux clients d'envoyer et d'envoyer 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 que eth0, remplacez eth0 dans l'exemple suivant par l'interface (lignes 5 et 7).
Si vous utilisez plusieurs interfaces, configurez 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 d'effectuer la configuration.
${cpeLocalIP}: adresse IP du périphérique Strongswan.${cpePublicIpAddress}: adresse IP publique de Strongswan, également l'adresse IP de l'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 clef prépartagée fournie par Oracle par défaut ou en indiquer une lorsque vous configurez la connexion IPSec dans la console Oracle.${sharedSecret2}: clé prépartagée du deuxième tunnel. Vous pouvez utiliser la clef prépartagée fournie par Oracle par défaut ou en indiquer une lorsque vous configurez 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 la droite pour définir les paramètres de configuration du dispositif CPE local et de la passerelle distante. L'un ou l'autre côté de la connexion (conn dans la configuration Strongswan) peut être gauche ou droit, mais la configuration de cette connexion doit être cohérente. Dans cet exemple :
- gauche : CPE Strongswan local
- right : tête de réseau du VPN Oracle
Utilisez le modèle suivant pour le 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 périphérique NAT un à un, 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
Les 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 le 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 quand le CPE est derrière un périphérique NAT.-
<mark>doit correspondre à la marque configurée pour la connexion.
Une fois l'interface de tunnel virtuelle créée, elle doit être activée (utilisez ip link set <name> up) et vous pouvez ensuite installer les 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é les 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 du trafic à un VCN via les tunnels IPSec. Si vous êtes enregistré avec un compte utilisateur sans privilège, vous devrez peut-être utiliser sudo avant la commande.
Les routages statiques créés avec la commande IP route ne sont pas persistant en cas de redémarrage. Pour savoir comment rendre les routes persistantes, reportez-vous à la documentation de la distribution Linux de votre choix.
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 activement et passivement les ressources cloud. Pour plus d'informations sur la surveillance d'un 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
A l'avenir, si vous devez ouvrir un ticket d'assistance auprès d'Oracle concernant le 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
Nous vous recommandons 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 sur site.${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