Dans la première partie, on a vu comment le réseau DN42 se présente par rapport à Internet et comment s'enregistrer sur le registre pour obtenir un AS et des IP à annoncer. Dans cette partie, nous allons mettre en place notre premier nœud sur le réseau, à savoir un routeur BGP. Il servira notamment à annoncer aux autres que nos adresses existent et comment on peut nous joindre.
Pour vous donner une idée plus claire, voici un schéma de ce qu'on va obtenir à la fin (obtenu via l'outil Asciiflow) :
+----------------+
|+--------------+|
+----------------->|| DN42 NETWORK ||<-----------------+
| |+--------------+| |
| +----------------+ |
| ^ |
| | |
| | |
| | |
| | |
v v v
+----+----+ +-----+----+ +----+----+
| Kioubit | | Mirsal | | Aeris |
+---------+ +----------+ +---------+
fdfc:e23f:ffff:3234::8 fdfa:ead5:d47f:3f::3 fdfa:ead5:d47f:3f::7
^ ^ ^
| | |
| | |
|wg1 |wg0 |wg3
|fdfa:ead5:d47f:3f:: |fdfa:ead5:d47f:3f::2 |fdfa:ead5:d47f:3f::6
| | |
| +------+-----+ |
+--------------------| dn42-tas |--------------------+
+------------+
Qu'est-ce que BGP ?
BGP est un protocole qui sert à annoncer des routes pour aller d’une destination à une autre. Il permet ainsi d'échanger des informations de routage entre plusieurs AS et de calculer des routes pour les relier. Ces routes sont définies selon des attributs que l'on peut modifier : par exemple, on peut favoriser certains chemins parcourus ou bien interdire les routes que l'on ne souhaite pas diffuser/utiliser. Pour utiliser ce protocole, on met en place des routeurs BGP qui s’interconnectent et annoncent les routes des uns et des autres.
C'est ce principe qui permet entre autres de passer d'un point à un autre sans qu'on remarque quoi que ce soit en surface.
Si vous voulez avoir plus de détails, vous pouvez consulter en parallèle la page Wikipédia dédiée.
Choix des logiciels
Pour le choix de l'OS, j'avais envie de partir sur des bases solides et simples : mon AS sera composé principalement de machines sous OpenBSD. Pour la partie VPN, je ferai le choix de Wireguard, une technologie simple à mettre en place et souvent utilisée au sein de DN42. Je réutiliserai en partie des instructions provenant de mon tutoriel sur ce type de VPN.
Concernant la partie BGP, il existe plusieurs logiciels de routeur BGP. Les plus connus sont FRRouting et Bird. Bird est très populaire sur DN42 : c’est celui avec la configuration la plus complète sur le wiki officiel. Dans mon cas, je vais utiliser OpenBGPD, un routeur BGP développé par des membres d’OpenBSD. Ce dernier est présent par défaut et il a l'avantage d'avoir une syntaxe assez simple à comprendre. Il souffre néanmoins d'un manque de documentation sur le wiki officiel, même si on peut trouver un fichier de base pour bien commencer. Quelques contributeurs ont d'ailleurs participé récemment à étoffer cette documentation.
Pour écrire cet article, je me suis donc basé sur plusieurs sources en anglais :
- la page dédiée à OpenBGPD sur le wiki dn42 : howto/OpenBGPD
- un tutoriel sur OpenBGPD écrit par kaizo : OpenBSD bgpd - kaizo.org
- et bien sûr, la documentation officielle d'OpenBGPD :
man bgpd.confou https://man.openbsd.org/bgpd.conf.5
Préparation de la machine
Dans cet article, nous allons donc utiliser une machine virtuelle située sur un hyperviseur Proxmox. Son installation ne sera pas détaillée ici, mais les instructions génériques sont disponibles en anglais sur le site du projet : https://ftp.openbsd.org/pub/OpenBSD/7.5/amd64/INSTALL.amd64.
Une fois l'installation terminée, il est important d'activer le routage IP (IP forwarding) dans le noyau pour éviter certains problèmes et transformer la machine en routeur. Pour cela, il suffit d'activer ces options via sysctl :
$ doas sysctl net.inet6.ip6.forwarding=1
$ doas sysctl net.inet.ip.forwarding=1
$ doas vi /etc/sysctl.conf
net.inet6.ip6.forwarding=1
net.inet.ip.forwarding=1
Le fichier sysctl.conf permet au système d'appliquer automatiquement les options au démarrage de la machine et de s'assurer que tout fonctionne après un redémarrage.
On installe enfin les outils nécessaires pour utiliser Wireguard sous OpenBSD, via le gestionnaire de paquets : doas pkg_add wireguard-tools
Faire des demandes de peerings
Pour annoncer notre préfixe, il nous faut ce qu’on appelle des pairs (ou peers en anglais). Un pair va se charger de faire le relais entre les autres routeurs du réseau et nous et va annoncer une route pour nous joindre. Ce sont eux qui vont nous permettre d'échanger des paquets. De manière générale, plus on possède de peers, plus on est redondant par rapport aux coupures, et plus on peut nous joindre de différentes manières.
Sur DN42, il y a deux moyens de faire des demandes de peering : contacter gentiment un autre membre ou bien aller vers un membre qui fait des peerings automatiques. Dans mon cas, j’ai choisi un mix des deux : le camarade qui m’a introduit à DN42 voulait être un de mes pairs et j’ai fait des demandes avec plusieurs membres via leur outil de provisionnement automatique.
Pour établir un peering sur DN42, vous devez configurer un tunnel VPN avec la personne avec qui vous voulez vous interconnecter et lui communiquer votre numéro d'AS. Ce numéro va servir à créer un bout de configuration au niveau de son routeur BGP, pour que celui-ci reconnaisse vos échanges.
Dans la majorité des configurations DN42 pour IPv6, on utilise des adresses de type Lien-local pour les échanges BGP. Sur OpenBSD, ce fonctionnement est possible, mais demande une option supplémentaire dans la configuration d'OpenBGPD pour pouvoir insérer correctement les routes réseau dans la pile du noyau. Dans cet article, je vais donc utiliser, à la place, ce qu'on appelle des adresses de transfert : il s'agit d'un sous-réseau dédié uniquement aux sessions BGP. Pour IPv6, on définit alors un préfixe en /64 découpé depuis le préfixe en /48 qui nous est alloué.
Mon bloc de transfert sera donc celui-ci : fdfa:ead5:d47f:3f::/64.
Exemple avec un peering automatique : Kioubit
Kioubit est un des plus gros membres de DN42 : il fournit de très nombreux services, notamment un service de résolveurs DNS et il est connecté avec un très grand nombre de pairs. Pour s'interconnecter avec lui, un outil de peering automatique est disponible sur son site à l'adresse suivante : https://dn42.g-load.eu/auth/.
En se rendant sur la page, une demande d'authentification est requise pour identifier notre AS et obtenir la liste de nos peerings. On indique alors son numéro d'AS et on choisit ensuite une des méthodes pour s'authentifier (déchiffrement d'un message avec PGP ou bien un code par e-mail dans mon cas).
Une fois que cette authentification est réussie, on reçoit aussi un petit code qui servira de jeton (ou logincode) pour se connecter rapidement les prochaines fois. Je vous conseille de le stocker dans un gestionnaire de mots de passe.
Après connexion, on obtient une liste des peerings en cours avec Kioubit : cette liste devrait être vide si on se connecte pour la première fois.
Pour obtenir un peering, on clique alors sur le bouton Add new peering. On sélectionne ensuite un des nœuds les plus proches de nous pour avoir une latence faible : dans mon cas, ce sera fr1.g-load.eu. On arrive ensuite sur un formulaire qui nous demande les informations pour établir un tunnel VPN. On entre alors les informations suivantes :
- Tunnel Protocol : choisir Wireguard
- Wireguard Public Key : indiquer la clé publique de votre tunnel (à générer avant avec les commandes disponibles ci-après)
- Tunnel IPv4 Address : laisser vide ce champ. L'adresse IPv4 générée ne sera pas utilisée ici.
- Tunnel IPv6 Address : Indiquer une adresse en /128 provenant du bloc de transfert, ici
fdfa:ead5:d47f:3f:: - Multiprotocol BGP : Ne pas le cocher (car pas d'IPv4 sur cet AS)
- Extended next hop : Ne pas le cocher (Non supporté par défaut)
On clique enfin sur le bouton Create peering et on obtient alors un résumé des informations que l'on a indiquées avant, ainsi que les informations que Kioubit a générées de son côté pour établir le tunnel. On utilisera ces informations pour créer la configuration sur notre machine.
Créer les tunnels d'interconnexion
Pour les interconnexions, on utilise des tunnels VPN dédiés qui se connecteront sur le nœud de chaque pair. On va donc créer plusieurs interfaces réseaux sur la machine pour gérer nos différents tunnels Wireguard. Dans tous les cas, on commence par générer les clés de chaque tunnel dans un dossier dédié pour les conserver en cas de problème :
$ su
> mkdir /etc/wireguard && cd /etc/wireguard
> wg genkey | tee privatekey-kioubit | wg pubkey > publickey-kioubit
> wg genkey | tee privatekey-mirsal | wg pubkey > publickey-mirsal
> wg genkey | tee privatekey-aeris | wg pubkey > publickey-aeris
Les fichiers des interfaces seront stockés dans le dossier /etc et utiliseront la syntaxe suivante pour le nom : hostname.wgX où X est le numéro de l'interface voulue. Chaque fichier contient aussi les informations fournies par le pair pour pouvoir se connecter.
Kioubit
Pour reprendre mon exemple avec Kioubit, voici le contenu de l'interface wg1 qui lui est dédié sur cette machine :
> doas vim /etc/hostname.wg1
wgkey <privatekey> # cat /etc/wireguard/privatekey-kioubit
wgpeer <publickey-from-Kioubit> wgendpoint fr1.g-load.eu 22561 wgaip fe80::/64 wgaip fd00::/8
up
inet6 fe80::ade1/64
inet6 fdfa:ead5:d47f:3f::/128
!route add fdfc:e23f:fb45:3234::8/128 fe80::ade1%wg1
Ici, la règle essentielle au bon fonctionnement de notre routeur est l'instruction commençant par !route add : cette commande permet de rajouter une route réseau pour pouvoir contacter l'adresse DN42 donnée par l'outil de Kioubit. En effet, pour établir la session BGP avec son routeur, il est nécessaire de forcer le passage du trafic vers cette IP dans le tunnel Wireguard.
Dans ce fichier, on peut noter la présence d'une adresse de lien-local (celle qui commence par fe80). En réalité, il s'agit d'un reste de la première configuration que j'ai eue avec lui, notamment pour faire plusieurs tests. Si on utilise des adresses de transfert, il n'est pas indispensable d'utiliser des adresses de lien-local dans les tunnels, mais cela peut faciliter le déboguage.
Attention : Avec certains outils automatiques, il est recommandé de ne pas les ajouter, car ils ne sont pas toujours capables de configurer correctement les sessions BGP si les deux types sont présents : c'est le cas avec l'outil de IEDON-NET qui utilise l'adresse de lien-local par défaut si elle est présente.
Mirsal
Dans le cas d'un peering manuel, il est alors possible de demander à la personne de créer sa configuration en utilisant une adresse de transfert définie à l'avance. C'est typiquement ce que j'ai mis en place avec Mirsal, après une grosse session de debug et de tests. Sur mon interface Wireguard, je définis un /127 (fdfa:ead5:d47f:3f::2/127) pour obtenir un ensemble de deux IP qui se suivent et je communique la deuxième adresse IP à mon pair pour qu'il l'utilise sur son interface (soit fdfa:ead5:d47f:3f::3/127).
Le reste sera automatiquement calculé par OpenBSD pour créer les routes nécessaires pour le trafic dans ce tunnel.
Voici donc ce que cela donne pour le contenu de l'interface wg0 pour Mirsal :
> doas vim /etc/hostname.wg0
wgkey <privatekey> wgport 22308 # cat /etc/wireguard/privatekey-mirsal
wgpeer <publickey-from-Mirsal> wgendpoint 2a01:e0a:173:2140:20a:faff:fe24:2675 22561 wgaip fe80::/64 wgaip fd00::/8
up
inet6 fe80::b00b/64
inet6 fdfa:ead5:d47f:3f::2/127
Aeris
Un autre exemple de peering manuel avec Aeris, une personne que j'ai contactée sur le Fediverse suite à son message de recherche de pairs pour DN42. Cette configuration ressemble beaucoup à celle de Mirsal, si ce n'est que c'est un autre bloc en /127 qui est utilisé pour les échanges :
> doas vim /etc/hostname.wg3
wgkey <privatekey> wgport 23415 # cat /etc/wireguard/privatekey-aeris
wgpeer <publickey-from-Aeris> wgendpoint exegol.imirhil.fr 22561 wgaip fe80::/64 wgaip fd00::/8
up
inet6 fe80::2561/64
inet6 fdfa:ead5:d47f:3f::6/127
Activation des interfaces
Une fois les différentes interfaces ajoutées, on peut lancer les connexions en rechargeant simplement le réseau :
$ doas sh /etc/netstart
$ doas wg show
interface: wg0
public key: (hidden)
private key: (hidden)
listening port: 22308
peer: (hidden)
allowed ips: fd00::/8, fe80::/64
latest handshake: 19 seconds ago
transfer: 528.05 MiB received, 145.88 MiB sent
interface: wg1
public key: (hidden)
private key: (hidden)
listening port: 45150
peer: (hidden)
endpoint: 94.23.2.110:22561
allowed ips: fd00::/8, fe80::/64
latest handshake: 29 seconds ago
transfer: 398.60 MiB received, 165.65 MiB sent
interface: wg3
public key: (hidden)
private key: (hidden)
listening port: 23415
peer: (hidden)
allowed ips: fd00::/8, fe80::/64
latest handshake: 51 seconds ago
transfer: 28.30 MiB received, 11.33 MiB sent
Les liens physiques sont maintenant en place et on devrait voir du trafic passer dans les tunnels, ainsi qu'un handshake assez récent. Cela valide le fonctionnement de nos tunnels et on peut donc passer à la configuration de notre routeur BGP.
Mettre en place OpenBGPD
OpenBGPD se configure dans le fichier /etc/bgpd.conf, fichier qui n'existe pas par défaut. Pour le créer, vous pouvez recopier celui existant dans les examples ou bien partir de zéro en reprenant celui présent sur le wiki de DN42. C'est cette deuxième option que j'ai choisie de faire dans cet article.
Définir la configuration de base
Pour définir la configuration de base, on a besoin des éléments suivants :
- le numéro de notre AS : ici,
4242422561 - le préfixe à annoncer : ici,
fdfa:ead5:d47f::/48
On ouvre ensuite le fichier /etc/bgpd.conf dans notre éditeur préféré et on recopie le contenu adapté à l'AS choisi :
# $OpenBSD: bgpd.conf,v 1.22 2023/09/27 10:49:21 claudio Exp $
# Final configuration for VINISHOR-DN42
## Options for the AS
# define our own ASN as a macro
ASN="4242422561" ## Numero de l'AS
# global configuration
AS $ASN
router-id 45.13.105.181 ## Mettre une adresse IPv4 publique pour faire office d'identifiant
# list of networks that may be originated by our ASN
prefix-set dn42 {
fdfa:ead5:d47f::/48 ## Remplacer par le bon prefixe
}
socket "/var/www/run/bgpd.rsock" restricted
## Defintion for large-community
network prefix-set dn42 set large-community $ASN:1:1
L'option router-id sert à identifier le routeur BGP entre ses pairs : la valeur que l'on indique est une adresse IPv4 publique (une venant de DN42 si on a réservé des IPv4 ou bien celle du nœud sur Internet), même si elle n'est pas utilisée en tant que tel. Le bloc prefix-set sert à définir les préfixes que l'on va annoncer sous la forme d'une variable : ici, la variable dn42 fera référence au préfixe assigné dans le registre de DN42.
L'option socket sert notamment pour la connexion d'une looking glass : il s'agit d'un logiciel qui va se charger d'envoyer des commandes BGP au routeur pour afficher ce qu'il répond aux autres membres. J'ai justement l'intention d'en avoir une, donc j'active cette option.
Définir les peers
On continue les ajouts dans la configuration avec la partie dédiée aux pairs. Ici, on crée un groupe pour rassembler tous nos pairs BGP dans un seul endroit. Dans ce groupe, je définis deux sections neighbor qui contiennent les ASN de mes peers et une description qui sera utilisée pour nommer la connexion. Chaque neighbor est directement suivi de l'adresse de transfert qu'on a défini plus haut pour chaque pair :
## Peers definition
group "peering dn42" {
# mirsal
neighbor fdfa:ead5:d47f:3f::3 {
remote-as 4242422308
descr dn42_mirsal_ebgp
}
# kioubit
neighbor fdfc:e23f:fb45:3234::8 {
remote-as 4242423914
descr dn42_kioubit_ebgp
}
# aeris
neighbor fdfa:ead5:d47f:3f::7 {
remote-as 4242423415
descr dn42_aeris_ebgp
}
}
Définir les règles de routage BGP
Pour terminer la configuration, on passe sur la partie concernant les règles du routeur. Cette partie étant assez cruciale et compliquée, je vais détailler le maximum de ce qui est présent dans le bloc ci-dessous.
Tout d'abord, il est essentiel de connaître la différence entre IBGP et EBGP : dans le protocole BGP, on appelle EBGP (pour External BGP) tout ce qui concerne les échanges entre deux AS différents. Dans notre cas, il s'agit des échanges entre notre routeur et celui de nos pairs.
IBGP (pour Internal BGP) désigne lui le trafic entre deux routeurs BGP d'un même AS. Cela sert, par exemple, à relier un routeur situé dans une zone géographique A et un autre routeur à nous, situé dans une région géographique B.
Ensuite, il est important que nos préfixes ne soient annoncés que par nous-même, donc nous allons devoir définir une règle pour interdir les annonces de notre préfixe qui proviennent de l'extérieur. On va également bloquer le trafic qui passe par un trop grand nombre d'AS, afin de conserver une limite et d'obtenir de meilleures latences.
On aura aussi besoin de mettre en place une règle pour utiliser le ROA (pour Route Origin Authorizations). Le ROA est central sur DN42 : il s'agit d'un moyen de valider l'origine d'un ou plusieurs préfixes et de s'assure que seul l'AS autorisé peut diffuser les routes vers ceux-ci.
Enfin, le reste des règles servira notamment à autoriser tout ce qui vient de IBGP (notamment si ce sont nos routeurs de bordure) et ajouter quelques options utiles pour la bonne gestion du routeur BGP.
Voici donc le bloc à mettre en place dans le fichier de configuration :
## rules section
# deny more-specifics of our own originated prefixes
deny quick from ebgp prefix-set dn42 or-longer
# filter out too long paths, establish more peerings instead
deny quick from any max-as-len 8
# Outbound EBGP: only allow self originated networks to ebgp peers
# Don't leak any routes from upstream or peering sessions. This is done
# by checking for routes that are tagged with the large-community $ASN:1:1
allow to ebgp prefix-set dn42 large-community $ASN:1:1
# enforce ROA
allow from ebgp ovs valid
# IBGP: allow all updates to and from our IBGP neighbors
allow from ibgp
allow to ibgp
# Scrub normal and large communities relevant to our ASN from EBGP neighbors
# https://tools.ietf.org/html/rfc7454#section-11
match from ebgp set { large-community delete $ASN:*:* }
# Honor requests to gracefully shutdown BGP sessions
# https://tools.ietf.org/html/rfc8326
match from any community GRACEFUL_SHUTDOWN set { localpref 0 }
# include the roa-set (https://dn42.eu/howto/OpenBGPD)
# defines roat-set, see _rpki-client crontab
include "/etc/bgpd/dn42.roa-set"
Avec ce bloc, on a une configuration prête à l'emploi pour pouvoir communiquer avec les routeurs de nos pairs. Il ne reste qu'à rajouter le fichier qui contient les informations de ROA, c'est-à-dire le fichier mentionné ci-dessus dans la ligne include. On crée donc le dossier nécessaire, on télécharge ce fichier et on rajoute une commande pour le mettre à jour dans la crontab de la machine :
# mkdir -p /etc/bgpd/
# /usr/local/bin/curl -sfSLR -o/etc/bgpd/dn42.roa-set -z/etc/bgpd/dn42.roa-set https://dn42.burble.com/roa/dn42_roa_obgpd_6.conf
# crontab -e
*/15 * * * * /usr/local/bin/curl -sfSLR -o/etc/bgpd/dn42.roa-set -z/etc/bgpd/dn42.roa-set https://dn42.burble.com/roa/dn42_roa_obgpd_6.conf && bgpctl reload
Cette commande va automatiquement récupérer un fichier généré par une machine de Burble, un autre gros membre du réseau. Ce fichier se met à jour en fonction de ce qui est présent dans le registre de DN42 et contient les ROA de tous les AS présents, ce qui permet d'avoir une bonne base pour valider les routes. Il existe plusieurs formats de ce même fichier pour être compatible avec un maximum de logiciels.
On peut ensuite activer et démarrer OpenBGPD : # rcctl enable bgpd && rcctl start bgpd
En quelques instants, OpenBGPD va se mettre à écouter sur toutes les interfaces de la machine (comportement par défaut) et tenter de lancer des sessions BGP avec nos pairs. Dans le cas d'un peering automatique, la configuration est en place au bout de quelques minutes après génération de la configuration VPN et une session sera établie dans la foulée. Dans le cas d'un peering manuel, la session ne sera établie qu'après ajout de votre AS dans la configuration du routeur BGP du pair.
Vérifier que tout est bon
Pour voir les sessions en cours, on peut utiliser la commande bgpctl show neighbor en tant que root (le résultat de la commande est tronqué) :
$ doas bgpctl show neighbor
BGP neighbor is fdfa:ead5:d47f:3f::3, remote AS 4242422308
Description: dn42_mirsal_ebgp
BGP version 4, remote router-id 172.23.107.1
BGP state = Established, up for 5d11h13m
....
BGP neighbor is fdfc:e23f:fb45:3234::8, remote AS 4242423914
Description: dn42_kioubit_ebgp
BGP version 4, remote router-id 172.20.53.102
BGP state = Established, up for 2d15h22m
.....
BGP neighbor is fdfa:ead5:d47f:3f::7, remote AS 4242423415
Description: dn42_aeris_ebgp
BGP version 4, remote router-id 172.20.212.129
BGP state = Established, up for 5d17h14m
.....
La ligne mentionnant BGP state = nous indique l'état de la session BGP et depuis combien de temps la session est établie (ou uptime en anglais). Une liaison Established signifie que notre routeur BGP communique bien avec le pair concerné.
Pour s'en assurer, on peut afficher la table RIB qui contient toutes les routes calculées via bgpctl show rib :
$ doas bgpctl show rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
aspa validation state: ? = unknown, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete
flags vs destination gateway lpref med aspath origin
*> V-? fd00:21:259e::/48 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242422547 4242420293 i
* V-? fd00:21:259e::/48 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242423914 4242422547 4242420293 i
*> V-? fd00:bb:5bf3::/48 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242420549 i
* V-? fd00:bb:5bf3::/48 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242423914 4242420549 i
*> V-? fd00:bb:5bf3::/64 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242420549 i
* V-? fd00:bb:5bf3::/64 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242423914 4242420549 i
*> V-? fd00:bb:5bf3:3441::/64 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242420549 i
* V-? fd00:bb:5bf3:3441::/64 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242423914 4242420549 i
*> V-? fd00:bb:5bf3:4421::/64 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242420549 i
* V-? fd00:bb:5bf3:4421::/64 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242423914 4242420549 i
*> V-? fd00:420:69::/48 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242423117 i
* V-? fd00:420:69::/48 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242423914 4242423117 i
*> V-? fd00:1072:9982::/48 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242421686 4242423745 4242420772 i
* V-? fd00:1072:9982::/48 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242423914 4242421686 4242423745 4242420772 i
*> V-? fd00:1145:1419::/48 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242422189 4242421857 i
*m V-? fd00:1145:1419::/48 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242422189 4242421857 i
*> V-? fd00:1171:1171::/48 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242421171 i
* V-? fd00:1171:1171::/48 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242423914 4242421171 i
*> V-? fd00:11ea:8d63::/48 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242421592 4242422936 i
*m V-? fd00:11ea:8d63::/48 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242422923 4242422936 i
*> V-? fd00:1444:1821::/48 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242423035 4242422914 i
*m V-? fd00:1444:1821::/48 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242423035 4242422914 i
*> V-? fd00:1926:817::/48 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242421331 i
* V-? fd00:1926:817::/48 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242423914 4242421331 i
*> V-? fd00:41a0:4f2::/64 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242423088 4242423717 i
*m V-? fd00:41a0:4f2::/64 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242422189 4242423717 i
*> V-? fd00:41a0:4f2:1::/64 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242423717 i
* V-? fd00:41a0:4f2:1::/64 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242423914 4242423717 i
*> V-? fd00:41a0:4f2:2::/64 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242423717 i
* V-? fd00:41a0:4f2:2::/64 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242423914 4242423717 i
*> V-? fd00:4242:3348::/48 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242422100 4242423991 4242423348 i
* V-? fd00:4242:3348::/48 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242423914 4242422100 4242423991 4242423348 i
*> V-? fd00:443a:ef14::/48 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242420361 i
* V-? fd00:443a:ef14::/48 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242423914 4242420361 i
*> V-? fd00:46c5:1654::/48 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242423618 4242422980 4242423953 4242423710 i
*m V-? fd00:46c5:1654::/48 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242421080 4242422980 4242423953 4242423710 i
*> V-? fd00:65a8:93a4::/48 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242422923 65142 i
*m V-? fd00:65a8:93a4::/48 fdfa:ead5:d47f:3f::3 100 0 4242422308 4242422923 65142 i
*> V-? fd00:82fa:2a76::/48 fdfc:e23f:fb45:3234::8 100 0 4242423914 4242422717 4242420920 i
[....]
Le symbole * signifie que la route est valide et peut être prise en compte par OpenBGPD et le symbole > signifie que c'est cette route qui est utilisée pour joindre la destination indiquée (notamment s'il existe plusieurs routes pour la destination en question).
Si on obtient ce résultat, alors cela signifie que tout est bon au niveau de BGP et qu'on peut accéder à DN42 dans son ensemble : on participe officiellement au réseau !
Allô le monde !
Pour vérifier que l'on peut accéder à DN42, il nous reste à adapter les serveurs DNS récursifs de la machine. Les serveurs récursifs de DN42 résolvent à la fois des noms en .dn42 et des noms sur Internet, ce qui est pratique sur une machine ayant accès à l'Internet conventionnel.
Pour cela, on peut utiliser le service unwind, présent de base sur OpenBSD. Il suffit de configurer le fichier /etc/unwind.conf avec le contenu ci-dessous avant d'activer et de lancer le service avec doas rcctl enable unwind && doas rcctl start unwind :
## Unwind configuration for DN42
forwarder { fd42:d42:d42:54::1 fd42:d42:d42:53::1 }
force accept bogus forwarder { "dn42." }
On peut ensuite tester que tout est bon :
$ doas rcctl check unwind
unwind(ok)
$ ping6 -c 2 wiki.dn42
PING wiki.dn42 (fd42:d42:d42:80::1): 56 data bytes
64 bytes from fd42:d42:d42:80::1: icmp_seq=0 hlim=60 time=42.394 ms
64 bytes from fd42:d42:d42:80::1: icmp_seq=1 hlim=60 time=43.346 ms
--- wiki.dn42 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 42.394/42.870/43.346/0.476 ms
Et voilà ! Notre routeur BGP peut accéder à tout DN42 et tout ce réseau peut nous joindre via les adresses qu'on annonce avec ce dernier !
Si besoin, on peut aussi utiliser des outils externes pour vérifier que notre AS est joignable et que les routes sont calculés correctement :
- l'outil Routegraphs qui permet de tester l'accès à notre préfixe et de dessiner un schéma clair
- l'outil DN42 Realtime Map pour afficher une cartographie de tous les AS
Conclusion
Grâce à cet article, nous avons maintenant un AS déclaré dans DN42 et un routeur BGP qui fait office d'annonceur pour celui-ci. Une bonne base pour commencer les expérimentations et apprendre quelques notions. Dans la suite de cette série, deux articles sont à prévoir : l'un sera dédié à nos premières VM pour DN42, afin de construire le SI de notre AS, et l'autre parlera de IBGP et de la mise en place d'un second routeur BGP.