Tailscale Peer Relays: Eigene Geräte als Hochgeschwindigkeits-Relays nutzen

 (tailscale.com)
2 Punkte von GN⁺ 2026-02-19 | 1 Kommentare | Auf WhatsApp teilen
  • Tailscale Peer Relays sind jetzt allgemein verfügbar und ermöglichen es Nutzern, ihre eigenen Geräte als leistungsstarke Relay-Nodes zu verwenden
  • Unterstützt stabile und schnelle Traffic-Weiterleitung auch in Umgebungen, in denen direkte Verbindungen wegen Firewalls, NAT oder Einschränkungen von Cloud-Netzwerken schwierig sind
  • Durch höheren Durchsatz, verbesserte Lock-Contention und verteilte Verarbeitung über UDP-Sockets verbessert sich die Performance bei vielen Client-Verbindungen deutlich
  • Durch die Integration statischer Endpunkte kann ein Relay auch in Cloud-Umgebungen betrieben werden, in denen automatische Erkennung nicht möglich ist, etwa hinter einem AWS NLB
  • Durch integrierte Transparenz und Monitoring lassen sich Traffic-Pfade, Latenz und Relay-Status klar nachvollziehen, was für den Betrieb großer Netzwerke wichtig ist

Überblick über Tailscale Peer Relays

  • Peer Relays sind eine Funktion, mit der sich eine Hochleistungs-Relay-Funktion auf eigenen Geräten ausführen lässt
    • Zusätzlich zu den bestehenden DERP-Relays können auch vom Nutzer selbst bereitgestellte Nodes als Relays verwendet werden
    • Seit der Beta wurden Performance, Stabilität und Transparenz deutlich verbessert, sodass die Funktion nun produktionsreif ist
  • Ursprünglich als Funktion zur Umgehung komplexer NAT-Umgebungen gedacht, wurde sie zu einer Verbindungsoption für große Netzwerke ausgebaut
    • Bietet Teams eine Struktur, mit der sich Performance, Kontrolle und Flexibilität sichern lassen

Verbesserungen bei Performance und Zuverlässigkeit

  • Wenn viele Clients über ein Relay verbunden sind, steigt der Durchsatz deutlich
    • Clients wählen innerhalb des Relays automatisch die am besten geeignete Schnittstelle und Address Family aus
    • Das Relay steigert die Effizienz der Paketverarbeitung durch weniger Lock-Contention und verteilte Verarbeitung über mehrere UDP-Sockets
  • Diese Verbesserungen erhöhen Performance und Stabilität auch im normalen Traffic-Betrieb und liefern selbst dann, wenn direkte Verbindungen nicht möglich sind, eine Leistung nahe an einem Mesh-Netzwerk

Unterstützung statischer Endpunkte

  • In öffentlichen Cloud-Umgebungen ist die automatische Erkennung von Endpunkten oft schwierig
    • Wegen Firewall-Regeln, Port Forwarding oder Load Balancern ist das Öffnen beliebiger Ports oft nicht möglich
  • Peer Relays können mit dem Flag --relay-server-static-endpoints feste IP:Port-Paare ankündigen
    • So können externe Clients Traffic über das Relay weiterleiten, auch wenn es sich hinter Infrastruktur wie einem AWS Network Load Balancer befindet
  • Damit lassen sich schnelle Verbindungen auch in eingeschränkten Cloud-Umgebungen sicherstellen, und durch den Ersatz von Subnet Routern wird eine Full-Mesh-Konfiguration möglich

Integrierte Transparenz und Monitoring

  • Peer Relays sind direkt in die Observability-Werkzeuge von Tailscale integriert, sodass sich ihr Verhalten klar nachvollziehen lässt
    • Mit dem Befehl tailscale ping lässt sich prüfen, ob ein Relay verwendet wird, ob es erreichbar ist und wie es sich auf Latenz und Zuverlässigkeit auswirkt
    • Bei Problemen lässt sich sofort erkennen, ob der Traffic über ein Relay läuft und ob dessen Status in Ordnung ist
  • Als Monitoring-Metriken werden tailscaled_peer_relay_forwarded_packets_total und tailscaled_peer_relay_forwarded_bytes_total bereitgestellt
    • In Verbindung mit Prometheus, Grafana und ähnlichen Tools sind Analyse von Traffic-Mustern, Anomalieerkennung und Überwachung des Netzwerkzustands möglich

Allgemeine Verfügbarkeit und Bereitstellung

  • Die jetzt allgemein verfügbaren Peer Relays sind ein zentraler Bestandteil der Skalierbarkeit von Tailscale
    • Bieten schnelle Verbindungen mit geringer Latenz, wenn ein direkter Pfad nicht möglich ist
    • Funktionieren durch Bereitstellung auf Basis statischer Endpunkte auch in eingeschränkten Cloud-Umgebungen
    • Unterstützen Full-Mesh-Konfigurationen in privaten Subnetzen sowie die Steuerung von Ein- und Ausgangspfaden
  • Die grundlegenden Sicherheitsprinzipien von Tailscale bleiben erhalten, darunter Ende-zu-Ende-Verschlüsselung, Least-Privilege-Zugriff und vorhersehbares Verhalten
  • Kann per CLI auf allen unterstützten Nodes aktiviert werden und unterstützt ACL-basierte Kontrolle sowie schrittweise Rollouts
  • Peer Relays sind in allen Tarifen, einschließlich des kostenlosen Personal-Plans, verfügbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-19
Hacker-News-Kommentare

  • Wenn Tailscale Vertrauen genießt, weil es „offen“ ist, sollte man zugleich wissen, dass einige Clients Closed Source sind
    Sie werden nur über offizielle Vertriebskanäle verteilt, etwa den Apple App Store, und stehen vollständig unter deren Kontrolle
    Die Logik zur Rechtfertigung dieser Position ist befremdlich: Wenn es in Ordnung sei, dass Nutzer ein proprietäres OS verwenden, dann sei es auch in Ordnung, wenn Tailscale proprietär ist
    In einer solchen Struktur ist Vertrauen in Umgebungen mit eingeschränkter Konnektivität schwer
    Selbst wenn es technisch besser ist als die Konkurrenz, bleibt es am Ende eben ein Geschäft. Wenn möglich, sollte man freie Software-Alternativen unterstützen
    Zugehöriges GitHub-Issue

    • Ich möchte klarstellen, dass auf manchen Plattformen nur die GUI proprietär ist (Tailscalar)
    • Mir ist Kontrolle wichtiger als Performance
      Wenn Nutzer direkt aus dem Quellcode bauen können, lassen sich auch Performance-Verbesserungen erreichen; ohne Kontrolle gibt es jedoch keine Möglichkeit, unbefriedigende Aspekte selbst zu beheben
      Kommerzielle Software ist oft qualitativ schwach, update-abhängig und priorisiert Time-to-Market vor Ausgereiftheit
    • Der CLI-Client für macOS lässt sich direkt aus dem Quellcode bauen
      Er kann mit dem Befehl go install tailscale.com/cmd/tailscale{,d}@latest installiert werden und wird im offiziellen Wiki beschrieben
      Die GUI ist proprietär, aber die CLI ist vollständig offen und kann daher auch in eingeschränkten Netzwerkumgebungen verwendet werden
    • Die meisten Mac-Apps sind Closed Source, daher stört mich ein einzelnes Tailscale-Menüleisten-Icon nicht
      Wenn es wirklich lästig ist, kann man brew oder die CLI zur Steuerung verwenden
    • Ich halte ein Hybridmodell aus Open Source und kommerzieller Software für einen realistischen Kompromiss
      Ich entwickle selbst gerade eine App mit ähnlicher Struktur: Die CLI wird vollständig Open Source sein, die GUI möchte ich kostenpflichtig verkaufen
      So kann ich die Entwicklung fortführen und meinen Lebensunterhalt sichern
      GUI und CLI entwickle ich gemeinsam auf Basis der validate-Bibliothek

  • Ich habe kürzlich Tailscale eingerichtet, und der Ping sank von 16 ms auf 10 ms, während sich die Bandbreite verdreifachte
    Zusammen mit Moonlight/Sunshine kann ich Windows-Spiele mit 50 Mbps/10 ms von meinem Linux-Desktop auf ein MacBook streamen
    Ich habe den Router nur als Peer-Node eingerichtet, ohne Port-Forwarding

    • In Bezug auf Sunshine könnte man Apollo ausprobieren
    • Ein interessanter Anwendungsfall, aber im Grunde wurde NAT-Traversal und Port-Forwarding an ein automatisiertes Protokoll delegiert
    • Ich frage mich, ob die andere Person für öffentliches Game-Streaming an normale Nutzer ebenfalls Tailscale installieren muss
      Ich würde gern wissen, ob Tailscale grundsätzlich auf Freigaben zwischen vertrauenswürdigen Nutzern ausgerichtet ist
    • Ich habe eine ähnliche Konfiguration mit einem OpenWRT-Router versucht und dachte trotzdem, ich müsse Ports öffnen
      Wenn das so ist, wäre es dann nicht weiterhin dem Internet ausgesetzt? Das verwirrt mich

  • Mich interessiert das Geschäftsmodell von Tailscale. Der Dienst gefällt mir, aber ich sorge mich um die langfristige Nachhaltigkeit
    Manchmal fühlt es sich auch so an, als gäbe es Rate Limits

    • Unser Unternehmen nutzt den Business-Plan für 18 US-Dollar pro Nutzer und Monat
      Wenn das Team größer wird, ist ein kostenpflichtiger Plan Pflicht, und Funktionen wie serve/funnel und SSH sind nützlich
      Früher haben wir Zerotier verwendet und es einige Jahre kostenlos genutzt; als die Nutzerzahl stieg, zahlten wir nur etwa 5 US-Dollar im Monat
    • Ursprünglich sollte Tailscale nach der ersten Verbindung eine P2P-WireGuard-Verbindung herstellen, daher sollte es eigentlich keine Drosselung geben
      Je nach Netzwerkumgebung kann jedoch ein Relay erforderlich sein
      Als Open-Source-Alternativen gibt es Headscale und Netbird
    • Der offizielle Blogbeitrag zum Free-Plan ist dazu lesenswert
    • Das ist ein typischer Fall eines Freemium-Modells: erst Popularität über einen kostenlosen Entwickler-Plan, dann steigen Unternehmen auf kostenpflichtige Pläne um
    • Da P2P-Verbindungen fast keine Kosten verursachen, ist die Strategie wirksam, über einen Free-Tier Entwicklerbindung aufzubauen

  • Der Wechsel zu Peer Relay ist ein großer Gewinn für Self-Hoster in NAT-Umgebungen
    Man muss keinen eigenen DERP-Server mehr direkt einrichten, was die UX verbessert

    • (Tailscale-Mitarbeiter Alex) Wir hatten dasselbe Problem
      Peer Relay ließ sich mit überschaubarem Implementierungsaufwand umsetzen, indem die bestehende Subnet-Router- und Exit-Node-Infrastruktur wiederverwendet wurde
      Auch in restriktiven NAT-Umgebungen wie AWS ist das für stabile Verbindungen unverzichtbar
      Im Ergebnis wurden sowohl Latenz als auch Nutzererfahrung verbessert
    • Es gab Fälle, in denen zentraler DERP den Traffic wie ein Black Hole verschlang, aber in letzter Zeit ist es stabil
      Mit der Einführung von Peer Relay dürfte die Wahrscheinlichkeit solcher Probleme weiter sinken

  • Entscheidend ist, dass Peer Relay UDP unterstützt
    DERP basiert auf TCP, was bei Game-Streaming oder Sprachkommunikation zu Latenzproblemen führte
    Peer Relay nutzt UDP und ist daher für Echtzeit-Traffic deutlich besser geeignet
    Ohne eine separate DERP-Instanz einzurichten, kann es direkt auf bestehenden Subnet-Routern aktiviert werden

    • Wenn jedoch aufeinanderfolgend positive Kommentare von neuen Accounts erscheinen und teilweise Tailscale-Mitarbeiter antworten, wirkt das wie KI-gestützte PR
      Solche KI-Kommentare untergraben das Vertrauen der Community und sollten unterbleiben

  • Wenn es mehrere Relays gibt, frage ich mich, ob Tailscale automatisch den Node mit der geringsten Latenz auswählt

  • In einer realen CGNAT-Umgebung hat mir Tailscale sehr geholfen
    Ich betreibe ein KI-Vision-System auf Google Cloud Run, aber mein ISP blockierte Port-Forwarding
    Über Tailscale konnten der Cloud-Run-Container und die Kamera so kommunizieren, als wären sie im selben LAN
    Dank Peer Relay dürfte sich auch das Latenzproblem verringern, das bei häufigen Neustarts des Containers entstand
    Ich frage mich allerdings, wie die Relay-Auswahl in Umgebungen mit ephemeren Nodes funktioniert

  • Ich nutze bereits ein selbst eingerichtetes WireGuard-Netzwerk und frage mich, was Tailscale intern eigentlich tut
    Es gibt viele „Magie“-Funktionen, die DNS, Routing, Firewall usw. automatisch anpassen, und das macht mich nervös
    Ich habe die offizielle Dokumentation gelesen, aber sie ist bei den Details nicht tief genug
    Ich möchte wissen, ob es auch in komplexen Netzwerkkonfigurationen zuverlässig funktioniert

    • (Tailscale-Mitarbeiter) Es ist schwer, perfekte Dokumentation aktuell zu halten, aber wir versuchen, umgebungsadaptive Heuristiken so gut wie möglich zu dokumentieren
      Unter Linux gibt es viele verschiedene Konfigurationsmuster, was es komplex macht
      Das wird auch in diesem zugehörigen Blogbeitrag erklärt
      Die wichtigsten Verhaltensweisen sind folgende
      • Regelbasiertes Routing zur Vermeidung von Konflikten
      • Bevorzugte Integration mit systemd-resolved, andernfalls Anpassung von /etc/resolv.conf
      • Unterstützung sowohl für iptables als auch nftables sowie Kompatibilität mit ufw/firewalld
      • SSH-Login mit möglichst hoher Kompatibilität unter Berücksichtigung distributionsspezifischer Unterschiede
      • Für stabile Kommunikation wird ein MTU-Pfad von 1360 Byte benötigt
        In stark angepassten Umgebungen kann es zwar Probleme geben, diese lassen sich aber oft mit Support lösen
    • Der Client ist Open Source, und einige Mitarbeiter tragen auch zu reverse-engineerten Servern wie Headscale bei
    • Headscale ist als Open-Source-Alternative einen Blick wert

  • Ich habe die Seite auf dem Smartphone geöffnet, aber keinen Schließen-Button gesehen und konnte das Modal nicht schließen
    Siehe Screenshot
    Später habe ich ihn gefunden, aber die Position war merkwürdig

    • Der Schließen-Button ist das weiße X im blauen Kasten unten rechts im Modal