A la baaaase, le développeur derrière Nylon voulait juste streamer tranquillou ses jeux depuis son PC de sa chambre d'étudiant. Sauf que les VPN privés comme Tailscale ou Nebula reposent sur de la traversée de NAT, et que sur le réseau très fermé de sa fac, bah ça coinçait. Alors il a codé
Nylon
, un réseau WireGuard où chaque machine peut relayer le trafic des autres, sans aucun serveur au milieu pour se coordonner.
Pour y arriver, Nylon fait tourner un protocole de routage nommé Babel (
RFC 8966
) par-dessus une version modifiée de wireguard-go, et il mesure la latence de chaque lien pour choisir le meilleur chemin. Du coup, vos machines n'ont pas besoin de se voir directement. Par exemple, si votre ordi portable n'arrive pas à joindre le serveur VPN, hé bien le trafic passera par un autre nœud, voire plusieurs. Et quand un lien tombe, l'outil met moins de 10 secondes pour trouver une autre route sur le réseau.
La démo du README : on coupe le lien direct entre alice et charlie, le ping repart par bob, puis le lien direct revient
Côté config, tout repose sur un binaire, le port UDP 57175 ouvert et 2 fichiers YAML que vous pouvez triturer. Le node.yaml contient notamment la clé privée de la machine, et le central.yaml liste tous les nœuds avec leurs adresses + un graphe qui dit qui doit essayer de se connecter à qui. Ce fichier central, vous le recopiez alors à la main sur chaque machine, ou vous l'empaquetez avec nylon seal dans un bundle signé et chiffré, à mettre sur un serveur web pour que les nœuds puissent le relire (en moyenne, ils passent dessus toutes les dix secondes).
Et pour les téléphones, y'a pas d'app maison à installer car les clients WireGuard standard d'iOS et d'Android se branchent sur une passerelle, c'est-à-dire un nœud Nylon normal qui annonce leur présence au reste du réseau. Ces clients passifs ne relaient rien bien sûr, mais avec plusieurs profils VPN qui partagent la même clé privée, ils passent automatiquement d'une passerelle à l'autre OKLM.
Après je vous sens hyper chaud mais il faut remplir 2 conditions avant de tout migrer. En effet, pour passer le NAT, Nylon exige une redirection de port ou un nœud relais public, donc dès que deux machines sont sur des réseaux différents, au moins un nœud doit être joignable depuis Internet. Par exemple, 2 machines derrière deux box différentes, sans aucun port ouvert ailleurs, se retrouvent sur deux "îlots" séparés... La parade, c'est donc de rediriger le port 57175 en UDP sur votre box ou de poser un petit VPS au milieu qui servira de relais à tout le monde.
L'autre condition, c'est la confiance bien sûr.
Le chiffrement se fait saut par saut puisque chaque nœud déchiffre puis rechiffre les paquets qu'il relaie, et l'auteur reconnaît dans
son article technique
que Nylon fait pour l'instant confiance à tous ses pairs de la même manière. Un nœud compromis pourrait donc annoncer de fausses routes pour attirer le trafic. Alors n'y mettez que des machines à vous, et gardez du TLS par-dessus pour ce qui est sensible !
Après si votre souci, c'est uniquement le NAT, sachez que Tailscale sait maintenant relayer le trafic par une de vos propres machines quand la connexion directe ne passe pas. En effet, ses
Peer Relays
sont en version stable depuis février 2026, et dispo dès dans l'offre gratuite, donc pas de quoi se prendre le chou. Et côté libre, il y a aussi
EasyTier
qui perce le NAT sans souci, y compris entre deux NAT4, et choisit lui aussi ses routes en fonction de la latence.
Pour mettre Nylon en place sous Linux, un script permet d'installer le binaire et son service systemd, puis la commande nylon key génèrera les clés de chaque machine. Enfin, nylon verify contrôlera vos fichiers avant le premier lancement :
Voilà, c'est open source (licence Apache 2.0), dispo sous macOS / Linux et pour Windows, sachez que le client de ce dernier a des problèmes connus, donc il vaut mieux pour le moment connecter les PC Windows en client simple WireGuard derrière une passerelle Linux ou Mac.
En tout cas, si vous avez déjà un VPS qui traîne et quelques machines à relier, ça vaut le coup de lui laisser sa chance !
En février,
je vous ai présenté Reticulum
, une pile réseau chiffrée de Mark Qvist qui n'a besoin ni de TCP/IP ni d'Internet. Et cette fois, on va aller un peu plus loin en passant à la pratique avec NomadNet, un programme du même auteur qui permet de servir des pages et des fichiers par-dessus Reticulum.
À la fin de ce tuto, vous aurez alors une page d'accueil et quelques fichiers à télécharger, diffusés par votre propre nœud.
NomadNet est tout simplement un paquet Python qui va chercher Reticulum pour l'installer. Il suffit d'invoquer pip comme ceci :
pip install nomadnet
Sur les Debian et Ubuntu récentes, qui bloquent pip, vous pouvez utiliser pipx à la place comme ceci :
pipx install nomadnet
pipx install rns
Et voilà, vous devriez normalement vous retrouver avec NomadNet 1.5.0 et rns 1.6.0.
NomadNet 1.5.0 installé par pipx
Le paquet rns apporte rnstatus et les autres utilitaires de Reticulum 1.6.0
Le second paquet n'est pas obligatoire certes, mais il apporte des utilitaires de Reticulum plutôt cools et pratiques comme rnstatus, qui affiche l'état de vos interfaces.
Lancez ensuite nomadnet une première fois. Le programme s'ouvrira alors sur son guide, dans le terminal, et créera au passage 2 fichiers de configuration : ~/.reticulum/config pour la pile réseau et ~/.nomadnetwork/config pour NomadNet.
Le premier lancement, sur le guide
Ce guide recommande un terminal d'au moins 135 colonnes sur 32 lignes, donc agrandissez un peu la fenêtre si vous voyez que c'est moche et si vous voyez des petits carrés à la place des lettres de l'alphabet, c'est que vous devez installer les
Nerd Fonts
. Ou vous en passer en changer dans la section [textui] dans le fichier ~/.nomadnetwork/config, le paramètre glyphs = nerdfont par :
glyphs = unicode
Relancez ensuite NomadNet pour que le changement prenne effet.
Côté réseau, la config par défaut n'active qu'une seule interface : l'AutoInterface. Elle permet de découvrir les autres nœuds Reticulum par IPv6 en lien local et transporte les paquets en UDP, sans routeur ni DHCP. Mais elle ne parle qu'aux pairs Reticulum de votre réseau local. Donc si un pare-feu tourne sur la machine et bloque ce trafic, faudra lui ouvrir les ports UDP 29716 et 42671, sinon personne ne vous trouvera et ça c'est triste... snif.
Entre mes deux machines virtuelles, ça a marché sans toucher à rien, puisque le pare-feu ufw est désactivé par défaut dans Ubuntu.
Activer le nœud
Par défaut, NomadNet est un simple client de messagerie. Pour qu'il serve des pages web, ouvrez ~/.nomadnetwork/config, cherchez la section [node] et passez enable_node à yes.
Le node_name est le nom que votre nœud diffuse à tout le réseau donc je compte sur vous pour choisir un truc cool. Quant à disable_propagation, il sert à faire un nœud qui ne sert que des pages, sans stocker ni relayer les messages chiffrés des autres utilisateurs. En version 1.5.0 c'est déjà le réglage par défaut, donc pas de stress. Relancez ensuite NomadNet, ou faites-le tourner sans interface avec la commande : nomadnet --daemon.
La section [node] de la config, nœud activé
Chez moi, une fois le nœud activé, un onglet My Node est alors apparu dans l'interface, avec l'explorateur des pages et des fichiers, ainsi qu'un éditeur de langage micron (j'y viens après) et un aperçu en direct, soit de quoi se passer de nano.
Sans Nerd Font, des carrés remplacent les icônes de l'onglet My Node
La page provisoire d'un nœud encore vide et la fenêtre de saisie d'adresse, dans une version antérieure de NomadNet
Écrire la page et poser les fichiers
Tant que vous n'avez rien déposé, le nœud sert une page d'accueil générée automatiquement. Comme je vous le disais, les pages s'écrivent en micron, un petit langage de balisage de NomadNet, et vont dans ~/.nomadnetwork/storage/pages. Créez donc d'abord un fichier index.mu, puisque c'est la page servie par défaut à quiconque se connectera à votre noeud.
Les fichiers à partager vont ensuite dans le dossier ~/.nomadnetwork/storage/files, et pour qu'un visiteur puisse en télécharger un, il faudra un lien vers ce même fichier dans une de vos pages.
Voici une page minimale, assemblée à partir des exemples du guide :
>Bienvenue sur mon nœud
Quelques fichiers à récupérer :
`[Le PDF du jour`:/file/document.pdf]
La page index.mu et le PDF posés dans le stockage du nœud
À l'essai, ce lien fonctionne, mais il s'affiche chez le visiteur du texte ordinaire tout moche, alors pour qu'il ressorte un peu mieux, je vous invite à l'entourer d'une couleur et d'un petit soulignement avec ces codes : F79d` et _ pour ouvrir, ``_ et ``f` pour refermer :
`F79d`_`[Le PDF du jour`:/file/document.pdf]`_`f
Notre page vue depuis la seconde machine : le lien ne se distingue pas du texte ordinaire
Avec ses balises de couleur, le lien sort en bleu souligné
L'éditeur micron de l'onglet My Node et son aperçu en direct
L'adresse :/file/document.pdf pointe donc vers un fichier local, posé dans storage/files mais attention par contre, NomadNet ne dressera la liste de ces deux dossiers qu'au démarrage, puisque page_refresh_interval et file_refresh_interval sont à 0 par défaut. Donc après chaque ajout, soit vous redémarrez votre noeud, soit vous donnez à ces deux réglages un intervalle en minutes pour que ça s'auto-refresh tous les X.
Ainsi, une page déjà existante que l'on modifie s'affichera aussitôt chez le visiteur dans sa nouvelle version pour peu qu'il refresh, par contre, une page ajoutée par la suite sera en "Request failed" tant que le nœud n'a pas redémarré.
L'adresse complète d'une page se compose donc d'un hash de destination du nœud, qui fait 32 caractères hexadécimaux, suivi de :/page/index.mu. Dans l'onglet Network de NomadNet, Ctrl+U ouvre la boîte de saisie d'URL, et le programme se charge de trouver le nœud et de s'y connecter. Depuis une autre machine du même réseau local, c'est là aussi que votre page devrait s'afficher.
Notre nœud "Mon site" dans le flux d'annonces du voisin
Maintenant le plus simple pour la trouver, c'est encore de passer par le flux d'annonces de l'onglet Network, où votre nœud apparaît sous son nom, puis de cliquer dessus et de choisir Connect. Et si vous passez par Ctrl+U, chez moi la boîte de dialogue est arrivée préremplie avec l'adresse de la page en cours, qu'il a donc fallu effacer avant de taper la mienne, avec l'adresse du nœud lue sur sa fiche, à la ligne Addr.
La boîte de saisie d'URL avec l'adresse complète de la page
Reste le téléchargement, et là, sur mon Ubuntu en français, ça a coincé car NomadNet enregistre par défaut dans ~/Downloads, un dossier qui n'existe pas chez moi puisqu'il s'appelle Téléchargements. Et donc chez moi le transfert est resté figé sur "Receiving response 100%", sans un message à l'écran. L'erreur n'apparaissait que dans ~/.nomadnetwork/logfile. Donc si ce dossier n'existe pas chez vous non plus, corrigez ça sur la machine du visiteur, à la ligne downloads_path de la section [client] de ~/.nomadnetwork/config :
downloads_path = ~/Téléchargements
Le dossier de téléchargement corrigé dans la config de NomadNet
Chez moi, après un redémarrage de NomadNet, le PDF est arrivé ensuite en une fraction de seconde, avec une empreinte SHA-256 identique à celle de l'original.
Le PDF enregistré, 13,12 Ko, identique à l'original
Le forum rns.recipes ouvert dans le navigateur intégré de NomadNet, son adresse de page en haut
Sortir du réseau local
Maintenant pour être joignable depuis l'extérieur, il faut en général ajouter une interface dans ~/.reticulum/config, sous [interfaces], à moins qu'un autre système de votre réseau local, configuré en passerelle, ne le fasse déjà pour vous. Pour passer par Internet, la forme que donne la doc est celle-ci, où target_host et target_port sont ceux d'un point d'entrée que vous aurez choisi :
Le projet ne fournit plus d'adresse toute faite, puisque son testnet public a été fermé donc la doc renvoie vers deux annuaires communautaires, directory.rns.recipes et rmap.world, et conseille de mettre en place plusieurs connexions plutôt qu'une seule. Sachez aussi que si Reticulum chiffre ses échanges par défaut, TCP lui ne chiffre rien. Cela veut dire que l'adresse IP des deux bouts est visible pour qui inspecte la connexion, et il peut aussi en déduire que vous faites tourner Reticulum. Donc si vous voulez masquer réellement ces adresses, faudra mettre en place une interface I2P au prix d'un démon i2pd à faire tourner à côté (une fois encore tout est dans la doc).
Dans l'annuaire directory.rns.recipes on a 71 points d'entrée TCP, dont 40 sont actuellement en ligne, chacun avec pour chacun son bloc de configuration prêt à copier. J'ai ajouté RMAP et SWISS RNS sur la machine du visiteur, relancé NomadNet, et une minute plus tard, une dizaine de nœuds figuraient déjà dans la liste, le mien compris :
Dix nœuds listés une minute après l'ajout des deux points d'entrée, le mien compris, les noms des autres étant floutés
rnstatus avec l'AutoInterface et les deux interfaces TCP actives
Je n'ai fait ce test que dans ce sens, le visiteur voit des nœuds d'Internet, mais je n'ai pas vérifié qu'un inconnu pouvait atteindre notre nœud, puisque seule la machine du visiteur avait ces deux interfaces.
Ce que votre nœud montre
Une fois en ligne, le nœud s'annonce au démarrage puis toutes les 360 minutes, et cette annonce diffuse son nom en clair. Et d'après le code de NomadNet (Node.py), le nœud réutilise l'identité principale du programme, celle qui sert aussi à votre messagerie, donc n'importe qui peut relier votre site à votre adresse de messagerie.
Et ça se voit, puisque chez le visiteur, la fiche de votre nœud affiche une ligne Oprtr qui n'est autre que votre adresse de messagerie
LXMF
, en clair.
La fiche du nœud chez le visiteur, avec l'adresse de messagerie de l'opérateur en face d'Oprtr
Les pages et fichiers que vous déposez sont publics, sauf si vous posez à côté un fichier du même nom suivi de .allowed, qui liste les identités autorisées. Et surtout, hors Windows, un fichier exécutable placé dans pages est lancé comme un programme quand un visiteur autorisé le demande, puisque c'est comme ça que NomadNet génère ses pages dynamiques. Donc vérifiez les droits de ce que vous y copiez.
Reste la question de la maturité car pour le moment Reticulum n'a fait l'objet d'aucun audit de sécurité externe, NomadNet est en bêta, y'a eu quelques failles de sécu corrigées depuis et les dépôts GitHub ne sont plus que des miroirs figés.
Ajoutez à ça la licence maison, la Reticulum License, qui interdit tout usage dans un système conçu pour nuire aux humains et toute utilisation dans la création d'une IA ou de ses données d'entraînement. Bref,
les défenseurs d'Omarchy repasseront
, loool. Voilà, donc pour un petit site entre voisins ou entre amis, c'est jouable mais pour quelque chose de sensible, je vous conseille d'attendre un audit et surtout de bien lire la doc.
Connexion
