Rayfish : un VPN P2P basé sur Iroh

 (rayfish.xyz)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Rayfish est une première version qui crée un VPN maillé P2P entre les appareils des utilisateurs, sans serveur ni compte, en conservant l’état du réseau sous forme d’enregistrements signés détenus par les membres
  • En supprimant le plan de contrôle central, le réseau continue de fonctionner après l’inscription sans compte d’entreprise, opérateur ni serveur de coordination devant rester allumé en permanence
  • Iroh v1 sert de base au lancement en prenant en charge les connexions QUIC chiffrées, la traversée de NAT, le hole punching et le repli sur relais lorsqu’aucun chemin direct n’est disponible
  • Il propose actuellement l’adhésion simultanée à plusieurs réseaux isolés, l’inscription par codes d’invitation et approbation, Magic DNS, un pare-feu par appareil, le provisionnement déclaratif de flottes, les connexions 1:1 et le transfert de fichiers
  • Il peut être moins mature et moins performant que Tailscale, et ce n’est pas non plus un SDK, mais il vise les cas où l’on a besoin d’un réseau privé sans partie centrale

Le problème que Rayfish cherche à résoudre

  • Rayfish est un VPN maillé P2P qui crée un réseau privé entre des appareils
  • Il fonctionne sans serveur intermédiaire ni entreprise dont il faudrait croire qu’elle continuera à opérer le service
  • L’utilisateur reçoit une clé, les appareils s’en servent pour se trouver mutuellement, et le réseau créé appartient aux personnes qui en font partie

Une conception sans plan de contrôle central

  • Beaucoup de VPN modernes dépendent d’un plan de contrôle opéré par une entreprise
    • L’entreprise décide des membres du réseau et des politiques
    • Même pendant que les appareils communiquent, l’entreprise reste dans le flux
    • Si l’entreprise s’arrête, augmente ses prix ou met fin à la relation client, il devient difficile pour le réseau privé de rester entièrement sous le contrôle des utilisateurs
  • Rayfish supprime les comptes et l’opérateur central
    • L’état du réseau est un enregistrement signé que n’importe quel membre peut transmettre à un autre
    • Même si les créateurs de Rayfish disparaissent, les réseaux existants continuent de fonctionner

Comment gérer plusieurs réseaux sur un même appareil

  • Rayfish part du principe que les utilisateurs n’utilisent pas un seul réseau plat
  • Un même appareil peut appartenir simultanément à un réseau d’amis, un réseau de projet annexe et un réseau de travail
  • L’implémentation fonctionne derrière un seul processus et une seule interface virtuelle
  • Chaque réseau est isolé des autres, et l’utilisateur devient membre à part entière de tous les réseaux qu’il rejoint

Le lancement rendu possible par Iroh v1

  • Rayfish confie à Iroh les parties difficiles de la couche de transport
    • Connexions QUIC chiffrées entre pairs
    • Traversée de NAT
    • Hole punching
    • Repli sur relais lorsqu’aucun chemin direct n’est disponible
  • Iroh v1 a fourni la stabilité nécessaire pour que la couche de transport ne bouge pas pendant le développement, rendant cette version possible
  • Le prochain défi consiste à transformer les premiers outils en outils que l’on peut exécuter sans inquiétude en production

Un spin-off de Field Technologies

  • Rayfish est un projet issu de Field Technologies, une société de trading haute fréquence
  • Il s’appuie sur l’expérience acquise en interne dans les systèmes distribués, où il a fallu construire à plusieurs reprises la découverte d’appareils, l’accord sur un état partagé et des communications rapides et privées
  • Ces infrastructures internes ont surtout été créées pour éviter de dépendre du plan de contrôle d’autres entreprises
  • Rayfish était une idée suivie depuis plus de quatre ans, mais son absence d’opérateur central rendait difficile l’identification d’un point de facturation clair, ce qui a retardé sa transformation en produit
  • À l’avenir, il pourrait s’étendre à des problématiques d’entreprise comme la gestion de flottes ou l’audit, mais ces fonctions n’existent pas encore

Fonctionnalités actuellement disponibles

  • Structure point à point

    • Rayfish n’est pas un modèle hub-and-spoke, mais une structure point à point
    • Tous les membres se connectent directement à tous les autres membres
    • L’appartenance au réseau n’est pas une valeur demandée à un serveur, mais un enregistrement signé que chaque membre transporte avec lui
    • Le coordinateur qui a créé le réseau n’est nécessaire que pour accepter de nouveaux membres ; après l’inscription, le réseau fonctionne sans personne au centre

  • Réseaux fermés et modes d’inscription

    • Les réseaux sont fermés par défaut
    • Le coordinateur peut ajouter de nouveaux membres de deux manières
      • Code d’invitation à usage unique
      • Approbation en temps réel d’une demande d’inscription
    • Si un réseau public est nécessaire, on peut ouvrir la porte avec ray create --open, auquel cas il suffit du room id pour le rejoindre
    • Les membres inscrits sont accessibles via une IP stable et un nom Magic DNS familier
    • Le nom d’hôte par défaut peut être défini avec ray up --hostname dario, et --hostname peut être remplacé réseau par réseau
    ray up --hostname dario
ray create --name prod
ray invite prod --hostname web
ray join <code>

  • Pare-feu par appareil

    • Chaque appareil possède son propre pare-feu et décide lui-même quoi accepter et de qui
    • Le coordinateur peut publier des règles de pare-feu recommandées pour chaque réseau
    • Chaque hôte peut accepter les règles ou choisir l’installation automatique
    • Il s’agit de fournir des valeurs par défaut partagées, sans serveur central de politiques que tout le monde serait obligé de suivre

  • Provisionnement de flottes

    • Pour plusieurs appareils, un fichier déclaratif permet de définir et d’appliquer les réseaux et les règles de pare-feu
    • La spécification est une map networks:, avec sous chaque réseau les pairs et ports autorisés par hôte
    networks:
  prod:
    web:
      allows:
        "*": "tcp:443"
    db:
      allows:
        web: "tcp:5432"
  game:
    "*":
      allows:
        "*": "tcp:6969"

    ray apply deploy.yaml --dry-run
ray apply deploy.yaml --invite-missing
    • Pour une flotte, il est possible de créer des clés réutilisables sans émettre un code pour chaque machine
    ray invite prod --reusable
ray join <key> --hostname web01 --auto-accept-firewall
    • Révoquer une clé bloque seulement les nouvelles inscriptions et ne perturbe pas les serveurs déjà inscrits
    • ray apply fonctionne de manière idempotente, de sorte que le fichier de spécification reste l’état de référence de la flotte

  • Connexions 1:1 et transfert de fichiers

    • Lorsqu’il n’est pas nécessaire de créer un réseau séparé, ray connect permet d’établir une connexion 1:1 basée sur un ID de contact
    ray contact id
ray connect <their-contact-id>
ray connections approve <id>
    • Une fois approuvée, un réseau privé à deux pairs est créé automatiquement
    • Magic DNS, le pare-feu et les fonctions de maillage fonctionnent de la même manière, et ray status affiche [direct]
    • Les ID de contact peuvent être renouvelés, et les connexions déjà créées continuent de fonctionner
    • Comme il existe déjà un chemin authentifié et chiffré entre les membres, il est possible d’envoyer des fichiers sans service séparé
    ray send ./build.tar.gz web01
ray files accept 1

Différences avec Tailscale

  • Tailscale et Rayfish fournissent tous deux des IP stables, Magic DNS, la traversée de NAT et un plan de données P2P
  • La principale différence est l’emplacement du contrôle
    • Tailscale utilise un plan de contrôle comme les serveurs de coordination de Tailscale ou Headscale en self-hosted
    • Rayfish n’a pas de plan de contrôle central : l’état du réseau est un enregistrement signé transmis en P2P
  • Le plan de données est également différent
    • Tailscale utilise WireGuard, qui fonctionne dans le noyau
    • Rayfish utilise des datagrammes Iroh/QUIC en espace utilisateur
  • En général, Tailscale a l’avantage en vitesse
    • Comme WireGuard fonctionne dans le noyau, l’écart peut être net pour les transferts volumineux sur des liens rapides
    • Rayfish échange une partie du débit brut contre une architecture sans partie centrale
  • Rayfish utilise une paire de clés sur disque comme identité, et non un compte ou du SSO
  • Rayfish est jeune et centré sur un minimum de fonctionnalités, tandis que Tailscale est mature et beaucoup plus riche fonctionnellement

Différences avec Yggdrasil

  • Yggdrasil fournit un réseau IPv6 chiffré de bout en bout, sans autorité centrale
  • La différence se situe dans la dernière étape que l’utilisateur doit gérer directement
    • Yggdrasil fournit un réseau mondial unique et des adresses IPv6
    • Rayfish fournit des réseaux privés séparés que l’utilisateur crée et auxquels il ajoute des membres
  • Rayfish inclut des commodités comme les codes d’invitation, des noms DNS lisibles, un pare-feu par réseau et des invites d’approbation d’inscription
  • Yggdrasil convient aux ingénieurs qui ont des connaissances réseau, tandis que Rayfish vise aussi les utilisateurs qui veulent créer facilement un petit réseau privé à plusieurs

Ce que l’on peut construire, et ce que l’on ne peut pas construire

  • Rayfish n’est pas une bibliothèque, mais un outil complet
  • Il ne peut pas être embarqué comme un SDK dans une application
  • Il convient aux cas où des appareils sur lesquels Rayfish est installé doivent communiquer en privé
    • Serveur de jeu P2P auquel des amis se connectent par nom
    • API interne non exposée à l’Internet public
    • Cible de sauvegarde
    • Application de chat ou d’appel entre membres du réseau
    • Base de données partagée par deux équipes qui ne doivent pas se voir mutuellement
  • Les applications peuvent accéder aux pairs via name.network.ray
  • Les personnes extérieures qui n’ont pas installé Rayfish ne peuvent pas accéder au réseau, et il n’existe pas de passerelle pour les externes

Exemples de configurations réelles

  • Deux services qui partagent une base de données

    • En plaçant payments et analytics dans des réseaux séparés, les deux services ne peuvent pas se voir mutuellement
    • Seule la machine de base de données rejoint les deux réseaux
    • Un pare-feu recommandé est configuré pour n’ouvrir que les ports nécessaires dans chaque réseau
    networks:
  payments:
    db:
      allows:
        "*": "tcp:8123,tcp:9000"
  analytics:
    db:
      allows:
        "*": "tcp:8123,tcp:9000"
    • Chaque équipe y accède via db.payments.ray ou db.analytics.ray
    • Les deux réseaux ignorent leur existence respective, et le contrôle d’accès est assuré par la séparation des réseaux et l’hôte partagé, sans audit ACL central

  • Serveur Minecraft entre amis

    • En créant un réseau fermé et en invitant des amis, ils peuvent se connecter par nom, sans adresse IP, redirection de port ni DNS dynamique
    ray create --name mc
ray invite mc
    • Les clients se connectent à mc-host.mc.ray:25565

  • Groupe fermé où tout le monde ouvre un port

    • Si tous les membres doivent ouvrir TCP 6969, l’administrateur peut proposer la règle une fois
    ray firewall suggest mc --subject '*' --allow '*:tcp:6969'
    • Chaque membre examine la règle proposée et l’accepte ou la refuse
    ray firewall pending mc
ray firewall accept mc
    • Les suggestions de pare-feu ne sont pas des règles imposées ; un membre peut les refuser s’il ne les veut pas

Sécurité et gestion des adresses

  • Les adresses IP ne sont pas attribuées par un serveur, mais dérivées de l’identité cryptographique de chaque pair
  • Les collisions d’adresses sont très rares, mais si elles se produisent, le coordinateur place le second pair dans le prochain emplacement libre
  • Tous les pairs convergent de manière déterministe vers la même attribution d’adresses, sans allocateur central
  • Rayfish construit la sécurité autour de deux éléments plutôt que d’ACL centralisées
    • Une segmentation où seuls les pairs partageant le même réseau peuvent communiquer
    • Le pare-feu propre à chaque appareil, par réseau
  • Pour isoler prod et dev, il suffit d’en faire deux réseaux
  • Les hôtes appartenant à plusieurs réseaux conservent leur propre pare-feu dans chaque réseau

Faut-il un serveur ou ouvrir des ports ?

  • Il n’est pas nécessaire d’héberger un serveur de contrôle séparé
  • Le coordinateur qui a créé le réseau peut être hors ligne une fois que tous les membres l’ont rejoint
  • Iroh gère la traversée de NAT et le hole punching, et utilise un repli sur relais chiffré lorsqu’un chemin direct est impossible
  • Si vous contrôlez le routeur et voulez un chemin direct garanti vers une machine précise, vous pouvez rediriger le port UDP fixe de Rayfish, mais c’est facultatif

Feuille de route et cas où ce n’est pas adapté

  • Actuellement, Rayfish est fourni comme outil en ligne de commande pour les postes de travail et les serveurs
  • La prochaine étape consiste à l’étendre aux appareils que les utilisateurs transportent réellement avec eux
    • Client Android
    • Client iOS
    • Véritable application desktop
  • En parallèle, le travail consiste à renforcer les fonctionnalités existantes pour qu’elles puissent être utilisées sans crainte en production
  • Si Tailscale, le VPN d’entreprise ou un maillage WireGuard configuré à la main fonctionnent déjà bien, il y a peu de raisons de passer à Rayfish
  • Rayfish est plus jeune, avec moins de fonctionnalités, et les outils existants offrent de nombreuses fonctions de manière plus fluide
  • Ce que Rayfish élimine tient en une chose
    • Les comptes
    • L’entreprise capable d’arrêter le réseau
    • Le serveur de contrôle devant rester allumé en permanence
    • La base de données de politiques opérée par quelqu’un d’autre

Démarrage

  • L’installation commence par une commande d’une ligne
curl -fsSL https://rayfish.xyz/install.sh | sh
  • La création du premier réseau et la procédure d’invitation sont expliquées ensuite dans la documentation

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis sur Lobste.rs

  • J’aime beaucoup le fait que Rayfish parte dès le départ du principe qu’on peut gérer plusieurs réseaux en même temps
    Dans Tailscale, ça ne semble pas être une priorité, donc cela pourrait être un vrai avantage
    Le passage disant que le projet est issu d’une scission d’une société de trading haute fréquence était inattendu, et affirmer que Tailscale gagne en vitesse parce que « le plan de données WireGuard tourne dans le noyau » est faux. Tailscale n’utilise pas WireGuard dans le noyau, mais les gens continuent à faire cette confusion
    Il dit « les idées, le produit et les phrases sont les miens », mais c’est dommage qu’il y ait un CLAUDE.md dans le dépôt. Cela dit, à en juger par le résumé des contributions, clod représente 1 017++ / 383-- lignes, tandis que l’auteur est à 104 786++ / 47 064-- lignes ; la majeure partie du code ne semble donc pas avoir été bricolée à la va-vite par une IA. Je ne sais quand même pas s’il fallait laisser ce genre de trace dans le dépôt pour 1/100 de la charge de travail

    • Même s’il y a eu une assistance par IA, ça ne me dérange pas vraiment. Ce qui compte, c’est l’utilisabilité réelle, et si c’est une vraie alternative décentralisée à Tailscale, ce serait énorme
      Jusqu’ici, j’ai surtout vu Iroh utilisé de manière mignonne mais pas très utile ; c’est peut-être justement l’application qu’il lui fallait
    • Comme c’est basé sur Iroh, il y a QUIC, et donc on pourra peut-être enfin utiliser de la cryptographie post-quantique dans un VPN maillé
      Là encore, dans Tailscale, ça ne semble pas être une priorité

  • Le produit lui-même a vraiment l’air génial, et la seule chose qui m’empêche de remplacer mon mesh Tailscale, c’est l’absence de client Android
    En revanche, l’article m’a un peu agacé parce qu’au moins une partie se lit comme si elle avait été rédigée par IA

  • La comparaison avec Yggdrasil est faible et contient des erreurs factuelles. Le testnet Yggdrasil fonctionne bien comme un réseau mondial, mais ce n’est qu’une conséquence pratique de la topologie de Yggdrasil
    Il peut accepter dynamiquement n’importe quelle connexion entre deux ensembles de clés séparés, et la seule différence entre deux réseaux Yggdrasil séparés et un grand réseau unique est de savoir s’ils échangent des messages entre eux. N’importe qui peut créer un réseau Yggdrasil privé
    Les clés sont cryptographiquement impossibles à deviner, mais je ne pense pas que cela implique pour autant des services cachés. Les noms de domaine sont arbitraires, mais beaucoup de gens pointent aussi le DNS mondial vers l’espace d’adressage Yggdrasil
    Si le point de vue est « si je veux seulement un réseau avec trois amis pour un serveur de jeu, Yggdrasil demande beaucoup d’assemblage », il est même surprenant qu’il n’y ait pas de comparaison avec tinc, qui est quasiment le standard pour trois amis et un serveur de jeu

    • L’ID public lui-même peut être impossible à deviner, mais il peut aussi apparaître dans des journaux partagés ou des rapports de bug. C’est donc ce problème qu’un réseau privé avec invite d’approbation vient résoudre
      L’explication porte sur le fait qu’il n’y a pas de notion de création d’un réseau privé distinct avec admission de personnes, ni de fonctionnalités pratiques comme des codes d’invitation, des noms DNS familiers, des pare-feu par réseau ou une invite d’approbation quand quelqu’un essaie d’entrer. Pour un ingénieur réseau, ce n’est peut-être pas un problème
      Un autre point manquant dans la comparaison avec Yggdrasil est que Rayfish exploite le NAT hole punching d’Iroh, ce qui permet à deux pairs de communiquer même si aucun des deux n’est accessible publiquement