- Tailscale Peer Relays sind eine neue Traffic-Relay-Funktion als Ersatz für bestehende DERP-Server, die Nutzer selbst bereitstellen und verwalten können
- Jeder Node kann mit nur einem offenen UDP-Port als Relay fungieren und lässt sich direkt im Tailscale-Client integriert einfach aktivieren
- Unterstützt schnelle Verbindungen mit hohem Durchsatz und liefert selbst hinter Cloud-NAT oder Firewalls eine Performance nahe an Direktverbindungen
- Der gesamte Traffic bleibt mit WireGuard®-basierter Ende-zu-Ende-Verschlüsselung geschützt; automatischer Fallback auf DERP und benutzerdefiniertes DERP wird unterstützt
- Aktuell als Public Beta verfügbar; in allen Tarifen sind bis zu 2 kostenlose Peer Relays enthalten
Überblick über Tailscale Peer Relays
- Tailscale Peer Relays sind ein vom Nutzer verwalteter Traffic-Relay-Mechanismus, der die gemanagten DERP-Server von Tailscale ersetzen kann
- Jeder Tailscale-Node kann als Relay konfiguriert werden und Traffic zwischen Nodes im selben tailnet weiterleiten
- Ein Relay kann nur Nodes aus dem tailnet weiterleiten, zu dem es selbst gehört
- Da Kunden sie selbst verwalten, gibt es weniger Durchsatzbeschränkungen als bei DERP, und sie bieten hohe Performance auch in abgeschlossenen Cloud-Infrastrukturen oder hinter Firewalls
- In ersten Tests mit Partnern wurde ein Durchsatz nahe an Direktverbindungen erreicht; gegenüber bestehendem DERP wurde eine um ein Vielfaches höhere Performance bestätigt
Hard-NAT-Umgebungen überwinden
- Tailscale nutzt verbesserte NAT-Traversal-Techniken, um selbst in NAT-Umgebungen möglichst Direktverbindungen (über 90 %) aufrechtzuerhalten
- In einigen Cloud-Umgebungen können Direktverbindungen jedoch unmöglich oder ineffizient sein
- Das bisherige DERP bietet zwar stabile Verbindungen, bringt aber in manchen Deployment-Umgebungen Herausforderungen durch QoS-Beschränkungen und Performance-Limits mit sich
- Peer Relays wurden als leistungsorientiertes Verbindungswerkzeug entwickelt und sind dank UDP-basierter Kommunikation mit geringer Latenz sowie direkter Integration in den Client einfach bereitzustellen
- Kunden können Relays selbst platzieren und so leistungsstarke und hochflexible Netzwerkarchitekturen aufbauen
Funktionsweise
- Ein Peer Relay verwendet einen einzelnen UDP-Port, der von beiden Endpunkten erreichbar ist
- Die Aktivierung ist einfach per CLI-Befehl
tailscale set --relay-server-port möglich
- Wenn eine Direktverbindung nicht möglich ist, erfolgt der automatische Fallback in der Reihenfolge Peer Relay → DERP (gemanagt oder benutzerdefiniert)
- Alle Verbindungen sind durch WireGuard®-Verschlüsselung geschützt
- Die Konfiguration kann so erfolgen, dass bei minimalen Firewall-Ausnahmen nur Traffic innerhalb des tailnet erlaubt wird
- Unterstützt regionale Skalierung, Netzwerkfehlertoleranz und automatischen DERP-Fallback
Verschiedene Einsatzszenarien
- Schnelle Weiterleitung von Traffic ohne mögliche Direktverbindung in Cloud-NAT-Umgebungen (z. B. AWS Managed NAT Gateway)
- In strengen Firewall-Umgebungen muss nur ein einzelner UDP-Port geöffnet werden, was Freigabeprozesse verkürzt
- Reduzierung der Last im DERP-Netzwerk sowie kein Bedarf an Wartung für benutzerdefiniertes DERP
- Beim Zugriff auf abgeschlossene Kundennetzwerke müssen über vorhersehbare Endpunkte nur minimale Ports geöffnet werden
- Reale Kunden setzen Peer Relays bereits für Zugriff auf nicht verwaltete Netzwerke, Steuerung von Verbindungsrouten zu Partnern und feingranulare Netzwerkarchitekturen auf Basis von VPC-Peering ein
Public Beta und Bereitstellungsrichtlinie
- Tailscale Peer Relays sind ab sofort als Public Beta verfügbar
- Derzeit wird an Verbesserungen bei Sichtbarkeit und Debugging gearbeitet
- Erste Partner haben einfache Bereitstellung und stabile Performance bestätigt
- In allen Tarifen, einschließlich des kostenlosen, sind bis zu 2 Peer Relays kostenlos enthalten; zusätzliche Relays können erweitert werden
- Bei Bedarf an weiteren Relays ist eine Erweiterung über eine Anfrage an das Tailscale-Vertriebsteam möglich
1 Kommentare
Hacker-News-Kommentare
Ich halte dieses Feature wirklich für sinnvoll
Es verwendet nur dann einen Zwischenknoten, wenn eine direkte Verbindung nicht möglich ist, und der Datenverkehr ist Ende-zu-Ende-verschlüsselt
Es ist ähnlich, als würde man selbst einen DERP-Server betreiben, nur dass man keine Ports öffnen muss, und durch die geringere Nutzung von Tailscales Relays sinken auch die Bandbreitenkosten
Ich frage mich allerdings, warum es kostenpflichtig ist, sobald man mehr als zwei Relays nutzt
Wenn nicht, braucht man Tailscale womöglich von vornherein nicht
Als Ausnahme gibt es Fälle, in denen zwei Clients zwar auf das Relay zugreifen können, aber nicht direkt miteinander verbunden werden können
tinc hat dieses Problem schon früher gelöst
Jeder Knoten kann als Relay fungieren, und es arbeitet als echtes Mesh-Netzwerk ohne zentralen Server
Statt das neu zu implementieren, wäre es meiner Meinung nach besser, es auf Basis von WireGuard in eine speichersichere Sprache zu portieren
Oft bricht die Route direkt nach dem Aufbau einer SSH-Verbindung ab
Da der Verkehr auf dem Relay-Knoten entschlüsselt und erneut verschlüsselt wird, braucht man für Ende-zu-Ende-Verschlüsselung ein experimentelles Protokoll
Ich würde es gern auf Basis des cjdns-Protokolls neu schreiben, aber das ist nicht einfach
Tailscales neues Peer-Relay-Feature wirkt ähnlich wie etwas, das ZeroTier früher schon hatte
Es als „eine exklusive Funktion nur von Tailscale“ darzustellen, wäre überzogen, und zusätzliche Gebühren neben der nutzerbasierten Abrechnung wirken übertrieben
Stattdessen waren das eigene Verschlüsselungsverfahren, schwache Single-Thread-Performance und das langsame Entwicklungstempo problematisch
Ich habe mehrere Alternativen ausprobiert, aber bisher gibt es nichts, das wie Tailscale sowohl Funktionen als auch Performance bietet
Der Vergleich fühlt sich an wie „Warum Dropbox nutzen, wenn es FTP gibt?“
Ich frage mich, ob man externe IPv4-/IPv6-Adressen direkt angeben kann
Denn es gibt Fälle, in denen ein- und ausgehender Traffic unterschiedliche Adressen nutzen oder Firewalls nur einige Adressen aus mehreren Internetverbindungen zulassen
Letzte Woche habe ich headscale und Split-Horizon-SSL eingerichtet und dann festgestellt, dass letztlich nur DERP möglich ist
Ich denke, es wäre besser, UDP-Ports im lokalen Netzwerk direkt freizugeben
Wenn die Sicherheit des WireGuard-Clients ausreichend verifiziert ist, wäre das deutlich praktischer
Ich würde gern wissen, ob versucht wurde, den direkten WireGuard-Port zu öffnen, oder ob der Tailscale-Port gemeint ist
Wenn man dieses Feature statt DERP nutzt, funktioniert es im Browser nicht
Der Grund ist, dass es auf nativem UDP basiert
Ich frage mich, ob sich das später mit WebTransport umsetzen ließe
Es löst allerdings das NAT-Traversal-Problem nicht
Ich beobachte auch aufmerksam den Fortschritt von Irohs QAD
Wenn alles gut zusammenpasst, könnte das ein viel magischeres Netzwerk ergeben
Ich frage mich, ob der nächste Schritt sein könnte, dass alle Tailscale-Clients automatisch Weiterleitungsanfragen annehmen, sodass sich das Mesh-Netzwerk ohne Unterbrechung selbst repariert
Entscheidend ist allerdings, ob man das Weiterleiten von fremdem Traffic erlauben will
Mit Tailscale lassen sich Verbindungen zwischen Diensten herstellen, aber ich frage mich, ob bei einem Tailscale-Ausfall auch die Kommunikation zwischen meinen eigenen Diensten unterbrochen wird
Eine Wiederverbindung war auch nicht möglich, weil kein Zugriff auf Tailscale bestand
Deshalb will ich jetzt headscale selbst aufsetzen
Dass selbst Geräte im lokalen LAN nicht mehr miteinander kommunizieren konnten, war schon ziemlich absurd
Ich habe das ganze Wochenende über eine Behelfslösung für einen Kubernetes Operator gebaut, und jetzt kann ich sie dank dieses Features wieder komplett entfernen
Wirklich bravo
Ich habe mich gefragt, was der Anwendungsfall für dieses Feature ist
Es wirkt so, als wäre es dafür gedacht, dass ein SaaS-Produkt Daten aus dem System eines Kunden benötigt und der Kunde diese zur Integration über ein Relay zugänglich macht
Trotzdem dürfte man wohl weiterhin Software für Authentifizierung, Logging usw. brauchen
Weil NAT-Umgehung oft nicht möglich ist, wird DERP häufig verwendet, ist aber langsam
Jetzt kann man innerhalb des Netzwerks einen Peer mit guter Konnektivität als Relay festlegen und es dadurch schneller machen
Es ist weniger ein neuer Anwendungsfall als vielmehr eine Performance-Verbesserung des bisherigen DERP
Statt einer traditionellen Hub-and-Spoke-Struktur setzt es möglichst auf eine P2P-Architektur, bei der alle Knoten direkt über UDP/IP verbunden werden
Wegen NAT und Firewalls sind direkte Verbindungen jedoch oft nicht möglich, und dann vermittelt DERP
DERP war langsam, und Nutzer konnten die Performance kaum verbessern, aber mit dem neuen Peer Relay kann man nun eigene Relays betreiben
Wenn man deren Standort gut wählt, lässt sich auch die Latenz senken
Natürlich ist das nicht ein Feature, das jeder braucht