Faire de l'administration système est quelque chose que j'ai l'habitude de faire depuis quelques années. Que ce soit dans mon travail ou bien sur mon temps libre, j'en profite toujours pour mettre les mains dans le cambouis et gérer au mieux mes machines.
Pour autant, le petit curieux en moi a envie de tester quelque chose de différent : faire du réseau. Cela peut sembler similaire à ce que je fais déjà, mais il n'en est rien : quand je parle de faire du réseau, je parle d'interconnexion, d'échanges de routes, d'annonces d'adresses IP, de transit. Bref, tout ce qui touche au routage des paquets et au fonctionnement direct d'Internet.
Vu que les technologies utilisées sont différentes et que j'aime bien apprendre par la pratique, je me suis récemment mis en tête de participer à un réseau en particulier : DN42. Ce réseau m'a été présenté par un camarade qui est ingénieur réseau et qui voulait s'amuser aussi dessus.
Voici donc le premier article de ma série dédiée à DN42 !
C'est quoi DN42 ?
DN42 est un réseau décentralisé qui est ouvert à tout le monde et qui a pour objectif de reproduire à petite échelle le fonctionnement d'Internet. Il s'agit d'un réseau superposé à Internet et utilisant des VPNs pour pouvoir être accessible. Son but premier est d'être un réseau d'expérimentations et de recherche, notamment pour apprendre à utiliser des technologies comme BGP, OSPF ou encore RPKI.
Sur DN42, IPv6 est très largement privilégié. Il existe bien des adresses IPv4, mais elles sont encore moins nombreuses que sur l'Internet conventionnel, ce qui accentue le problème de pénurie. Un excellent exercice pratique pour pouvoir comprendre ce problème et donc encourager à apprendre IPv6.
Sur DN42, les préfixes que les personnes utilisent sont ceux définis par les RFC 1918 et 4193, soit des préfixes privés : 172.20.0.0/14 en IPv4 et fd00::/8 en IPv6. Le filtrage au niveau des routeurs BGP prend en compte ce détail et seul le trafic venant de ces préfixes est autorisé sur DN42 (sur Internet, c'est souvent l'opposé : on autorise tout sauf certaines destinations).
Pourquoi se mettre sur DN42 ?
L'intérêt principal de DN42 est de pouvoir expérimenter sans forcément occasionner de gêne sur des équipements en production. Un mauvais routage ou des erreurs de configuration peuvent entraîner des soucis de routage global, des prefix hijacks (soit le fait d'annoncer des choses qui ne sont pas à nous) ou encore des insultes sur des listes de diffusion.
Un autre intérêt est que la participation à ce réseau est gratuite : aucun frais de transit ou de cross-connect par exemple. Cela peut être pratique pour déployer une petite infra de test, surtout si on veut utiliser des machines virtuelles ou du matériel qu'on ne maîtrise pas. L'enregistrement sur DN42 ne nécessite pas de payer un enregistrement auprès d'un bureau ou encore de demander à un sponsor de porter notre candidature.
Dans mon cas, je voulais aussi en profiter pour tester de nouvelles choses et en apprendre plus sur le fonctionnement du routage inter-réseaux.
Mise en place d'un AS
Pour commencer l'aventure DN42, on doit faire un peu d'administatif : l'idée est de s'enregistrer dans le registre et s'allouer ce que l'on va utiliser sur le réseau. Ce principe se fait habituellement à travers un RIR, un bureau d'enregistrement qui se charge de répartir les ressources entre tout le monde et de maintenir les bases de données à jour.
Sur DN42, ce rôle est remplacé par un dépôt git centralisé et validé via des clés PGP. Il est trouvable sur cette forge Git sous Gitea : git.dn42.dev.
Une petite note cependant : je partirai du principe que vous connaissez un peu git et que vous avez les outils nécesaires sur votre machine pour exécuter les commandes qui suiveront. Je sais que les systèmes sous MacOS, Linux et autres dérivés UNIX sont fournis avec ces outils.
Récupérer le registre
Pour accéder au registre, on crée d'abord un compte sur l'instance Gitea et on configure son compte avec une adresse e-mail librement diffusable (le spam existe), une clé SSH pour cloner les dépôts et une clé PGP pour valider nos commits. La clé PGP servira aussi à valider les informations que nous enverrons sur le dépôt. Je partirai du principe que vous savez en générer ou que vous en possédez déjà une. Si besoin, un excellent tutoriel en français est disponible en PDF.
Une fois cela fait, on peut commencer à rechercher le registre du réseau via cette adresse : https://git.dn42.dev/dn42/registry
Ce dépôt est modifiable par tout le monde, mais toute publication nécessite d'être vérifiée et validée avant publication. Pour cela, on clique sur le bouton Bifurcation (ou Fork) et on choisit de créer un nouveau dépôt sur son compte. Cela nous permettra de créer un demande de fusion en bonne et due forme et de faire les choses proprement.
On clone le tout sur son poste via la commande git : git clone git@git.dn42.dev:<votrepseudo>/registry.git
On rentre ensuite dans le dossier créé et on change quelques options pour pouvoir utiliser la clé PGP qu'on a indiqué sur notre compte, avant de créer une branche qui contiendra nos modifications :
cd registry
git config user.signingKey <EMPREINTEPGP>
git config commit.gpgSign true
git config user.name "votrepseudo"
git config user.email "votreadresse@e.mail"
git checkout -b <nomdebranche> ## à changer par un nom de votre choix
L'environnement de travail est prêt et on peut commencer les hostilités !
Déclarer son AS
Nom et numéro
Pour obtenir un AS et des ressources, il faut ajouter plusieurs objets dans le registre. Un objet est un fichier qui permet de définir des informations et qui sera ensuite lié au reste via son nom. Cela permet ainsi de lier un AS à une personne (ou une organisation) et à des adresses IP dans notre cas.
On commence par ajouter une fiche d'informations sur nous-même, via un fichier dans data/person. Voici un exemple en prenant ma fiche nommée VINISHOR-DN42 :
person: Vincent Finance
e-mail: network@linuxmario.net
www: https://vinishor.xyz/
pgp-fingerprint: 83F2E9F6682102576327A62544B1371C2A4252E2
nic-hdl: VINISHOR-DN42
mnt-by: VINISHOR-MNT
source: DN42
Le nom de la fiche servira à définir votre pseudo. Je vous conseille d'utiliser une adresse mail dédiée à DN42 : elle sera utile si on doit vous contacter pour des abus ou en cas de problèmes. Le formatage est également important, toute entrée doit commencer à la colonne 21. Cette information est vérifiable via votre éditeur de textes.
On crée ensuite une fiche de mainteneur, c'est-à-dire la personne qui se chargera de faire les modifications techniques. Elle se trouve dans data/mntner :
mntner: VINISHOR-MNT
admin-c: VINISHOR-DN42
tech-c: VINISHOR-DN42
mnt-by: VINISHOR-MNT
source: DN42
auth: pgp-fingerprint 83F2E9F6682102576327A62544B1371C2A4252E2
Si on s'arrête dessus, on commence à voir la relation avec le fichier précédent : dans la fiche person, j'ai mentionné le terme VINISHOR-MNT qui n'est autre que le nom de la fiche de mainteneur qu'on vient de créer dans data/mntner. Dans cette dernière, vous pouvez voir que VINISHOR-DN42 est associé aux rôles admin-c et tech-c. Ici, c'est ce qu'on veut, mais si vous travaillez dans une équipe d'ingénieurs réseaux, ces informations peuvent désigner des personnes différentes. Enfin, la partie auth contient la clé PGP qu'on a définie plus haut : elle permet d'identifier la personne sur DN42 et de s'assurer que tout est cohérent.
On termine cette partie en sélectionnant un numéro d'AS (ou ASN) disponible parmi ceux proposés dans le dossier data/aut-num. Pour le choisir, une petite recherche vous permettra de voir qu'il y a des fois des trous entre deux numéros et que l'on peut piocher en un.
Dans mon cas, j'ai pris le numéro finissant par 2561 et je l'ai défini dans le fichier data/aut-num/AS4242422561 comme ceci:
aut-num: AS4242422561
as-name: VINISHOR-AS
descr: Vinishor home AS
remarks: Open peering policy, e-mail <network@linuxmario.net>
remarks: new peerings require a BGP session with IPv6
admin-c: VINISHOR-DN42
tech-c: VINISHOR-DN42
mnt-by: VINISHOR-MNT
La partie descr est une courte description de votre AS et doit rester courte. Si besoin de rajouter plus de détails, vous pouvez utiliser des champs remarks comme ci-dessus.
À cette étape de l'article, si on reprend mon exemple, voici ce qu'on a créé pour l'instant :
- un fichier data/person/VINISHOR-DN42 pour définir notre identité sur DN42
- un fichier data/mntner/VINISHOR-MNT pour définir le mainteneur dans le registre
- un fichier data/aut-num/AS4242422561 pour l'ASN
Préfixes
La prochaine étape est de récupérer un préfixe à annoncer.
Dans mon cas, je vais partir sur un AS qui annonce uniquement des IPv6. Il est tout à fait possible de s'allouer des IPv4, mais je vous invite à aller sur le wiki officiel pour vérifier comment faire.
Sachez cependant que les AS annoncant uniquement des IPv4 sont très rares et sont généralement assez mal vu par les autres membres. Très peu de monde voudra faire des demandes de peer avec ce type d'AS.
Pour obtenir un préfixe IPv6, la méthode est assez simple : il suffit d'utiliser un générateur aléatoire d'adresses ULA. Les ULA sont l'équivalent des adresses privées en IPv6 et elles ont le même avantage que les adresses IPv6 publiques : il y a en des tonnes. Pour rappel, l'espace total d'adressage pour IPv6 contient 340282366920938463463374607431768211456 adresses (contre 4294967296 pour tout IPv4). En terme de comparaison visuelle drôle, il est dit que chaque grain de sable de la Terre peut recevoir plusieurs adresses IPv6.
Vous pouvez utiliser celui-ci : https://unique-local-ipv6.com
Une fois votre préfixe obtenu, vous devez créer deux fichiers selon les modèles ci-dessous. Le premier, qui sera à mettre dans data/inet6num, sert à définir la taille de votre préfixe, son nom et son assignation à votre AS. Le deuxième sert à définir la route, c'est-à-dire le fait que votre préfixe vient de votre AS, et sera à mettre dans data/route6. Cela servira notamment à valider RPKI et ROA et à empêcher de vous faire hijack et qu'une autre personne annonce vos adresses IP.
Comme exemple, voici mon fichier data/inet6num/fdfa:ead5:d47f::_48 :
inet6num: fdfa:ead5:d47f:0000:0000:0000:0000:0000 - fdfa:ead5:d47f:ffff:ffff:ffff:ffff:ffff
cidr: fdfa:ead5:d47f::/48
netname: VINISHOR-V6-NET-1
country: FR
admin-c: VINISHOR-DN42
tech-c: VINISHOR-DN42
mnt-by: VINISHOR-MNT
status: ASSIGNED
source: DN42
Et mon fichier data/route6/fdfa:ead5:d47f::_48 :
route6: fdfa:ead5:d47f::/48
origin: AS4242422561
max-length: 48
mnt-by: VINISHOR-MNT
source: DN42
Sur la partie IPv6, il est courant de s'allouer des préfixes en /48, ce qui explique mon choix pour le générateur et mes fichiers. Il est possible de s'allouer un préfixe plus petit, mais cela n'est pas recommandé. Notez aussi que le nom des fichiers correspond au préfixe choisi, tout en remplaçant le symbole / par _ pour des raisons de syntaxe.
Valider nos modifications et les envoyer sur le registre
Nos fichiers sont prêts pour être envoyés sur le dépôt central. Avant de continuer, on peut installer les outils de validations fournis par DN42 pour que tout soit fait automatiqument avant de pousser le commit. Pour cela, il suffit de lancer ./install-commit-hook dans le dossier registry et les scripts seront ajoutés aux bons endroits. Ces scripts servent à contrôler les objets pour éviter de modifier quelque chose qui existe déjà et à vérifier le formatage.
Si on veut vérifier le contenu avant, on peut lancer ./check-my-stuff <pseudo-MNT> pour vérifier que tout est bien relié et valide. Le script ne devrait sortir que des PASS et vous indiquera si une erreur est présente.
On peut donc rassembler nos modifications et créer un commit : git add -Av && git commit -S. Un éditeur de textes va s'ouvrir en vous demandant de rentrer un message. On écrit une petite description du commit en anglais (Add new ressources for YOURNAME-AS par exemple), on enregistre et on ferme l'éditeur. GPG sera ensuite utilisé pour signer le commit et on peut vous demander une phrase de passe si vous en avez défini une pour protéger votre clé. Les scripts de vérifications vont ensuite passer pour tout valider et le commit sera poussé.
Un git log -p va vous afficher toutes les modifications que vous avez apporté et si votre commit est bien signé. Une fois que tout est bon, on pousse le tout : git push --set-upstream origin <nomdebranche>. Un lien devrait apparaître et vous pouvez cliquer dessus ou bien le recopier dans le navigateur.
Cela va ouvrir une page sur git.dn42.dev qui va proposer de faire une demande de fusion (ou merge request en anglais) entre dn42/registry (soit le vrai dépôt central) et notre branche. Si tout est bon, on peut cliquer sur le bouton de validation pour créer la demande. Deux vérifications vont alors passer sur les modifications et la demande sera mise en attente de validation. Il ne reste plus qu'à attendre une validation de la part d'un des membres principaux.
Une fois la validation effectuée, les fichiers sont ajoutés sur le registre et le système va commencer à prendre en compte le nouveau préfixe. Il sera alors temps de passer à la deuxième partie pour configurer le premier élément de ce nouvel AS : un routeur BGP !
Conclusion
Cet article présente surtout des concepts administratifs et n'est pas aussi technique que la suite. Cependant, cela montre un peu comment fonctionne l'enregistrement d'un AS et la nécéssité de déclarer des ressources avant de se lancer dans son projet. Avec ça, on peut déjà commencer à comprendre comment on relie des informations entre elles pour faire en sorte que tout fonctionne bien au sein d'un réseau interconnecté.
Dans le prochain article, on va attaquer dans le dur et commencer à configurer un premier routeur BGP avec OpenBSD !
Commentaire(s) publié(s)
- « Très inspirant, hâte de lire la partie 2 :) » - Quentin J