Et si la partie la plus sensible d’un VPN mesh ne se jouait pas dans le tunnel lui-même, mais dans tout ce qu’il faut autour pour permettre aux machines de se trouver, de se reconnaître et de s’organiser entre elles ? C’est le pari, encore très jeune, de nostr-vpn, un projet open source qui combine WireGuard pour le chiffrement et Nostr pour la signalisation.
Quand on parle de VPN, on parle presque toujours du chiffrement. C’est la partie la plus visible, celle que les services grand public mettent en avant, et celle que l’on cerne le plus facilement. Mais dès qu’il s’agit de faire communiquer plusieurs machines entre elles, dans une logique « mesh » donc, ça n’est plus suffisant. Car avant même de chiffrer quoi que ce soit, il faut savoir quels appareils appartiennent au réseau, comment les joindre, comment leurs informations circulent, et comment l’ensemble tient debout lorsqu’une IP change, qu’un appareil passe d’un réseau à un autre ou qu’un routeur décide de pimenter les choses.
Chez Tailscale, Netbird ou ZeroTier, cette organisation repose sur un service central chargé de tenir à jour la liste des nœuds, leurs paramètres de connexion et les changements d’état du réseau. Le modèle a des vertus très concrètes. Il simplifie le déploiement, facilite l’administration et évite de passer son week-end à lire des logs abscons. Mais il concentre aussi, au même endroit, une bonne partie de l’intelligence du réseau.
C’est ce choix que remet en question nostr-vpn. Développé en Rust et présenté comme une alternative aux solutions de type Tailscale, le projet s’appuie sur WireGuard pour sécuriser les échanges, tout en utilisant Nostr comme couche de signalisation. Il ne s’agit pas de réinventer le chiffrement, ni de prétendre que WireGuard faisait mal son travail, mais de repenser la manière dont les machines se découvrent, s’annoncent et se coordonnent, sans dépendre d’un serveur de contrôle unique exploité par un seul acteur.
Nostr, une autre manière de faire circuler l’information
Il faut bien s’arrêter un instant sur Nostr, puisque c’est lui qui donne au projet sa tournure la plus inattendue. Derrière ce nom qui fleure bon ce coin du web où se croisent les plus nerds d’entre nous, on trouve un protocole de communication décentralisé. Son rôle n’est pas d’héberger une plateforme, encore moins de centraliser des comptes ou du contenu, mais de définir une manière d’envoyer, de signer, de récupérer et de faire circuler des messages entre plusieurs clients.
Dans les faits, ces échanges transitent par des serveurs indépendants appelés relais, chargés de les diffuser et, au besoin, de les conserver pour d’autres clients. Une application peut s’appuyer sur un ou plusieurs de ces relais pour publier ou récupérer des données. Il n’y a ni point d’entrée unique, ni tour de contrôle chargée d’orchestrer l’ensemble, ni service unique qui déciderait seul de ce qui doit rester visible ou disponible. Chaque client compose donc sa propre combinaison de relais, au lieu de s’en remettre à une infrastructure imposée.
L’identité, ici, ne repose pas sur un compte hébergé par une plateforme. Elle s’appuie sur une paire de clés cryptographiques. La clé privée sert à signer les messages, la clé publique à en vérifier l’origine.
Ce modèle a permis l’émergence d’applications comme Damus ou Amethyst, des clients Nostr qui reprennent une partie des usages d’un réseau social classique sans faire dépendre l’identité de l’utilisateur ou de l’utilisatrice d’un service central. Une logique qui parlera aussi aux milieux proches de l’écosystème crypto. La clé fait foi, l’intermédiaire recule, et la base centrale n’est plus censée tout savoir de tout le monde.
Or, vous le voyez venir, un protocole capable de faire circuler des informations structurées entre plusieurs machines, sans point de coordination unique, peut servir à bien autre chose qu’à publier des messages. Il peut, par exemple, transporter les informations dont un réseau mesh a besoin pour exister, s’adapter aux changements du réseau et, ce faisant, rester synchronisé.
Nostr-vpn, un VPN mesh plus distribué dans son organisation
C’est exactement le type de capacité sur lequel misent les développeurs de nostr-vpn. Le projet ne réinvente ni le VPN mesh ni le chiffrement, déjà confié à WireGuard, mais il cherche à mieux distribuer l’organisation du réseau. Plutôt que de s’appuyer sur une infrastructure de contrôle dédiée pour maintenir l’état du mesh et diffuser les informations dont les machines ont besoin pour se trouver, s’annoncer et rester joignables, comme le font Tailscale, Netbird ou ZeroTier, nostr-vpn utilise Nostr pour faire circuler directement ces données de signalisation entre les machines elles-mêmes.
Alors, il ne s’agit évidemment pas de supprimer toute infrastructure intermédiaire, ni de promettre une confidentialité absolue, mais d’éviter qu’un acteur unique concentre à lui seul toute la vue d’ensemble sur l’état du réseau. Le recours à Nostr pour la signalisation ne fait pas disparaître les traces de connexion, de même qu’un relais Nostr peut toujours voir qu’un client s’y connecte, à quel moment et depuis quelle adresse IP apparente, sauf protection supplémentaire en amont. Et si une machine du réseau sert de porte de sortie vers Internet pour les autres, il faut aussi lui faire confiance, cette fois pour le trafic qu’elle relaie.
VPN classique, VPN mesh, quelle différence ?
Dans un VPN classique, un appareil se connecte à un serveur tiers qui se charge de faire transiter le trafic. C’est le modèle des services grand public, utilisés pour masquer une adresse IP, sécuriser une connexion sur un Wi-Fi public ou contourner certaines restrictions géographiques.
Dans un VPN mesh, les machines cherchent au contraire à communiquer directement entre elles. Il ne s’agit plus de faire passer tout le trafic par un fournisseur, mais d’organiser un réseau privé entre plusieurs appareils, serveurs ou sites. Il faut alors un système capable de faire exister le réseau lui-même. Les appareils doivent pouvoir s’identifier, signaler leur présence et indiquer comment les joindre, tout en s’adaptant à des conditions qui évoluent en permanence (adresses qui changent, passage d’un réseau à un autre, contraintes liées aux routeurs ou aux pare-feu). Une fois ces informations échangées, les connexions peuvent être établies puis sécurisées par chiffrement.
Un projet prometteur, pour un public déjà averti
Reste alors la partie la moins glamour de l’histoire, mais sans doute la plus décisive. À qui ce type d’outil peut-il vraiment servir, dans quel contexte, avec quel niveau d’autonomie, et pour quels bénéfices concrets ?
Nostr-vpn dispose déjà d’une base assez fournie, avec une interface graphique, des builds pour plusieurs plateformes, des outils de diagnostic, des services en arrière-plan, des bundles de support et des tests d’intégration, ce qui montre qu’il a déjà dépassé le stade du prototype improvisé. Cela ne suffit pas pour autant à en faire une solution que l’on recommanderait les yeux fermés. Le projet est jeune et, pour l’heure, n’offre pas encore le même niveau de garanties documentées qu’une solution déjà largement éprouvée. Il n’a pas non plus encore tout à fait le profil d’un outil qu’on peut déployer en trois clics, sans passer son temps à vérifier ce qu’il fait, comment il le fait, et à quel moment il risque de demander un coup de tournevis.
En l’état, nostr-vpn parlera donc moins aux personnes qui cherchent un VPN mesh prêt à l’emploi qu’à celles et ceux qui administrent déjà leurs propres machines, hébergent eux-mêmes une partie de leurs services, bricolent leur réseau, expérimentent autour de Nostr ou veulent tester une approche moins centralisée que celle de Tailscale, Netbird ou ZeroTier. Pour relier quelques appareils personnels, accéder à un homelab, mailler plusieurs serveurs ou explorer d’autres manières d’organiser un réseau privé, il y a déjà matière à s’amuser. En revanche, pour un déploiement plus large, facile à prendre en main et réellement stabilisé, il est encore trop tôt.
