Rayfish: P2P-VPN auf Basis von Iroh

 (rayfish.xyz)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Rayfish ist die erste Version, die ohne Server oder Accounts ein P2P-Mesh-VPN zwischen Nutzergeräten erstellt und den Netzwerkzustand als signierte, von den Mitgliedern gespeicherte Historie verwaltet
  • Durch den Verzicht auf eine zentrale Control Plane funktioniert das Netzwerk nach dem Beitritt weiter, ohne Firmenaccount, Betreiber oder dauerhaft laufenden Koordinationsserver
  • Iroh v1 übernimmt verschlüsselte QUIC-Verbindungen, NAT-Traversal, Hole Punching und Relay-Fallback, wenn kein direkter Pfad verfügbar ist, und bildet damit die Grundlage des Releases
  • Derzeit bietet Rayfish gleichzeitige Mitgliedschaft in mehreren isolierten Netzwerken, Beitritt per Einladungscode oder Freigabe, Magic DNS, Firewalls pro Gerät, deklaratives Fleet-Provisioning, 1:1-Verbindungen und Dateiübertragung
  • Gegenüber Tailscale kann Rayfish bei Reifegrad und Durchsatz im Nachteil sein und ist auch kein SDK, fokussiert sich aber auf Fälle, in denen private Netzwerke ohne zentrale Partei benötigt werden

Das Problem, das Rayfish lösen will

  • Rayfish ist ein P2P-Mesh-VPN, das private Netzwerke zwischen Geräten erstellt
  • Es funktioniert ohne Zwischenserver oder ein Unternehmen, dessen dauerhaften Betrieb man vertrauen muss
  • Nutzer erhalten Schlüssel, Geräte finden einander über diese Schlüssel, und das entstandene Netzwerk gehört den Menschen darin

Design ohne zentrale Control Plane

  • Viele moderne VPNs hängen von einer von einem Unternehmen betriebenen Control Plane ab
    • Das Unternehmen entscheidet über Netzwerkmitglieder und Policies
    • Auch während Geräte kommunizieren, bleibt das Unternehmen im Ablauf eingebunden
    • Wenn das Unternehmen ausfällt, die Preise erhöht oder die Kundenbeziehung beendet, bleibt das private Netzwerk schwer vollständig im Besitz der Nutzer
  • Rayfish entfernt Accounts und zentrale Betreiber
    • Der Netzwerkzustand ist eine signierte Historie, die jedes Mitglied an andere Mitglieder weitergeben kann
    • Selbst wenn die Macher von Rayfish verschwinden, funktionieren bestehende Netzwerke weiter

Wie ein Gerät mehrere Netzwerke handhabt

  • Rayfish geht davon aus, dass Nutzer nicht nur ein einziges flaches Netzwerk verwenden
  • Ein Gerät kann gleichzeitig zu Netzwerken für Freunde, ein Nebenprojekt und die Arbeit gehören
  • Die Implementierung läuft hinter einem einzelnen Prozess und einem einzelnen virtuellen Interface
  • Jedes Netzwerk ist voneinander isoliert, und der Nutzer ist vollwertiges Mitglied aller Netzwerke, denen er beigetreten ist

Der durch Iroh v1 ermöglichte Release

  • Rayfish überlässt die schwierigen Teile der Transportschicht Iroh
    • verschlüsselte QUIC-Verbindungen zwischen Peers
    • NAT-Traversal
    • Hole Punching
    • Relay-Fallback, wenn kein direkter Pfad verfügbar ist
  • Iroh v1 lieferte die Stabilität, damit die Transportschicht während der Entwicklung nicht ins Wanken geriet, und machte diesen Release möglich
  • Die nächste Aufgabe ist, die frühen Tools zu Werkzeugen zu verfeinern, die man bedenkenlos in Produktion laufen lassen kann

Spin-off von Field Technologies

  • Rayfish ist ein Projekt, das aus dem Hochfrequenzhandelsunternehmen Field Technologies ausgegründet wurde
  • Grundlage sind interne Erfahrungen mit verteilten Systemen, bei denen mehrfach Geräteerkennung, Konsens über gemeinsamen Zustand sowie schnelle und private Kommunikation aufgebaut wurden
  • Diese interne Infrastruktur entstand vor allem, um nicht von den Control Planes anderer Unternehmen abhängig zu sein
  • Rayfish war eine Idee, die über mehr als vier Jahre weiterverfolgt wurde, doch weil es keinen zentralen Betreiber gibt, gab es keinen offensichtlichen Abrechnungspunkt, was die Produktisierung verzögerte
  • Künftig könnte es auf Unternehmensprobleme wie Fleet Management oder Auditing ausgeweitet werden, solche Funktionen existieren aber noch nicht

Derzeit verfügbare Funktionen

  • Peer-to-Peer-Struktur

    • Rayfish ist kein Hub-and-Spoke-System, sondern Peer-to-Peer
    • Alle Mitglieder verbinden sich direkt mit allen anderen Mitgliedern
    • Mitgliedschaft ist kein Wert, der bei einem Server abgefragt wird, sondern eine signierte Historie, die jedes Mitglied mit sich führt
    • Der Koordinator, der ein Netzwerk erstellt hat, wird nur benötigt, wenn neue Mitglieder aufgenommen werden; nach dem Beitritt funktioniert das Netzwerk ohne zentrale Person

  • Geschlossene Netzwerke und Beitrittswege

    • Netzwerke sind standardmäßig geschlossen
    • Ein Koordinator kann neue Mitglieder auf zwei Arten aufnehmen
      • einmalige Einladungscodes
      • Live-Freigabe von Beitrittsanfragen
    • Wenn ein öffentliches Netzwerk benötigt wird, kann man mit ray create --open das Gate öffnen; dann reicht die room id für den Beitritt
    • Beigetretene Mitglieder sind über eine stabile IP und vertraute Magic-DNS-Namen erreichbar
    • Der Standard-Hostname kann etwa mit ray up --hostname dario gesetzt werden, und --hostname kann pro Netzwerk überschrieben werden
    ray up --hostname dario
ray create --name prod
ray invite prod --hostname web
ray join <code>

  • Firewalls pro Gerät

    • Jedes Gerät hat seine eigene Firewall und entscheidet selbst, was es von wem annimmt
    • Der Koordinator kann empfohlene Firewall-Regeln pro Netzwerk veröffentlichen
    • Jeder Host kann die Regeln übernehmen oder die automatische Installation wählen
    • Es ist ein Modell mit gemeinsamen Standardwerten, ohne zentralen Policy-Server, dem alle zwingend folgen müssen

  • Fleet-Provisioning

    • Mehrere Geräte können Netzwerke und Firewall-Regeln über deklarative Dateien definieren und anwenden
    • Die Spezifikation ist eine networks:-Map; unter jedem Netzwerk werden die pro Host erlaubten Peers und Ports angegeben
    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
    • Für Fleets können wiederverwendbare Schlüssel erstellt werden, statt für jede Box einen Code auszustellen
    ray invite prod --reusable
ray join <key> --hostname web01 --auto-accept-firewall
    • Wird ein Schlüssel widerrufen, werden nur neue Beitritte verhindert; bereits beigetretene Server werden nicht gestört
    • ray apply arbeitet idempotent, sodass die Spezifikationsdatei der Sollzustand der Fleet bleibt

  • 1:1-Verbindungen und Dateiübertragung

    • Wenn kein eigenes Netzwerk erstellt werden muss, kann man mit ray connect eine 1:1-Verbindung auf Basis einer Kontakt-ID herstellen
    ray contact id
ray connect <their-contact-id>
ray connections approve <id>
    • Nach der Freigabe wird automatisch ein privates Zwei-Peer-Netzwerk erstellt
    • Magic DNS, Firewall und Mesh-Funktionen funktionieren identisch und erscheinen in ray status als [direct]
    • Kontakt-IDs können rotiert werden, bereits eingerichtete Verbindungen funktionieren weiter
    • Da zwischen Mitgliedern bereits ein authentifizierter und verschlüsselter Pfad besteht, können Dateien ohne separaten Dienst gesendet werden
    ray send ./build.tar.gz web01
ray files accept 1

Unterschiede zu Tailscale

  • Sowohl Tailscale als auch Rayfish bieten stabile IPs, Magic DNS, NAT-Traversal und eine P2P-Datenebene
  • Der größte Unterschied ist der Ort der Kontrolle
    • Tailscale nutzt eine Control Plane wie den Tailscale-Koordinationsserver oder das self-hosted Headscale
    • Rayfish hat keine zentrale Control Plane, sondern hält den Netzwerkzustand als signierte Historie, die per P2P weitergegeben wird
  • Auch die Datenebene unterscheidet sich
    • Tailscale verwendet WireGuard, das im Kernel läuft
    • Rayfish verwendet Iroh/QUIC-Datagramme im Userspace
  • Bei der Geschwindigkeit ist Tailscale in der Regel im Vorteil
    • Da WireGuard im Kernel läuft, kann der Unterschied bei großen Übertragungen über schnelle Links deutlich sein
    • Rayfish tauscht etwas rohen Durchsatz gegen eine Struktur ohne zentrale Partei
  • Rayfish verwendet nicht Accounts oder SSO, sondern ein Schlüsselpaar auf der Festplatte als Identität
  • Rayfish ist jung und auf Minimalfunktionen fokussiert, während Tailscale ausgereift ist und eine breite Funktionspalette bietet

Unterschiede zu Yggdrasil

  • Yggdrasil bietet ein Ende-zu-Ende-verschlüsseltes IPv6-Netzwerk ohne zentrale Autorität
  • Der Unterschied liegt in der letzten Ebene, mit der Nutzer direkt umgehen müssen
    • Yggdrasil bietet ein einzelnes globales Netzwerk und IPv6-Adressen
    • Rayfish bietet separate private Netzwerke, die Nutzer erstellen und denen sie Mitglieder hinzufügen
  • Rayfish enthält Komfortfunktionen wie Einladungscodes, vertraute DNS-Namen, Firewalls pro Netzwerk und Freigabe-Prompts für Beitritte
  • Yggdrasil eignet sich für Engineers mit Netzwerkwissen, während Rayfish auch Nutzer ansprechen soll, die einfach ein privates Netzwerk für wenige Personen erstellen wollen

Was man damit bauen kann und was nicht

  • Rayfish ist keine Library, sondern ein fertiges Tool
  • Es lässt sich nicht wie ein SDK in Anwendungen einbetten
  • Es passt zu Anwendungsfällen, in denen Geräte mit installiertem Rayfish privat miteinander kommunizieren müssen
    • P2P-Gameserver, auf die Freunde per Name zugreifen
    • interne APIs, die nicht über das öffentliche Internet erreichbar sind
    • Backup-Ziele
    • Chat- oder Anruf-Apps zwischen Netzwerkmitgliedern
    • eine Datenbank, die von zwei Teams geteilt wird, die einander sonst nicht sehen sollen
  • Anwendungen können Peers über name.network.ray erreichen
  • Außenstehende ohne installiertes Rayfish können nicht auf das Netzwerk zugreifen, und es gibt kein Gateway für Externe

Beispiele für reale Konfigurationen

  • Zwei Abteilungen teilen sich eine Datenbank

    • Wenn payments und analytics als getrennte Netzwerke angelegt werden, können die beiden Abteilungen einander nicht sehen
    • Nur die Datenbank-Box tritt beiden Netzwerken bei
    • Die empfohlene Firewall wird so gesetzt, dass in jedem Netzwerk nur die benötigten Ports geöffnet sind
    networks:
  payments:
    db:
      allows:
        "*": "tcp:8123,tcp:9000"
  analytics:
    db:
      allows:
        "*": "tcp:8123,tcp:9000"
    • Jedes Team greift über db.payments.ray oder db.analytics.ray zu
    • Die beiden Netzwerke wissen nichts voneinander, und Zugriffskontrolle entsteht durch Netzwerktrennung und einen gemeinsamen Host, ohne zentrales ACL-Audit

  • Minecraft-Server für Freunde

    • Wenn man ein geschlossenes Netzwerk erstellt und Freunde einlädt, können sie sich per Name verbinden, ohne IP-Adressen, Port-Forwarding oder dynamisches DNS
    ray create --name mc
ray invite mc
    • Clients verbinden sich mit mc-host.mc.ray:25565

  • Geschlossene Gruppe, in der alle einen Port öffnen

    • Wenn alle Mitglieder TCP 6969 öffnen müssen, kann ein Admin die Regel einmal vorschlagen
    ray firewall suggest mc --subject '*' --allow '*:tcp:6969'
    • Jedes Mitglied prüft die vorgeschlagene Regel und akzeptiert oder lehnt sie ab
    ray firewall pending mc
ray firewall accept mc
    • Firewall-Vorschläge sind keine erzwungenen Regeln und können abgelehnt werden, wenn ein Mitglied sie nicht möchte

Sicherheit und Adressvergabe

  • IP-Adressen werden nicht von einem Server vergeben, sondern aus der kryptografischen Identität jedes Peers abgeleitet
  • Adresskollisionen sind sehr selten; wenn eine Kollision auftritt, platziert der Koordinator den zweiten Peer im nächsten freien Slot
  • Alle Peers konvergieren ohne zentralen Zuweiser deterministisch auf dieselbe Adressvergabe
  • Rayfish baut Sicherheit statt über zentrale ACLs über zwei Mechanismen auf
    • Segmentierung, bei der nur Peers kommunizieren können, die dasselbe Netzwerk teilen
    • Firewalls pro Netzwerk auf jedem Gerät
  • Um prod und dev zu isolieren, erstellt man einfach zwei Netzwerke
  • Hosts, die mehreren Netzwerken angehören, führen in jedem Netzwerk ihre eigene Firewall

Ob Server und offene Ports nötig sind

  • Es muss kein separater Control Server gehostet werden
  • Der Koordinator, der das Netzwerk erstellt hat, kann offline sein, sobald alle Mitglieder beigetreten sind
  • Iroh übernimmt NAT-Traversal und Hole Punching; wenn ein direkter Pfad nicht möglich ist, wird ein verschlüsselter Relay-Fallback genutzt
  • Wenn man den Router kontrolliert und einen garantierten direkten Pfad zu einer bestimmten Box möchte, kann man Rayfishs festen UDP-Port weiterleiten, es ist aber optional

Weitere Pläne und wann es nicht passt

  • Derzeit wird Rayfish auf Desktops und Servern als Kommandozeilentool angeboten
  • Als Nächstes geht es darum, auf Geräte zu expandieren, die Nutzer tatsächlich mit sich tragen
    • Android-Client
    • iOS-Client
    • eine richtige Desktop-App
  • Parallel werden bestehende Funktionen gehärtet, damit sie bedenkenlos in Produktion genutzt werden können
  • Wenn Tailscale, das Firmen-VPN oder ein selbst konfiguriertes WireGuard-Mesh bereits gut funktioniert, gibt es wenig Grund, zu Rayfish zu wechseln
  • Rayfish ist jünger und hat weniger Funktionen; viele Funktionen bieten bestehende Tools glatter an
  • Rayfish entfernt eine Sache
    • Accounts
    • Unternehmen, die ein Netzwerk abschalten können
    • Control Server, die dauerhaft laufen müssen
    • Policy-Datenbanken, die jemand anderes betreibt

Erste Schritte

  • Die Installation beginnt mit einem Einzeiler
curl -fsSL https://rayfish.xyz/install.sh | sh
  • Das Erstellen des ersten Netzwerks und der Einladungsprozess werden in der Dokumentation weiter erklärt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Meinungen auf Lobste.rs

  • Ich finde es wirklich gut, dass Rayfish von Anfang an davon ausgeht, mehr als ein Netzwerk gleichzeitig zu handhaben.
    Bei Tailscale scheint das keine Priorität zu haben, daher könnte das ein ziemlich großer Vorteil sein.
    Unerwartet fand ich die Stelle, dass es aus einer Hochfrequenzhandelsfirma ausgegründet wurde; und die Aussage, Tailscale gewinne bei der Geschwindigkeit, weil „die WireGuard-Datenebene im Kernel läuft“, ist falsch. Tailscale nutzt Kernel-WireGuard nicht, trotzdem nehmen Leute das immer wieder an.
    Es hieß zwar „Idee, Produkt und Text sind von mir“, aber dass im Repository eine CLAUDE.md liegt, finde ich schade. Laut Beitragsübersicht hat clod allerdings 1.017++ / 383-- Zeilen, der Autor dagegen 104.786++ / 47.064-- Zeilen; der Großteil des Codes scheint also nicht schnell mit AI zusammengebastelt worden zu sein. Trotzdem frage ich mich, ob es wegen 1/100 des Arbeitsaufwands nötig war, so eine Spur im Repository zu hinterlassen.

    • Selbst wenn AI-Unterstützung im Spiel war, stört mich das nicht groß. Entscheidend ist die Praxistauglichkeit, und wenn es eine wirklich dezentrale Tailscale-Alternative ist, wäre das enorm.
      Bisher habe ich Iroh vor allem in niedlichen, aber wenig nützlichen Anwendungen gesehen; vielleicht ist genau das hier die App dafür.
    • Da es auf Iroh basiert, gibt es QUIC, und damit könnte man in einem Mesh-VPN vielleicht endlich quantenresistente Kryptografie nutzen.
      Auch das scheint bei Tailscale keine Priorität zu haben.

  • Das Produkt selbst sieht wirklich cool aus; das Einzige, was mich davon abhält, mein Tailscale-Mesh zu ersetzen, ist das Fehlen eines Android-Clients.
    Der Text las sich allerdings zumindest teilweise so, als wäre er von AI geschrieben worden, was mich etwas gestört hat.

  • Der Vergleich mit Yggdrasil ist dürftig und enthält auch sachliche Fehler. Das Yggdrasil-Testnet wird zwar als globales Netzwerk betrieben, aber das ist nur ein praktisches Ergebnis der Topologiestruktur von Yggdrasil.
    Jede Verbindung zwischen zwei getrennten Schlüsselmengen kann dynamisch akzeptiert werden, und der Unterschied zwischen zwei getrennten Yggdrasil-Netzwerken und einem großen Netzwerk besteht nur darin, ob sie miteinander Nachrichten austauschen. Jeder kann ein privates Yggdrasil-Netzwerk erstellen.
    Schlüssel sind kryptografisch nicht erratbar, aber ich würde nicht sagen, dass das auch Hidden Services bedeutet. Domainnamen sind willkürlich, aber viele Leute lassen globales DNS auf den Yggdrasil-Adressraum zeigen.
    Wenn die Perspektive lautet: „Wenn man nur ein Netzwerk für drei Freunde und einen Gameserver will, muss man bei Yggdrasil viel zusammenbauen“, dann ist es eher überraschend, dass kein Vergleich mit tinc vorkommt, das für drei Freunde und einen Gameserver fast der Standard ist.

    • Die öffentliche ID selbst mag nicht erratbar sein, aber in geteilten Logs oder Bugreports kann die öffentliche ID auftauchen. Ein privates Netzwerk mit Genehmigungs-Prompt adressiert genau dieses Problem.
      Genau darum geht es bei der Beschreibung, dass es kein Konzept gibt, ein separates privates Netzwerk zu erstellen und Personen aufzunehmen, und auch keine Komfortfunktionen wie Einladungscodes, vertraute DNS-Namen, netzwerkspezifische Firewalls oder einen Genehmigungs-Prompt, wenn jemand beitreten möchte. Für Netzwerkingenieure ist das vielleicht kein Problem.
      Ein weiterer Punkt, der im Vergleich mit Yggdrasil fehlt: Rayfish nutzt Irohs NAT-Hole-Punching, sodass zwei Peers kommunizieren können, auch wenn keine der beiden Seiten öffentlich erreichbar ist.