Strongswan
Strongswan est une solution RPV à code source libre, basée sur IPSec. La plupart des distributions Linux comprennent Strongswan ou facilitent son installation. Vous pouvez l'installer sur des hôtes dans votre réseau sur place ou celui d'un fournisseur de services infonuagiques.
Cette rubrique décrit la configuration d'un CPE qui exécute 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 d'appareils. Utilisez la configuration appropriée pour votre fournisseur et votre version de logiciel.
Si la version de l'appareil ou du logiciel utilisée par Oracle pour vérifier la configuration ne correspond pas exactement à votre appareil ou à votre logiciel, vous pouvez tout de même créer la configuration nécessaire sur votre appareil. Consultez la documentation de votre fournisseur et apportez les ajustements nécessaires.
Si le fabricant de votre appareil ne figure pas dans la liste des fournisseurs et des appareils vérifiés, ou si vous êtes déjà familiarisé avec la configuration de votre appareil pour IPSec, consultez la liste des paramètres IPSec pris en charge et la documentation relative à votre fournisseur pour obtenir de l'aide.
Oracle Cloud Infrastructure offre un RPV site à site, connexion IPSec sécurisée entre votre réseau sur place et un réseau en nuage 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 servent uniquement d'exemples.
Meilleures pratiques
Cette section décrit les meilleures pratiques et les points à considérer généraux pour utiliser un RPV site à site.
Configurer tous les tunnels pour chaque connexion IPSec
Oracle déploie deux têtes de réseau IPSec pour chacune des connexions afin d'offrir une haute disponibilité pour les charges de travail critiques. Côté Oracle, ces deux têtes de réseau se trouvent sur différents routeurs à des fins de redondance. Oracle recommande de configurer tous les tunnels disponibles pour une redondance maximale. Il s'agit d'une partie essentielle de la philosophie "Design for Failure" (conçu pour résister aux pannes).
Disposer de CPE redondants dans vos emplacements de réseau sur place
Chacun de vos sites qui se connecte avec IPSec à Oracle Cloud Infrastructure doit disposer d'appareils en périphérie de réseau redondants (également appelés équipements locaux d'abonné (CPE)). Vous ajoutez chaque équipement local d'abonné à la console Oracle et créez une connexion IPSec distincte entre votre passerelle de routage dynamique (DRG) et chaque CPE. Pour chaque connexion PSec, Oracle provisionne deux tunnels pour des têtes de réseau IPSec géographiquement redondantes. Pour plus d'informations, voir Guide sur la redondance de connectivité (PDF).
Considérations relatives au protocole de routage
Lorsque vous créez une connexion IPSec de RPV site à site, elle possède deux tunnels IPSec redondants. Oracle vous encourage à configurer votre équipement local d'abonné pour utiliser les deux tunnels (si votre CPE le prend en charge). Auparavant, Oracle créait des connexions IPSec qui possédaient jusqu'à quatre tunnels IPSec.
Les trois types de routage suivants sont disponibles, et vous en choisissez un séparément pour chaque tunnel du RPV site à site :
- Routage dynamique BGP : Les routes disponibles sont apprises de manière dynamique au moyen de BGP. La passerelle DRG apprend dynamiquement les routes de votre réseau sur place. Côté Oracle, la passerelle DRG annonce les sous-réseaux du VCN.
- Routage statique : Lorsque vous configurez la connexion IPSec à la passerelle DRG, vous spécifiez les routes particulières à votre réseau sur place que le réseau VCN doit connaître. Vous devez également configurer votre CPE avec des routes statiques vers les sous-réseaux du VCN. Ces routes ne sont pas apprises dynamiquement.
- Routage basé sur des politiques : Lorsque vous configurez la connexion IPSec à la passerelle DRG, vous spécifiez les routes particulières à votre réseau sur place que le réseau VCN doit connaître. Vous devez également configurer votre CPE avec des routes statiques vers les sous-réseaux du VCN. Ces routes ne sont pas apprises dynamiquement.
Pour plus d'informations sur le routage avec RPV site à site, notamment des recommandations Oracle sur la manipulation de l'algorithme de sélection du meilleur chemin BGP, voir Routage pour RPV site à site.
Autres configurations importantes de l'équipement local d'abonné
Assurez-vous que les listes d'accès sur votre équipement local d'abonné sont configurées correctement pour ne pas bloquer le trafic nécessaire depuis ou vers Oracle Cloud Infrastructure.
Si plusieurs tunnels fonctionnent simultanément, le routage peut être asymétrique. Pour permettre le routage asymétrique, assurez-vous que votre équipement local d'abonné est configuré pour gérer le trafic provenant de votre VCN sur n'importe quel tunnel. Par exemple, vous devez désactiver l'inspection ICMP, configurer le contournement de l'état TCP. Pour plus de détails sur la configuration appropriée, communiquez avec le soutien technique du fournisseur de votre CPE. Pour configurer un routage symétrique, consultez Routage pour RPV site à site.
Restrictions et limites
Cette section décrit les caractéristiques et les limites générales importantes de RPV site à site. Voir Limites de service pour une liste des limites applicables et des instructions pour demander l'augmentation d'une limite.
Routage asymétrique
Oracle utilise un routage asymétrique sur les multiples tunnels qui composent la connexion IPSec. Configurez vos pare-feux en conséquence. Dans le cas contraire, les tests ping ou le trafic d'application sur la connexion ne fonctionnent pas de manière fiable.
Lorsque vous utilisez plusieurs tunnels vers Oracle Cloud Infrastructure, Oracle vous recommande de configurer votre routage de façon à guider le trafic de manière déterministe à travers le tunnel privilégié. Pour utiliser un tunnel IPSec principal et un autre de secours, configurez des routes plus spécifiques pour le tunnel principal (BGP) et des routes moins spécifiques (route sommaire ou par défaut) pour le tunnel de sauvegarde (BGP/statique). Sinon, si vous annoncez la même route (par exemple, une route par défaut) par tous les tunnels, le trafic de retour de votre réseau VCN à votre réseau sur place est dirigé vers n'importe lequel des tunnels disponibles. En effet, Oracle utilise un routage asymétrique.
Pour des recommandations de routage Oracle spécifiques sur la manière de forcer un routage symétrique, voir Routage pour RPV site à site.
RPV site à site basé sur des routes ou sur des politiques
Le protocole IPSec utilise des associations de sécurité (AS) pour déterminer comment chiffrer les paquets. Au sein de chaque association, pour définir comment chiffrer ou déchiffrer un paquet, il vous faut paramétrer des domaines de chiffrement pour mapper les adresses IP source et cible d'un paquet, ainsi que le type de protocole, sur une entrée de la base de données des associations de sécurité.
Il est possible que d'autres fournisseurs ou que la documentation sectorielle utilisent le terme ID mandataire, index de paramètre de sécurité (SPI) ou sélecteur de trafic pour désigner les associations de sécurité ou les domaines de chiffrement.
Il existe deux méthodes générales pour mettre en oeuvre les tunnels IPSec :
- Tunnels basés sur des routes : Également appelés tunnels basés sur les sauts suivants. Une consultation de la table de routage est effectuée sur l'adresse IP de destination d'un paquet. Si l'interface de sortie de cette route est un tunnel IPSec, le paquet est chiffré et envoyé à l'autre extrémité du tunnel.
- Tunnels basés sur des politiques : Les adresses IP source et cible du paquet sont comparées à une liste d'énoncés de politique. Si une correspondance est trouvée, le paquet est chiffré en fonction des règles de cet énoncé.
Les têtes de réseau du RPV site à site Oracle utilisent des tunnels basés sur des routes, mais fonctionnent avec les tunnels basés sur des politiques. Il existe toutefois certaines restrictions indiquées dans les sections suivantes.
Si votre équipement local d'abonné est derrière un appareil NAT
En général, l'identificateur IKE de CPE configuré à votre extrémité de la connexion doit correspondre à celui qu'Oracle utilise. Par défaut, Oracle utilise l'adresse IP publique du CPE, que vous fournissez lorsque vous créez l'objet CPE dans la console Oracle. Toutefois, si votre équipement local d'abonné est derrière un appareil NAT, l'identificateur IKE configuré à votre extrémité peut être l'adresse IP privée du CPE, comme illustré dans le diagramme suivant.
Certaines plates-formes CPE ne permettent pas de modifier l'identificateur IKE local. Dans ce cas, vous devez remplacer l'ID IKE distant dans la console Oracle par l'ID IKE local de votre CPE. Vous pouvez entrer cette valeur lorsque vous configurez la connexion IPSec ou plus tard, lorsque vous la modifiez. Pour Oracle, la valeur doit être une adresse IP ou un nom de domaine complet, tel que cpe.example.com. Pour obtenir des instructions, voir Modification de l'identificateur IKE de CPE utilisé par Oracle.
Paramètres IPSec pris en charge
Pour la liste des paramètres IPSec pris en charge indépendamment du fournisseur pour toutes les régions, voir Paramètres IPSec pris en charge.
Le numéro ASN BGP d'Oracle pour le domaine du nuage commercial est 31898. Si vous configurez un RPV site à site pour le nuage gouvernemental des États-Unis, voir Paramètres de RPV site à site requis pour le nuage gouvernemental et ASN BGP d'Oracle. Pour le nuage gouvernemental du Royaume-Uni, voir ASN BGP d'Oracle.
Configuration du CPE
Les instructions de configuration de cette section sont fournies par Oracle Cloud Infrastructure pour votre équipement local d'abonné. Si vous avez besoin d'une assistance supplémentaire, communiquez directement avec le soutien technique de votre fournisseur.
La figure ci-dessous illustre la disposition de base de la connexion IPSec.
Fichiers de configuration Strongswan par défaut
L'installation de Strongswan par défaut 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 secrets (clés prépartagées du tunnel).
Le fichier etc/strongswan/ipsec.conf par défaut comprend cette ligne :
Include /etc/strongswan/*.confLe fichier etc/strongswan/ipsec.secrets par défaut comprend cette ligne :
include /etc/strongswan/ipsec.d/*.secretsLes lignes précédentes fusionnent automatiquement tous les fichiers .conf et .secrets du répertoire /etc/strongswan dans la configuration principale et les fichiers de secrets utilisés par Strongswan.
À propos de l'utilisation de IKEv2
Oracle prend en charge le protocole Internet Key Exchange version 1 (IKEv1) et version 2 (IKEv2). Si vous configurez la connexion IPSec dans la console pour utiliser IKEv2, vous devez limiter votre CPE aux paramètres de chiffrement IKEv2 et connexes qu'il prend en charge. Pour obtenir la liste des paramètres pris en charge par Oracle pour IKEv1 ou IKEv2, voir Paramètres IPSec pris en charge.
Vous spécifiez la version IKE lors du paramétrage du fichier de configuration IPSec dans la tâche 3 de la section suivante. Dans cet exemple de fichier, un commentaire explique comment configurer IKEv2 plutôt qu'IKEv1.
Processus de configuration
Le processus de configuration suivant traite de la configuration d'un tunnel basé sur des routes sur Strongswan. Les têtes de réseau du RPV d'Oracle utilisent des tunnels basés sur des routes. Oracle recommande de configurer Strongswan avec la syntaxe de configuration de l'interface de tunnel virtuel.
Pour plus de détails sur les paramètres spécifiques utilisés dans ce document, voir Paramètres IPSec pris en charge.
Selon la distribution Linux que vous utilisez, il vous faudra peut-être activer la transmission IP sur votre interface afin de permettre aux clients d'envoyer et de recevoir du trafic par l'intermédiaire de 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 autre interface 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 de Strongswan utilise les variables suivantes. Déterminez les valeurs avant de poursuivre la configuration.
${cpeLocalIP}: Adresse IP de votre appareil Strongswan.${cpePublicIpAddress}: Adresse IP publique de Strongswan, également l'adresse IP de votre interface externe. Selon la topologie de votre réseau, la valeur peut être différente de${cpeLocalIP}.${oracleHeadend1}: Pour le premier tunnel, point d'extrémité de l'adresse IP publique Oracle obtenu de la console Oracle.${oracleHeadend2}: Pour le second tunnel, point d'extrémité de l'adresse IP publique Oracle obtenu de la console Oracle.${sharedSecret1}: Clé prépartagée du premier tunnel. Vous pouvez utiliser la clé prépartagée fournie par Oracle par défaut ou fournir votre propre clé lorsque vous configurez la connexion IPSec dans la console Oracle.${sharedSecret2}: Clé prépartagée du second tunnel. Vous pouvez utiliser la clé prépartagée fournie par Oracle par défaut ou fournir votre propre clé lorsque vous configurez la connexion IPSec dans la console Oracle.${vcnCidrNetwork}: Intervalle d'adresses IP du réseau VCN.
La configuration Strongswan utilise le concept de gauche et de droite pour définir les paramètres de configuration de votre équipement local d'abonné (CPE) et de la passerelle distante. N'importe quel côté de la connexion (conn dans la configuration de Strongswan) peut être la gauche ou la droite, mais la configuration de cette connexion doit être cohérente. Dans cet exemple :
- Gauche : Votre CPE Strongswan local
- Droite : Tête de réseau du RPV Oracle
Utilisez le modèle suivant pour votre fichier /etc/strongswan/ipsec.conf. Ce fichier définit les deux tunnels créés par Oracle lors de la configuration de la connexion IPSec.
Si votre équipement local d'abonné est derrière un appareil NAT 1-1, annulez la mise en commentaire du paramètre leftid et réglez-le à ${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 énoncés tels que ike= et esp= peuvent être modifiés 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 VTI avec 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 traite les noms commençant parvticomme étant spéciaux dans certains cas (par exemple, lors de l'extraction des statistiques d'appareil). Les adresses IP sont les points d'extrémité du tunnel IPSec. Une adresse IP privée peut être utilisée lorsque votre équipement local d'abonné est derrière un appareil NAT.-
<mark>doit correspondre à la marque configurée pour la connexion.
Une fois créée, l'interface VTI doit être activée (utilisez ip link set <name> up). Vous pouvez ensuite installer des routes et utiliser des protocoles de routage comme illustré 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 de la route 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 paramétré vos fichiers de configuration et de secrets, vous devez redémarrer le service Strongswan. 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 routes statiques qui envoient le trafic à votre réseau VCN au moyen des tunnels IPSec. Si vous êtes connecté avec un compte d'utilisateur sans privilèges, il vous faudra peut-être ajouter sudo avant la commande.
Les routes statiques créées avec la commande ip route ne sont pas conservées lors d'un redémarrage. Pour déterminer comment rendre vos 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
Un service Surveillance, également disponible dans Oracle Cloud Infrastructure, vous permet de contrôler vos ressources en nuage de manière active et passive. Pour plus d'informations sur la surveillance de votre RPV site à site, voir Mesures du RPV site à site.
En cas de problèmes, voir Dépannage du RPV site à site.
Vous pouvez également activer la journalisation OCI pour accéder aux journaux RPV.
Vérification du statut de l'interface de tunnel
Vérifiez l'état courant de vos tunnels Strongswan à l'aide de la commande suivante.
strongswan statusSi la sortie retournée est similaire à 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
À l'avenir, si vous devez ouvrir un ticket de soutien auprès d'Oracle à propos de votre tunnel Strongswan, indiquez 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 en ligne ou hors ligne à l'aide de la commande ifconfig ou ip link show. Vous pouvez également utiliser des applications telles que tcdump avec les interfaces.
Voici un exemple de la sortie ifconfig avec une mise en oeuvre Strongswan en cours d'exécution qui présente les interfaces VTI 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 pour 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
Configurer le 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 distribution Linux différente, vos commandes peuvent varier légèrement) :
sudo yum -y install quaggaModifiez la configuration zebra (/etc/quagga/zebra.conf) pour définir l'adresse IP VTI, qui est requise car BGP utilise l'appairage. Définissez les variables suivantes pour zebra :
${vti_name1}: Nom de la première interface VTI utilisée. Par exemple, vti1.${vti_name2}: Nom de la deuxième interface VTI utilisée. Par exemple, vti2.${vti_ipaddress1}: Adresse IP affectée à la première interface VTI utilisée.${vti_ipaddress2}: Adresse IP affectée à la seconde interface VTI utilisée.${local_subnet}: Sous-réseau 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 de votre réseau local.${router-id_ipaddress}: ID BGP du réseau local.${local_subnet}: Sous-réseau local qui doit être annoncé.${bgp_peer-ip _network}: CIDR /30 pour le réseau IP pair dans OCI.${neighbor_peer_ip_address}: Adresse IP du pair BGP OCI.
Ces variables sont utilisées dans l'extrait de fichier de configuration suivant de /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
L'activation de strongswan pour utiliser des routes et des adresses IP virtuelles nécessite des modifications à /etc/strongswan/strongswan.d/Charon.conf.
Annulez la mise en commentaire des lignes qui indiquent #install_routes = yes et #install_virtual_ip = yes et remplacez les valeurs par "no" comme illustré :
#Tunnels
install_routes = no
#Install virtual IP addresses.
install_virtual_ip = no
Utilisez les commandes suivantes pour activer et démarrer le service pour zebra et BGPD :
systemctl start zebra
systemctl enable zebra
systemctl start bgpd
systemctl enable bgpd