Haute disponibilité WireGuard site à site
|
Important
|
Traduction d’un article du site Pro Custodibus Le contenu de cette page est la traduction Française de l’article High Availability WireGuard Site to Site de Justin Ludwig |
Haute disponibilité WireGuard entre sites
WireGuard facilite la mise en place d’une connexion privée entre deux réseaux, qu’ils soient simplement des sous-réseaux différents dans le même bureau physique ou centre de données, ou des sites éloignés séparés par des continents ou des océans. Cet article vous montrera comment configurer plusieurs routeurs WireGuard à chaque site connecté pour la redondance — afin que si un routeur tombe en panne (ou le lien qu’il utilise tombe en panne), le trafic échoue automatiquement vers un routeur qui reste en ligne et opérationnel.
Dans l’exemple que nous couvrirons, nous aurons deux sites : Site A et Site B. Nous configurerons une boîte Linux standard avec WireGuard en cours d’exécution comme Routeur 1 dans Site A, et la connecterons à un routeur similaire Routeur 3 dans Site B. Ensuite, nous configurons une connexion parallèle entre un second routeur WireGuard dans Site A, Routeur 2, et un deuxième routeur WireGuard dans Site B, Routeur 4 :
Nous utiliserons OSPF (Open Shortest Path First, un Protocole de passerelle interne, ou IGP) pour suivre l’état des liens entre les deux routes parallèles (Router 1 ←→ Router 3 et Router 2 ←→ Router 4), que nous pouvons propager aux sites via OSPF ou via iBGP (Protocole de passerelle frontière interne). Ainsi, si le lien utilisé par une route tombe en panne, les routeurs LAN du site détecteront cette situation et remplaceront la route dans quelques secondes.
Voici les étapes que nous couvrirons :
- Configurer des routeurs WireGuard
- Configurer OSPF entre les routeurs WireGuard
- Configurer OSPF vers les routeurs LAN
- Configurer alternativement BGP vers les routeurs LAN
- Utiliser alternativement IPv6
Configurer des routeurs WireGuard
Nous configurerons chacun des quatre routeurs WireGuard de la même manière : installer Linux sur chacun (n’importe quelle distribution Linux moderne fonctionnera), puis :
Cela permettra de créer deux réseaux virtuels privés parallèles (Réseaux Virtuels Privés) : un entre le Routeur 1 et le Routeur 3, et l’autre entre le Routeur 2 et le Routeur 4 :
Le Routeur 1 aura une adresse IP privée WireGuard de 10.99.13.1, mais une adresse IP publique de 198.51.100.10 (et une adresse IP de 192.168.1.101 dans le LAN de Site A). Le Routeur 3 aura une adresse WireGuard de 10.99.13.3, mais une adresse IP publique de 203.0.113.33 (et une adresse IP de 192.168.200.3 dans le LAN de Site B). Le Routeur 1 se connectera à l’adresse IP publique du Routeur 3 sur le port UDP 51820, et vice versa.
De manière similaire, le Routeur 2 aura une adresse WireGuard de 10.99.24.2, mais une adresse IP publique de 198.51.100.222 (avec une adresse IP de 192.168.1.202 dans le LAN de Site A). Et le Routeur 4 aura une adresse WireGuard de 10.99.24.4, avec une adresse IP publique de 203.0.113.244 (et une adresse IP de 192.168.200.224 dans le LAN de Site B). Le Routeur 2 se connectera également à l’adresse IP publique du Routeur 4 sur le port UDP 51820, et vice versa.
Configurer WireGuard
Sur chaque routeur, installez WireGuard. Sur Debian ou Ubuntu, c’est aussi simple que sudo apt install wireguard. Pour d’autres distributions, consultez la page Installation de WireGuard.
Ensuite, générez un paire de clés publiques et privées pour chaque routeur avec la commande suivante :
wg genkey | tee privatekey | wg pubkey > publickey
Cela produira deux fichiers : privatekey contenant la clé privée et publickey contenant la clé publique. Copiez les clés publiques sur les autres routeurs pour configurer les connexions entre eux.
Configurer le transfert de paquets
Pour permettre le transfert de paquets entre les réseaux virtuels, vous devez activer le relais IP sur chaque routeur :
sysctl -w net.ipv4.ip_forward=1
Ajoutez cette ligne à /etc/sysctl.conf pour rendre la modification permanente.
Installer BIRD
BIRD (Berkeley Internet Routing Daemon) est un daemon de routage léger et efficace. Installez-le sur chaque routeur avec :
sudo apt install bird
Configurez BIRD en éditant le fichier /etc/bird/bird.conf pour chaque routeur. Voici un exemple de configuration basique :
router id 192.168.1.101;
protocol direct {
interface "eth0";
}
protocol kernel {
import all;
export all;
}
protocol bgp 65000 {
neighbor 198.51.100.33 as 65000;
import all;
export all;
}
Redémarrez BIRD pour appliquer les modifications :
sudo systemctl restart bird
Répétez ce processus sur les autres routeurs, ajustant les adresses IP et les identifiants BGP en conséquence.
Configurer OSPF entre les routeurs WireGuard
Configurez OSPF sur chaque routeur pour suivre l’état des liens entre les deux routes parallèles. Voici un exemple de configuration basique :
router ospf {
router-id 192.168.1.101;
network 10.99.13.0/24 area 0;
neighbor 10.99.24.2 remote-as 65000;
}
Redémarrez OSPF pour appliquer les modifications :
sudo systemctl restart ospfd
Répétez ce processus sur les autres routeurs, ajustant les adresses IP et les identifiants OSPF en conséquence.
Configurer OSPF vers les routeurs LAN
Configurez OSPF pour permettre le routage entre les réseaux virtuels et les réseaux LAN. Voici un exemple de configuration basique :
router ospf {
router-id 192.168.1.101;
network 10.99.13.0/24 area 0;
network 192.168.1.0/24 area 0;
}
Redémarrez OSPF pour appliquer les modifications :
sudo systemctl restart ospfd
Répétez ce processus sur les autres routeurs, ajustant les adresses IP et les identifiants OSPF en conséquence.
Configurer alternativement BGP vers les routeurs LAN
Si vous préférez utiliser BGP pour le routage entre les réseaux virtuels et les réseaux LAN, configurez BGP sur chaque routeur. Voici un exemple de configuration basique :
router bgp 65000 {
neighbor 192.168.1.2 remote-as 65000;
network 10.99.13.0/24;
}
Redémarrez BGP pour appliquer les modifications :
sudo systemctl restart bgpd
Répétez ce processus sur les autres routeurs, ajustant les adresses IP et les identifiants BGP en conséquence.
Utiliser alternativement IPv6
Si vous préférez utiliser IPv6 pour le routage entre les réseaux virtuels, configurez IPv6 sur chaque routeur. Voici un exemple de configuration basique :
interface eth0 {
address 2001:db8::1/64;
}
Ajoutez cette ligne à /etc/network/interfaces pour rendre la modification permanente.
Redémarrez le service réseau pour appliquer les modifications :
sudo systemctl restart networking
Répétez ce processus sur les autres routeurs, ajustant les adresses IPv6 en conséquence.
En suivant ces étapes, vous aurez une configuration haute disponibilité WireGuard entre deux sites avec OSPF pour le routage interne et BGP ou IPv6 pour le routage externe.
Vous pouvez le faire avec la commande suivante :
$ wg genkey | tee /dev/stderr | wg pubkey
0F1111111111111111111111111111111
La première ligne que vous voyez sera la clé privée (qui devrait être beaucoup plus aléatoire que l'exemple construit ci-dessus) ; la deuxième ligne sera la clé publique. La clé privée va dans le fichier de configuration du routeur lui-même ; la clé publique va dans le fichier de configuration du routeur correspondant auquel il se connecte.
Ensuite, créez un fichier de configuration WireGuard à `/etc/wireguard/wg0.conf`. Sur le Routeur 1, mettez les paramètres suivants :
```bash
# /etc/wireguard/wg0.conf sur le Routeur 1
# paramètres locaux pour le Routeur 1
[Interface]
PrivateKey = 0F1111111111111111111111111111111
Ne modifiez pas le paramètre `Table = off`, qui indique à `wg-quick` de ne pas ajouter d'routes basées sur `AllowedIPs` lors de la configuration de l'interface. Ne modifiez également pas le paramètre `AllowedIPs = 0.0.0.0/0, ::/0`, qui indique à WireGuard de passer tous les paquets envoyés via l'interface au routeur 3, indépendamment de l'adresse d'destination du paquet.
Sur le Routeur 3, ajoutez les paramètres suivants dans `/etc/wireguard/wg0.conf` :
```bash
# /etc/wireguard/wg0.conf sur le Routeur 3
# paramètres locaux pour le Routeur 3
[Interface]
PrivateKey = 2H3333333333333333333333333333333
```bash
$ ping -nc1 10.99.13.3
PING 10.99.13.3 (10.99.13.3) 56(84) bytes of data.
64 bytes from 10.99.13.3: icmp_seq=1 ttl=64 time=20.3 ms
--- 10.99.13.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 20.325/20.325/20.325/0.000 ms
Vous devriez également être en mesure de pinger le Routeur 4 depuis le Routeur 2 (et vice versa). Consultez la Configuration Site à Site WireGuard pour plus de détails sur les paramètres WireGuard mentionnés ci-dessus et pour des conseils de dépannage.
Configurer le Transfert de Paquets
Ensuite, pour activer le transfert de paquets, créez un fichier /etc/sysctl.d/local.conf et définissez-le avec ce contenu :
net.ipv4.conf.all.forwarding=1
Puis exécutez la commande suivante pour l’appliquer (ainsi que tous les autres fichiers de configuration sysctl) :
sudo sysctl --system
Installer BIRD
Enfin, installez le démon de routage BIRD 2.x. Sur la plupart des distributions Linux, il est disponible via le paquet bird ; sur Debian et Ubuntu, c’est le paquet bird2 (installez-le avec sudo apt install bird2).
BIRD 1.x fonctionnera également, mais utilise des paramètres de configuration légèrement différents — il ne prend pas en charge à la fois IPv4 et IPv6 (vous devez configurer l’un ou l’autre), donc il ne prend pas en charge les options de canal ip4 {} et ipv6 {} nécessaires pour la configuration BIRD 2.x. (D’autres démons de routage, comme FRR ou Quagga, fonctionneront également correctement — juste avec une syntaxe de configuration différente.)
Configurer OSPF entre les Routeurs WireGuard
À ce stade, nous avons WireGuard en cours d’exécution sur tous les quatre routeurs WireGuard, avec le Routeur 1 connecté au Routeur 3 et le Routeur 2 connecté au Routeur 4. Cependant, car nous avons mis Table = off dans leur configuration de WireGuard, aucun n’est encore configuré pour effectivement routager les paquets au-delà de leur propre sous-réseau WireGuard (10.99.13.0/24 pour la connexion entre le Routeur 1 et le Routeur 3, et 10.99.24.0/24 pour la connexion entre le Routeur 2 et le Routeur 4).
Ainsi, nous allons configurer le démon de routage BIRD avec OSPF sur chaque routeur afin de :
- Vérifier si le lien entre chaque routeur et sa paire est en cours
- Échanger les routes entre les routeurs paires
- Ajouter les routes échangées à la table principale du routeur
Nous attribuerons au Routeur 1 un ID de routeur de 10.99.13.1 et au Routeur 3 un ID de routeur de 10.99.13.2.
.13.1, au Routeur 3 un ID de routeur de 10.99.13.3, et utiliserons l'area OSPF 10.99.13.0pour leur connexion entre eux ; et nous attribuerons au Routeur 2 un ID de routeur de10.99.24.2, au Routeur 4 un ID de routeur de 10.99.24.4, et utiliserons l'area OSPF 10.99.24.0` pour leur connexion entre eux :
|
Note
|
Sur le Routeur 1, éditez son fichier /etc/bird/bird.conf pour qu’il ressemble au suivant :
router id 10.99.13.1;
protocol device {
}
protocol kernel {
ipv4 {
export where proto = "wg";
};
}
ipv4 {
import where net !~ 10.99.13.0/24;
export all;
};
area 10.99.13.0 {
interface "wg0";
};
}
|
Tip
|
La ligne router id définit l’ID global pour ce routeur (utilisé par les deux OSPF et BGP). Le bloc protocol device configure BIRD à synchroniser périodiquement sa liste d’interfaces à partir du système d’exploitation, afin de détecter quand des interfaces sont ajoutées, supprimées ou mises à jour.
Le bloc protocol kernel synchronise la table de routage IPv4 principale du système d’exploitation avec la table interne master4 de BIRD. Par défaut, toutes les routes sont importées depuis la table du système d’exploitation dans la table de BIRD, mais aucune n’est exportée à partir de la table de BIRD vers la table du système d’exploitation. La ligne export where proto = "wg"; configure BIRD pour exporter toutes les routes qu’il a ajoutées à sa table master4 depuis l’instance de protocole nommée wg au système d’exploitation dans sa table principale — autrement dit, pour copier toutes les routes qu’il apprend de OSPF sur le autre site dans sa propre table de routage active.
|
Note
|
Voici le texte corrigé : |
Le bloc protocol ospf v2 wg configure l’instance OSPFv2 que nous utiliserons pour la connexion WireGuard. Notez que wg est simplement un ID interne arbitraire que nous avons donné à cette instance — BIRD aurait autrement attribué à cette instance un ID de ospf1 par défaut. Par défaut, il importe toutes les routes qu’il reçoit via OSPF dans sa table de routage master4; mais il ne sort aucune des routes de sa table master4 vers OSPF. La ligne export all; dans ce bloc remplace cette valeur d’exportation par défaut pour exporter toutes les routes de sa table master4 vers OSPF.
La ligne import where net !~ 10.99.13.0/24; configure BIRD pour éviter d’importer des routes concernant le sous-réseau 10.99.13.0/24 depuis OSPF — c’est le sous-réseau que nous utilisons pour la connexion WireGuard entre le routeur 1 et le routeur 3. La route pour 10.99.13.0/24 est déjà configurée dans la table principale de l’OS par wg-quick lorsqu’il démarre la connexion WireGuard, donc l’OS n’a pas besoin d’apprendre cette route à partir de BIRD; et puisque cette route est utilisée uniquement en arrière-plan par la connexion privée entre les routeurs WireGuard, il n’y a pas besoin de la propager vers d’autres routeurs.
Le bloc area 10.99.13.0 configure BIRD pour utiliser la zone avec un ID de 10.99.13.0 pour OSPF sur les interfaces spécifiées (et comme mentionné ci-dessus, 10.99.13.0 est simplement un nombre 32 bits arbitraire, pas nécessairement lié à une adresse IP ou un sous-réseau). La ligne interface "wg0"; indique que l’interface wg0 WireGuard que nous avons configurée dans la section précédente est incluse dans la définition de la zone.
Autre que les filtres d’import et d’export personnalisés, cette configuration OSPF utilise simplement les paramètres par défaut de BIRD pour tout — ce qui est parfait pour WireGuard (tant que tous les routeurs WireGuard dans la même zone utilisent le même sous-réseau — 10.99.13.0/24 dans le cas du Routeur 1 et du Routeur 3). Il écoute et envoie des diffusion OSPF sur l’interface wg0, importe les routes apprises d’OSPF dans sa table master4, et exporte les autres routes de sa table master4 pour les partager via OSPF.
|
Avertissement
|
Sur le Routeur 3, éditez son fichier /etc/bird/bird.conf pour correspondre aux paramètres du Routeur 1, avec l’exception de l’utilisation de l’ID unique du routeur du Routeur 3 :
router id 10.99.13.3;
protocol device {
}
protocol kernel {
ipv4 {
export where proto = "wg";
};
}
protocol ospf v2 wg {
ipv4 {
import where net !~ 10.99.13.0/24;
export all;
};
area 10.99.13.0 {
interface "wg0";
};
}
Sur le Routeur 2, éditez son fichier /etc/bird/bird.conf pour le configurer de manière similaire au Routeur 1 et au Routeur 3, mais en sautant l’importation de son propre sous-réseau WireGuard (10.99.24.0/24) et en utilisant un ID d’area différent de 10.99.24.0 pour son area partagée avec le Routeur 4 :
router id 10.99.24.2;
protocol device {
}
protocol kernel {
ipv4 {
export where proto = "wg";
};
}
protocol ospf v2 wg {
ipv4 {
import where net !~ 10.99.24.0/24;
export all;
};
area 10.99.24.0 {
interface "wg0";
};
}
where net !~ 10.99.24.0/24;
export all;
};
area 10.99.24.0 {
interface "wg0";
};
}
Et sur le Routeur 4, éditez son fichier /etc/bird/bird.conf pour qu’il corresponde aux paramètres du Routeur 2, sauf avec l’ID d’hôte propre au Routeur 4 :
router id 10.99.24.4;
protocol device {
}
protocol kernel {
ipv4 {
export where proto = "wg";
};
}
protocol ospf v2 wg {
ipv4 {
import where net !~ 10.99.24.0/24;
export all;
};
area 10.99.24.0 {
interface "wg0";
};
}
Exécutez la commande suivante sur chaque routeur pour démarrer un client en ligne de commande interactif vers BIRD :
$ sudo birdc
BIRD 2.0.7 prêt.
Ensuite, exécutez la commande suivante dans le client BIRD pour recharger vos modifications apportées à /etc/bird/bird.conf :
bird> configure
Lecture de la configuration depuis /etc/bird/bird.conf
Reconfiguré
Après avoir rechargé vos modifications sur les Routeurs 1 et 3, si vous exécutez la commande suivante à partir du Routeur 1, vous devriez voir qu’il communique avec le Routeur 3 :
bird> show ospf neighbors wg
wg:
ID de routeur Préférence État DTime Interface IP du routeur
10.99.13.3 1 Full/PtP 35.956 wg0 10.99.13.3
Mais il n’aura pas encore importé de routes dans la table d’itinéraire IPv4 par défaut de BIRD :
bird> show route
Dépannage
Si vous ne voyez aucun voisin, vérifiez d’abord si le Routeur 1 peut pinguer le Routeur 3 :
$ ping -nc1 10.99.13.3
PING 10.99.13.3 (10.99.13.3) 56(84) bytes of data.
64 bytes from 10.99.13.3: icmp_seq=1 ttl=64 time=20.3 ms
--- 10.99.13.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 20.325/20.325/20.325/0.000 ms
Si ce n’est pas le cas, votre connexion WireGuard ne fonctionne pas et vous devez d’abord revenir et la corriger.
Sinon, ajoutez une ligne debug protocols all; au début du fichier /etc/bird/bird.conf :
router id 10.99.13.1;
debug protocols all;
...
Et rechargez votre configuration :
bird> configure
Reading configuration from /etc/bird/bird.conf
Reconfigured
Et vérifiez ensuite la sortie syslog de BIRD. Vous devriez voir des messages périodiques comme :
$ journalctl -u bird.service
Oct 12 17:06:02 router1 bird[8106]: wg: HELLO packet sent via wg0
Oct 12 17:06:02 router1 bird[8106]: wg: HELLO packet received from nbr 10.99.13.3 on wg0
Oct 12 17:06:12 router1 bird[8106]: wg: HELLO packet sent via wg0
Oct 12 17:06:12 router1 bird[8106]: wg: HELLO packet received from nbr 10.99.13.3 on wg0
Oct 12 17:06:22 router1 bird[8106]: wg: HELLO packet sent via wg0
Oct 12 17:06:22 router1 bird[8106]: wg: HELLO packet received from nbr 10.99.13.3 on wg0
Plus des mises à jour occasionnelles de l’état du lien.
|
Tip
|
Configurer OSPF pour les routeurs du LAN
Maintenant que les liens WireGuard entre Site A et Site B sont en place et échangent des routes, le prochain pas est de propager ces routes aux sites. Si vous utilisez OSPF dans vos sites, suivez les instructions de cette section ; si vous utilisez iBGP, suivez les instructions de la section Configurer BGP pour les routeurs du LAN (Alternativement).
Pour cet exemple, supposons que le Routeur 1 soit sur le sous-réseau LAN 192.168.1.64/26, et qu’il échange des routes avec son routeur LAN 192.168.1.65 dans la zone OSPF 0; le Routeur 2 est sur le sous-réseau LAN 192.168.1.192/26, et qu’il échange des routes avec son routeur LAN 192.168.1.193 dans la zone OSPF 0.
tes avec son routeur LAN `192.168.1.193`, également dans la zone `0`; le Routeur 3 est sur le sous-réseau LAN `192.168.200.0/26`, et qu'il échange des routes avec son routeur LAN `192.168.200.1` dans la zone OSPF `0`; et le Routeur 4 est sur le sous-réseau LAN `192.168.200.192/26`, et qu'il échange des routes avec son routeur LAN `192.168.200.193`, également dans la zone `0` :
Site A a également quelques autres sous-réseaux, `192.168.2.0/24` et `192.168.3.0/24`, qui peuvent être accessibles à travers les passerelles `192.168.1.65` et `192.168.1.193`; tandis que Site B a un sous-réseau supplémentaire `192.168.200.128.0/26`.
Sur chaque routeur WireGuard, éditez son fichier `/etc/bird/bird.conf` pour ajouter une deuxième bloc `protocol ospf` :
```bash
protocol ospf v2 lan {
ipv4 {
export all;
};
area 0 {
interface "eth0";
};
}
Remplacez eth0 par le nom réel de l’interface LAN du routeur (si ce n’est pas eth0), et remplacez l’ID d’area 0 par l’ID d’area OSPF réel que vous utilisez pour le sous-réseau LAN sur lequel se trouve le routeur (si ce n’est pas 0). Notez également que nous avons attribué cet bloc protocol un ID interne arbitraire de lan (sinon BIRD lui donnerait un ID généré automatiquement comme ospf2).
La ligne export all; configure BIRD pour exporter toutes les routes de sa table master4 vers OSPF. Par défaut, BIRD importera également toutes les routes IPv4 qu’il reçoit par OSPF dans sa table master4. Si vous ne voulez pas propager toutes les routes du site à l’autre site, ajoutez un filtre import ici au canal ipv4 pour limiter les routes que BIRD tirera de cette instance OSPF.
Par exemple, pour propager uniquement les routes du sous-réseau 192.168.1.0/24, ajoutez une ligne import where net ~ 192.168.1.0/24; au bloc ipv4; ou pour importer toutes les routes à l’exception des blocs 10.0.0.0/16 et 10.100.0.0/16, ajoutez import where net !~ 10.0.0.0/16 && net !~ 10.100.0.0/16;; etc. BIRD comprend un langage de programmation complet pour filtrer les routes, si vous avez besoin d’une fonctionnalité plus sophistiquée.
Le fichier /etc/bird/bird.conf complet sur le routeur 1 devrait maintenant ressembler à ceci :
router id 10.99.13.1;
protocol device {
}
protocol kernel {
ipv4 {
export where proto = "wg";
};
}
protocol ospf v2 wg {
ipv4 {
import where net !~ 10.99.13.0/24;
export all;
};
area 10.99.13.0 {
interface "wg0";
};
}
protocol ospf v2 lan {
ipv4 {
export all;
};
area 0 {
interface "eth0";
};
}
Maintenant, exécutez la commande suivante dans le client BIRD pour recharger vos modifications au fichier /etc/bird/bird.conf :
bird> configure
Reading configuration from /etc/bird/bird.conf
Reconfigured
Après le rechargement, vous devriez voir au moins un voisin pour la nouvelle instance OSPF lan :
bird> show ospf neighbors lan
lan:
Router ID Pri State DTime Interface Router IP
192.168.1.65 10 Full/DR 39.184 eth0 192.168.1.65
Si ce n’est pas le cas, vérifiez la configuration OSPF sur le routeur du LAN et ajustez la configuration OSPF WireGuard pour qu’elle corresponde. En particulier, assurez-vous que l’ID d’area et l’intervalle de bonjour correspondent (l’intervalle de bonjour par défaut de BIRD est de 10 secondes).
Si vous n’avez ajouté que la nouvelle instance OSPF lan à un seul routeur WireGuard (comme uniquement au routeur 1), BIRD récupérera les routes du site proprement dit du routeur :
bird> show route
Table master4:
192.168.1.64/26 unicast [lan 18:25:47.947] I (150/10) [10.99.13.1]
dev eth0
unicast [lan 18:25:47.947] E1 (150/20) [192.168.1.65]
via 192.168.1.65 on eth0
192.168.1.192/26 unicast [lan 18:25:47.9
47] E1 (150/30) [192.168.1.193]
via 192.168.1.65 on eth0
192.168.3.0/24 unicast [lan 18:25:47.947] E1 (150/30) [192.168.1.1]
via 192.168.1.65 on eth0
192.168.4.0/24 unicast [lan 18:25:47.947] E1 (150/30) [192.168.1.1]
via 192.168.1.65 on eth0
Mais une fois que vous avez mis à jour tous les routeurs, chaque routeur devrait avoir au moins un chemin vers toutes les routes exposées par OSPF sur n'importe quel sous-réseau LAN dans la table `master4` de BIRD :
```bash
bird> show route
Table master4:
192.168.1.64/26 unicast [lan 18:25:47.947] I (150/10) [10.99.13.1]
dev eth0
unicast [lan 18:25:47.947] E1 (150/20) [192.168.1.65]
via 192.168.1.65 on eth0
192.168.1.192/26 unicast [lan 18:25:47.947] E1 (150/30) [192.168.1.193]
via 192.168.1.65 on eth0
192.168.3.0/24 unicast [lan 18:25:47.947] E1 (150/30) [192.168.1.1]
via 192.168.1.65 on eth0
192.168.4.0/24 unicast [lan 18:25:47.947] E1 (150/30) [192.168.1.1]
via 192.168.1.65 on eth0
192.168.200.0/26 unicast [wg 19:37:19.495] E1 (150/20) [10.99.13.3]
via 10.99.13.3 on wg0
unicast [lan 20:14:51.882] E1 (150/60) [192.168.200.1]
via 192.168.1.65 on eth0
192.168.200.128/26 unicast [wg 19:37:19.495] E1 (150/30) [192.168.200.1]
via 10.99.13.3 on wg0
unicast [lan 20:14:51.882] E1 (150/50) [192.168.200.193]
via 192.168.1.65 on eth0
192.168.200.192/26 unicast [wg 19:37:19.495] E1 (150/40) [192.168.200.193]
via 10.99.13.3 on wg0
unicast [lan 20:14:51.882] E1 (150/40) [10.99.24.4]
via 192.168.1.65 on eth0
Et chaque routeur devrait avoir le meilleur chemin pour chaque sous-réseau à l’autre site dans sa table main de son système d’exploitation (notez que les routes exportées par BIRD seront listées comme proto bird) :
$ ip route
default via 192.168.1.65 dev eth0 proto dhcp src 192.168.1.101 metric 100
10.99.13.0/24 dev wg0 proto kernel scope link src 10.99.13.1
192.168.1.64/26 dev eth0 proto kernel scope link src 192.168.1.101
192.168.1.65 dev eth0 proto dhcp scope link src 192.168.1.101 metric 100
192.168.200.0/26 via 10.99.13.3 dev wg0 proto bird metric 32
192.168.200.128/26 via 10.99.13.3 dev wg0 proto bird metric 32
192.168.200.192/26 via 10.99.13.3 dev wg0 proto bird metric 32
Donc, vous devriez maintenant être en mesure de pinger Endpoint B (à 192.168.200.22) dans Site B depuis Endpoint A (à 192.168.1.91) dans Site A (en supposant que vous n’ayez pas de pare-feux bloquant les paquets ICMP entre les deux hôtes) :
$ ping -nc1 192.168.200.22
PING 192.168.200.22 (192.168.200.22) 56(84) bytes of data.
64 bytes from 192.168.200.22: icmp_seq=1 ttl=59 time=23.3 ms
--- 192.168.200.22 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 23.279/23.279/23.279/0.000 ms
Et si vous tuez l’un des liens WireGuard entre Site A et Site B (comme pour des tests, exécutez sudo wg-quick down wg0 sur le Routeur 1), vous devriez toujours être en mesure de pinger Endpoint B depuis Endpoint A — le routeur LAN d’Endpoint A doit recevoir la mise à jour de l’état du lien via OSPF et ré-routinger le trafic entre Endpoint A et Endpoint B par le autre lien WireGuard.
Configurez Alternativement BGP sur les Routeurs LAN
Si vous utilisez iBGP pour échanger des routes internes au sein d’un site (ou à la fois dans les deux sites), vous pouvez utiliser BGP au lieu de OSPF pour propager les routes échangées par les routeurs WireGuard vers le reste du site.
Par exemple, supposons que le Site A utilise iBGP. Nous pouvons configurer le Routeur 1 et le Routeur 2 pour utiliser BGP et les connecter à un Route Reflector dédié (RR) utilisé par tous les routeurs LAN du site. Les routeurs WireGuard propageront les routes du Site B vers le RR (et vice versa), et le RR propagera les routes vers le reste du si
Le RR sera à 192.168.3.1, et utilisera un numéro d’autorité de réseau privé (ASN) de 65000.
Sur le Routeur 1 et le Routeur 2, éditez leurs fichiers /etc/bird/bird.conf pour ajouter un bloc protocol direct et un bloc protocol bgp :
protocol direct {
ipv4;
interface "eth0";
}
protocol bgp {
ipv4 {
export all;
next hop self;
};
local as 65000;
neighbor 192.168.3.1 internal;
}
Remplacez eth0 dans le bloc protocol direct par le nom réel de l’interface LAN du routeur (ou si le routeur WireGuard a plusieurs interfaces connectées à différentes parties de son site, utilisez un motif d’interface qui les englobe tous, comme "eth*", "gre*", etc). Le bloc protocol direct est nécessaire pour importer les routes de l’interface directe pour l’interface LAN dans la table de routage principale BIRD (master4), afin qu’il puisse ajouter le bon prochain saut aux routes provenant d’un autre site qu’il partagera via BGP.
Dans le bloc protocol bgp, remplacez 65000 par le numéro ASN privé réel que vous utilisez, et remplacez 192.168.3.1 par l’adresse IP réelle du serveur iBGP avec lequel le routeur doit échanger des routes. Ajoutez plusieurs blocs protocol bgp si vous avez plusieurs serveurs iBGP avec lesquels les routeurs WireGuard doivent échanger des routes (un bloc pour chaque serveur iBGP).
La ligne export all; indique à BIRD de partager toutes les routes dans sa table master4 avec le serveur iBGP distant. La ligne next hop self; indique à BIRD d’ajuster ces routes afin que le routeur WireGuard lui-même devienne le prochain saut pour toutes ces routes. Cela permettra de partager les routes que le routeur WireGuard a apprises de l’autre site, en utilisant le routeur WireGuard lui-même comme lien vers ce site.
Par défaut, BIRD importe également toutes les routes IPv4 qu’il reçoit via BGP dans sa table master4 (pour être partagées à nouveau vers son routeur WireGuard pair sur l’autre site via OSPF). Si vous ne souhaitez pas propager toutes les routes de ce site à l’autre site, ajoutez un filtre import au canal ipv4 pour limiter les routes que BIRD importera depuis BGP.
Par exemple, pour propager uniquement les routes du sous-réseau 192.168.1.0/24, ajoutez une ligne import where net ~ 192.168.1.0/24; au bloc ipv4; ou pour importer toutes les routes sauf les blocs 10.0.0.0/16 et 10.100.0.0/16, ajoutez import where net !~ 10.0.0.0/16 && net !~ 10.100.0.0/16;; etc. Consultez la référence des filtres de BIRD si vous avez besoin d’un filtrage plus complexe.
Le fichier complet /etc/bird/bird.conf sur le routeur 1 devrait maintenant ressembler à ceci :
router id 10.99.13.1;
protocol device {
}
protocol kernel {
ipv4 {
export where proto = "wg";
};
}
protocol ospf v2 wg {
ipv4 {
import where net !~ 10.99.13.0/24;
export all;
};
area 10.99.13.0 {
interface "wg0";
};
}
protocol direct {
ipv4;
interface "eth0";
}
protocol bgp {
ipv4 {
export all;
next hop self;
};
local as 65000;
neighbor 192.168.3.1 internal;
}
Apportez une modification similaire au routeur 2, et exécutez la commande suivante dans le client BIRD sur chacun pour recharger vos modifications :
bird> configure
Reading configuration from /etc/bird/bird.conf
Reconfigured
Une fois que vous avez mis à jour les routeurs, chaque routeur doit avoir au moins un chemin vers toutes les routes exposées par BGP dans la table master4 de BIRD :
bird> show route
Table master4:
192.168.1.64/26 unicast [direct1 22:21:41.501] * (240)
dev eth0
unicast [bgp1 22:30:34.341] (100) [i]
via 192.168.1.65 on eth0
192.168.1.192/26 unicast [bgp1 22:30:34.341] (100)
Voici le texte corrigé :
i]
via 192.168.1.65 on eth0
192.168.3.0/24 unicast [bgp1 22:30:34.341] (100) [i]
via 192.168.1.65 on eth0
192.168.4.0/24 unicast [bgp1 22:30:34.341] (100) [i]
via 192.168.1.65 on eth0
192.168.200.0/26 unicast [wg 19:37:19.495] E1 (150/20) [10.99.13.3]
via 10.99.13.3 on wg0
unicast [bgp1 22:30:34.341] (100) [i]
via 192.168.1.65 on eth0
192.168.200.128/26 unicast [wg 19:37:19.495] E1 (150/30) [192.168.200.1]
via 10.99.13.3 on wg0
unicast [bgp1 22:30:34.341] (100) [i]
via 192.168.1.65 on eth0
192.168.200.192/26 unicast [wg 19:37:19.495] E1 (150/40) [192.168.200.193]
via 10.99.13.3 on wg0
unicast [bgp1 22:30:34.341] (100) [i]
via 192.168.1.65 on eth0
Et chaque routeur doit avoir le meilleur chemin pour chaque sous-réseau à l’autre site dans sa table main de son système d’exploitation (avec les routes exportées par BIRD listées avec proto bird) :
$ ip route
default via 192.168.1.65 dev eth0 proto dhcp src 192.168.1.101 metric 100
10.99.13.0/24 dev wg0 proto kernel scope link src 10.99.13.1
192.168.1.64/26 dev eth0 proto kernel scope link src 192.168.1.101
192.168.1.65 dev eth0 proto dhcp scope link src 192.168.1.101 metric 100
192.168.200.0/26 via 10.99.13.3 dev wg0 proto bird metric 32
192.168.200.128/26 via 10.99.13.3 dev wg0 proto bird metric 32
192.168.200.192/26 via 10.99.13.3 dev wg0 proto bird metric 32
Voici la traduction en français :
Ainsi, vous devriez maintenant être capable de pinger avec succès Endpoint B (à l’adresse 192.168.200.22) à partir d’Endpoint A (à l’adresse 192.168.1.91) dans Site A (en supposant que vous n’ayez pas de pare-feu bloquant les paquets ICMP entre les deux hôtes) :
$ ping -nc1 192.168.200.22
PING 192.168.200.22 (192.168.200.22) 56(84) bytes of data.
64 bytes from 192.168.200.22: icmp_seq=1 ttl=59 time=23.3 ms
--- 192.168.200.22 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 23.279/23.279/23.279/0.000 ms
Et si vous éteignez l’un des liens WireGuard entre Site A et Site B (comme pour les tests, exécutez sudo wg-quick down wg0 sur le Routeur 1), vous devriez toujours être capable de pinger Endpoint B à partir d’Endpoint A — le routeur LAN d’Endpoint A doit recevoir la nouvelle route vers Endpoint B via BGP et re-routage le trafic entre Endpoint A et Endpoint B en utilisant l’autre lien WireGuard.
Utiliser IPv6 Alternativement
Vous pouvez utiliser le même setup de base décrit dans les sections précédentes pour échanger des routes IPv6 (et pour échanger des routes sur des liens IPv6). La principale différence est que vous devez utiliser OSPFv3 au lieu d’OSPFv2 pour échanger des routes IPv6 entre les routeurs WireGuard — et comme OSPFv3 est conçu pour fonctionner uniquement sur des liens IPv6 directs, vous devez attribuer des adresses link-local IPv6 à vos interfaces WireGuard.
Voici donc les étapes à suivre afin d’ajouter IPv6 à (ou de remplacer IPv4 par IPv6 dans) les exemples ci-dessus :
- Activer la transmission de paquets IPv6
- Ajouter des adresses IPv6 WireGuard
- Configurer OSPFv3 dans BIRD
- Utiliser BGP avec IPv6 Alternativement
Activer la transmission de paquets IPv6
Pour activer la transmission de paquets IPv6, ajoutez ce qui suit à votre fichier /etc/sysctl.d/local.conf (créez-le s’il n’existe pas déjà) :
net.ipv6.conf.all.forwarding=1
Ensuite, exécutez la commande suivante pour l’appliquer (ainsi que tous les autres fichiers de configuration sysctl) :
sudo sysctl --system
Ajouter des Adresses IPv6 WireGuard
Vous pouvez ajouter plusieurs adresses IP, y compris une combinaison d’adresses IPv4 et IPv6, à n’importe quelle interface WireGuard. Par exemple, pour ajouter une adresse IPv6 link-local sur l’interface wg0, vous pouvez utiliser la commande suivante :
sudo ip -6 addr add fe80::1/64 dev wg0
Ensuite, redémarrez le service WireGuard pour appliquer les changements :
sudo wg-quick down wg0
sudo wg-quick up wg0
Configurer OSPFv3 dans BIRD
Pour configurer OSPFv3 avec BIRD, vous devez modifier le fichier de configuration BIRD. Voici un exemple de configuration basique :
protocol ospf6 {
interface "wg0";
}
Ensuite, redémarrez le service BIRD pour appliquer les changements :
sudo systemctl restart bird6
Utiliser BGP avec IPv6 Alternativement
Pour utiliser BGP avec IPv6, vous devez configurer BGP sur chaque routeur et ajouter des routes IPv6. Voici un exemple de configuration basique :
protocol bgp {
neighbor 2001:db8::1 as 65000;
import all;
export all;
}
Ensuite, redémarrez le service BIRD pour appliquer les changements :
sudo systemctl restart bird6
Avec ces étapes, vous devriez être capable d’échanger des routes IPv6 entre les routeurs WireGuard en utilisant OSPFv3 et BGP.
ireGuard. Par exemple, pour ajouter l’adresse IPv6 fe99:13::1 (sur le sous-réseau local fe99:13::/64) au routeur 1, vous pouvez simplement ajouter une deuxième entrée Address à sa définition d’interface dans son fichier /etc/wireguard/wg0.conf :
# paramètres locaux pour le routeur 1
[Interface]
PrivateKey = 0F1111111111111111111111111111111
Si vous n'avez pas besoin d'échanger les routes IPv4, vous pouvez remplacer la configuration `/etc/bird/bird.conf` sur le routeur 1 par ce qui suit :
```bash
router id 10.99.13.1;
protocol device {
}
protocol kernel {
ipv6 {
export where proto = "wg6";
};
}
protocol ospf v3 wg6 {
ipv6 {
export all;
};
area 10.99.13.0 {
interface "wg0";
};
}
protocol ospf v3 lan6 {
ipv6 {
export all;
};
area 0 {
interface "eth0";
};
}
Les seules différences entre cette configuration IPv4 et la version IPv6 sont :
- Elle utilise
v2au lieu dev3pour les blocsprotocol ospf. - Elle donne des identifiants différents aux instances du protocole :
wg6pour l’instance échangeant les routes OSPFv3 sur l’interfacewg0, etlan6pour l’instance échangeant les routes OSPFv3 sur l’interfaceeth0. Ces identifiants sont arbitraires, cependant — vous pouvez les changer en ce qui vous convient. - Comme nous utilisons des adresses link-local IPv6 pour WireGuard, nous n’avons pas besoin d’un filtre explicite dans le bloc
protocol ospf v3 wg6pour exclure nos adresses WireGuard de l’importation dans la tablemaster6de BIRD — BIRD les filtrera automatiquement (puisque cela ne fait pas sens d’échanger des routes vers des adresses link-local).
Si vous avez besoin à la fois de IPv4 et de IPv6, ajoutez les blocs protocol kernel et protocol ospf IPv6 au fichier /etc/bird/bird.conf de la version IPv4 du routeur 1 :
router id 10.99.13.1;
protocol device {
}
protocol kernel {
ipv4 {
export where proto = "wg";
};
}
protocol ospf v2 wg {
ipv4 {
import where net !~ 10.99.13.0/24;
export all;
};
area 10.99.13.0 {
interface "wg0";
};
}
protocol ospf v2 lan {
ipv4 {
export all;
};
area 0 {
interface "eth0";
};
}
protocol kernel {
ipv6 {
export where proto = "wg6";
};
}
protocol ospf v3 wg6 {
ipv6 {
export all;
};
area 10.99.13.0 {
interface "wg0";
};
}
ipv6 {
export all;
};
area 0 {
interface "eth0";
};
}
Apportez des modifications similaires au fichier /etc/bird/bird.conf sur tous les routeurs WireGuard ; la version IPv6 seule pour le Routeur 2 serait comme suit :
router id 10.99.24.2;
protocol device {
}
protocol kernel {
ipv6 {
export where proto = "wg6";
};
}
protocol ospf v3 wg6 {
ipv6 {
export all;
};
area 10.99.24.0 {
interface "wg0";
};
}
protocol ospf v3 lan6 {
ipv6 {
export all;
};
area 0 {
interface "eth0";
};
}
Et le Routeur 3 comme suit :
router id 10.99.13.3;
protocol device {
}
protocol kernel {
ipv6 {
export where proto = "wg6";
};
}
protocol ospf v3 wg6 {
ipv6 {
export all;
};
area 10.99.13.0 {
interface "wg0";
};
}
protocol ospf v3 lan6 {
ipv6 {
export all;
};
area 0 {
interface "eth0";
};
}
Et le Routeur 4 comme suit :
router id 10.99.24.4;
protocol device {
}
protocol kernel {
ipv6 {
export where proto = "wg6";
};
}
protocol ospf v3 wg6 {
ipv6 {
export all;
};
area 10.99.24.0 {
interface "wg0";
};
}
protocol ospf v3 lan6 {
ipv6 {
export all;
};
area 0 {
interface "eth0";
};
}
Rechargez vos modifications dans chaque fichier /etc/bird/bird.conf :
bird> configure
Lecture de
La configuration depuis `/etc/bird/bird.conf`
Reconfiguré
Après le rechargement, sur chaque routeur WireGuard, vous devriez voir un voisin pour l'instance OSPF `wg6` :
```bash
bird> show ospf neighbors wg6
wg6:
Router ID Pri State DTime Interface Router IP
10.99.13.3 1 Full/PtP 35.956 wg0 fe99:13::3
Et au moins un voisin pour l’instance OSPF lan6 :
bird> show ospf neighbors lan6
lan6:
Router ID Pri State DTime Interface Router IP
192.168.1.65 10 Full/DR 39.184 eth0 fe80::1921:68ff:fe01:65/64
Et chaque routeur devrait avoir au moins un chemin vers toutes les routes exposées par OSPF sur n’importe quel sous-réseau LAN dans la table master6 de BIRD :
bird> show route
Table master6:
2001:db8:1:100::/56 unicast [lan6 18:25:47.947] I (150/10) [10.99.13.1]
dev eth0
unicast [lan6 18:25:47.947] E1 (150/20) [192.168.1.65]
via fe80::1921:68ff:fe01:65 on eth0
2001:db8:1:300::/56 unicast [lan6 18:25:47.947] E1 (150/30) [192.168.1.193]
via fe80::1921:68ff:fe01:65 on eth0
2001:db8:3::/48 unicast [lan6 18:25:47.947] E1 (150/30) [192.168.1.1]
via fe80::1921:68ff:fe01:65 on eth0
2001:db8:4::/48 unicast [lan6 18:25:47.947] E1 (150/30) [192.168.1.1]
via fe80::1921:68ff:fe01:65 on eth0
2001:db8:200::/56 unicast [wg6 19:37:19.495] E1 (150/20) [10.99.13.3]
via fe99:13::3 on wg0
unicast [lan6 20:14:51.882] E1 (150/60) [192.168.200.1]
via fe80::1921:68ff:fe01:65 on eth0
2001:db8:200:200::/56 unicast [wg6 19:37:19.495] E1 (150/30) [192.168.200.1]
via fe99:13::3 on wg0
unicast [lan6 20:14:51.882] E1 (150/50) [192.168.200.193]
via fe80::1921:68ff:fe01:65 on eth0
2001:db8:200:300::/56 unicast [wg6 19:37:19.495] E1 (150/40) [192.168.200.193]
via fe99:13::3 on wg0
unicast [lan6 20:14:51.882] E1 (150/40) [10.99.24.4]
via fe80::1921:68ff:fe01:65 on eth0
Et chaque routeur devrait avoir le meilleur chemin pour chaque sous-réseau à l’autre site dans sa table main IPv6 de son système d’exploitation (où les routes exportées par BIRD seront listées avec proto bird) :
$ ip -6 route
::1 dev lo proto kernel metric 256 pref medium
2001:db8:1:100::/56 dev eth0 proto ra metric 100 pref medium
2001:db8:200::/56 via fe99:13::3 dev wg13 proto bird metric 32 pref medium
2001:db8:200:200::/56 via fe99:13::3 dev wg13 proto bird metric 32 pref medium
2001:db8:200:300::/56 via fe99:13::3 dev wg13 proto bird metric 32 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe99::/64 dev wg0 proto kernel metric 256 pref medium
default via fe80::1921:68ff:fe01:65 dev eth0 proto ra metric 100 expires 1792sec pref medium
Avec cela en place, vous devriez maintenant être capable de pinguer l’adresse IPv6 du Point de terminaison B (à 2001:db8:200:22::1) dans le Site B depuis le Point de terminaison A (à 2001:db8:1:91::1) dans le Site A (en supposant que vous n’ayez pas de pare-feu bloquant les paquets ICMPv6 entre les deux hôtes) :
$ ping -nc1 2001:db8:200:22::1
PING 2001:db8:200:22::1 (2001:db8:200:22::1) 56 data bytes
64 bytes from 2001:db8:200:22::1: icmp_seq=1 ttl=59 time=23.3 ms
--- 2001:db8:200:22::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 23.279/23.279/23.279/0.000 ms
Et si vous tuez l’un des liens WireGuard entre le Site A et le Site B (comme pour les tests, exécutez sudo wg-quick down wg0 sur le Routeur 1), vous devriez toujours être capable de pinguer le Point de terminaison B depuis le Point de terminaison A — le routeur LAN du Point de terminaison A doit recevoir la mise à jour d’état du lien via OSPF, et ré-routage le trafic entre le Point de terminaison A et le Point de terminaison B via l’autre lien WireGuard.
Ou bien Utilisez BGP
Avec IPv6
BGP peut échanger des routes IPv6 sur IPv4 et des routes IPv4 sur IPv6, donc vous n’avez pas besoin de modifier beaucoup la configuration BGP de BIRD pour utiliser IPv6. Vous devez néanmoins configurer les routeurs WireGuard pour utiliser OSPFv3 sur les adresses link-local IPv6, comme décrit ci-dessus.
Une fois que vous avez fait cela, vous pouvez échanger des routes uniquement en IPv6 avec une configuration comme celle-ci (pour le Routeur 1) :
router id 10.99.13.1;
protocol device {
}
protocol kernel {
ipv6 {
export where proto = "wg6";
};
}
protocol ospf v3 wg6 {
ipv6 {
export all;
};
area 10.99.13.0 {
interface "wg0";
};
}
protocol direct {
ipv6;
interface "eth0";
}
protocol bgp {
ipv6 {
export all;
next hop self;
};
local as 65000;
neighbor 2001:db8:3:1::1 internal;
}
Pour échanger à la fois les routes IPv4 et IPv6, vous configureriez plutôt le fichier de configuration du routeur /etc/bird/bird.conf comme suit (pour le routeur 1) :
router id 10.99.13.1;
protocol device {
}
protocol kernel {
ipv4 {
export where proto = "wg";
};
}
protocol ospf v2 wg {
ipv4 {
import where net !~ 10.99.13.0/24;
export all;
};
area 10.99.13.0 {
interface "wg0";
};
}
protocol kernel {
ipv6 {
export where proto = "wg6";
};
}
protocol ospf v3 wg6 {
ipv6 {
export all;
};
area 10.99.13.0 {
interface "wg0";
};
}
protocol direct {
ipv4;
ipv6;
interface "eth0";
}
protocol bgp {
ipv4 {
export all;
next hop self;
};
ipv6 {
export all;
next hop self;
next hop address 2001:db8:1:111::1;
};
local as 65000;
neighbor 192.168.3.1 internal;
}
Comme les instances protocol kernel et protocol ospf, les mêmes instances protocol direct et protocol bgp peuvent être utilisées pour les deux IPv4 et IPv6. Mais dans la section protocol bgp, vous devrez déclarer l’adresse spécifique next hop address à utiliser pour le routeur WireGuard sur le canal par lequel les routes ne sont pas échangées (c’est-à-dire si les routes sont échangées via IPv4, vous devrez spécifier l’adresse de saut suivant pour le canal IPv6, comme dans l’exemple ci-dessus ; si les routes étaient échangées via IPv6, vous devriez cependant spécifier l’adresse de saut suivant pour le canal IPv4).
by Justin Ludwig translated by: Patrice Le Guyader