Headscale – Open-Source-Implementierung eines selbst gehosteten Tailscale-Kontrollservers
(github.com/juanfont)- Headscale ist ein Projekt, das den Tailscale-Kontrollserver als Open-Source- und Self-Hosting-Implementierung bereitstellt und sich an Self-Hoster sowie Hobbyentwickler mit Projekt- und Lab-Umgebungen richtet
- Tailscale ist ein modernes, auf WireGuard basierendes VPN und arbeitet mithilfe von NAT Traversal wie ein Overlay-Netzwerk zwischen Computern in einem Netzwerk
- Der Tailscale-Kontrollserver übernimmt den Austausch öffentlicher WireGuard-Schlüssel zwischen Nodes, die Zuweisung von Client-IP-Adressen, die Bildung von Grenzen zwischen Nutzern, die Freigabe von Maschinen zwischen Nutzern und die Veröffentlichung von von Nodes beworbenen Routen
- Headscale bietet mit bewusst engem Umfang eine Implementierung für ein einzelnes Tailscale-Netzwerk (tailnet), die sich für den privaten Einsatz oder kleine Open-Source-Organisationen eignet
- Das Projekt ist nicht mit Tailscale Inc. verbunden und unterstützt oder empfiehlt den Einsatz von Reverse Proxy und Containern zum Betrieb nicht
Zweck und Umfang von Headscale
- Headscale zielt auf eine selbst hostbare Open-Source-Alternative zum Tailscale-Kontrollserver ab
- Zur Zielgruppe gehören Self-Hoster, Hobbyentwickler sowie Nutzer privater Projekte und Lab-Umgebungen
- Der Implementierungsumfang ist bewusst eng gefasst und bietet ein einzelnes tailnet
- Geeignet für den privaten Einsatz
- Auch geeignet für kleine Open-Source-Organisationen
Tailscale und die Rolle des Kontrollservers
- Tailscale ist ein modernes VPN, das auf WireGuard aufbaut
- Tailscale arbeitet zwischen Computern in einem Netzwerk wie ein Overlay-Netzwerk und nutzt NAT Traversal
- Bei Tailscale sind mit Ausnahme einiger GUI-Clients und des Kontrollservers alle Komponenten Open Source
- Die als Ausnahme genannten GUI-Clients sind Clients für proprietäre Betriebssysteme wie Windows und macOS/iOS
- Der Kontrollserver fungiert als Stelle für den Austausch öffentlicher WireGuard-Schlüssel zwischen den Nodes im Tailscale-Netzwerk
- Er weist Client-IP-Adressen zu
- Er erzeugt Grenzen zwischen Nutzern
- Er ermöglicht die Freigabe von Maschinen zwischen Nutzern
- Er veröffentlicht von Nodes beworbene Routen
- Ein Tailscale network, also tailnet, ist ein privates Netzwerk, das Tailscale einem einzelnen Nutzer oder einer Organisation zuweist
Hinweise zu Dokumentation und Versionen
- Um Beispielkonfigurationen passend zur verwendeten Release-Version zu sehen, sollte immer derselbe GitHub-Tag ausgewählt werden
- Der
main-Branch kann Änderungen enthalten, die noch nicht veröffentlicht wurden - Die Dokumentation wird für die stabile Version und die Entwicklungsversion bereitgestellt
- Die Funktionsübersicht ist in der Features-Dokumentation zu finden
- Der Support für Clients und Betriebssysteme ist in der Dokumentation zu Client- und Betriebssystemunterstützung beschrieben
Betrieb und Build
- Für den Betrieb von Headscale wird der Einsatz von Reverse Proxy und Containern weder unterstützt noch empfohlen
- Für die Ausführung wird auf die offizielle Dokumentation verwiesen
- Ein Modul für NixOS-Nutzer befindet sich im Verzeichnis
nix/ - Entwicklungs-Builds des
main-Branches werden als Container-Images und Binärdateien bereitgestellt- Details finden sich in der Dokumentation zu Development Builds
Projektbeziehungen und Beiträge
- Dieses Projekt ist nicht mit Tailscale Inc. verbunden
- Einer der aktiven Maintainer von Headscale ist bei Tailscale angestellt und kann während der Arbeitszeit zum Projekt beitragen
- Die Beiträge dieses Maintainers werden von anderen Maintainers geprüft
- Die Maintainers legen die Projektausrichtung gemeinsam nach dem Prinzip fest, ein nachhaltiges Projekt zu schaffen und zugleich die Community aus Self-Hostern, Power-Usern und Hobbyentwicklern zu unterstützen
- Beitragende sollten CONTRIBUTING.md lesen
Entwicklungsumgebung und Workflow
- Für Beiträge werden aktuelles Go und Buf benötigt
- Buf wird als Protobuf-Generator verwendet
- Für die Einrichtung der Entwicklungsumgebung wird die Nutzung von Nix empfohlen
nix developinstalliert die benötigten Werkzeuge und stellt eine Shell bereit- Dieser Weg stellt dieselbe Entwicklungsumgebung wie bei den Headscale-Maintainern sicher
- Go-Code wird mit
golangci-lintgelintet und mitgolinessowiegofumptformatiert- Die Zeilenbreite von
golinesist auf 88 gesetzt - Vor dem Commit werden
make lintundmake fmtempfohlen
- Die Zeilenbreite von
- Proto-Code wird mit
bufgelintet und mitclang-formatformatiert - Die Dokumentation wird mit
mdformatformatiert, Markdown-, YAML- und sonstige Dateien mitprettier - Bei Änderungen in
proto/muss die Generierung von Go-Code aus Protobuf erneut ausgeführt werden- Der Befehl lautet
make generate - Änderungen in
gen/sollten zur einfacheren Review in einen separaten Commit aufgenommen werden
- Der Befehl lautet
- Tests und Build werden jeweils mit
make testundmake buildausgeführt - Der empfohlene Workflow besteht darin, nach
nix developmake testundmake buildauszuführen- Wer Abhängigkeiten direkt verwaltet, kann Make unmittelbar verwenden
- Das Makefile warnt, wenn benötigte Werkzeuge fehlen, und schlägt die Ausführung von
nix developvor - Verfügbare Targets lassen sich mit
make helpanzeigen
1 Kommentare
Meinungen auf Hacker News
Alle paar Monate komme ich zu diesem Repository zurück, um zu prüfen, ob Tailnet lock endlich funktioniert und ob inzwischen jemand ein Security-Audit durchgeführt hat.
Leider scheint es bei beidem keine Fortschritte zu geben, und deshalb werde ich mir zunehmend unsicher, wie sehr ich dem als Kernkomponente meiner Infrastruktur vertrauen kann.
Die Prämisse von Tailscale SaaS ist, Tunnel zu erstellen, die Firewalls umgehen, und den Nutzern auf intuitive, integrierte Weise Kontrolle darüber zu geben, was über diese Tunnel geroutet wird.
Headscale scheint Firewall-Umgehung und fortgeschrittenes NAT-Traversal gut hinzubekommen, aber ich frage mich, ob es selbst genug Sicherheit bieten kann, um die gerade umgangene Sicherheit auszugleichen.
Wenn Nutzer nicht verstehen oder ablehnen können, was der Control-Server den Clients anweist, und es keinerlei Security-Audit des Servercodes gibt, wirkt das wie eine ziemlich gewagte Entscheidung.
Ich dachte, es sei eine Kontrollschicht über den grundlegenden Backend-Diensten von Tailscale; vermittelt es Verbindungen auf eine neue Art?
Ich nutze ZeroTier recht häufig, bin aber mit Tailscale nicht vertraut, daher ist das vielleicht eine offensichtliche Frage.
Wenn man an selbst gehosteten Orchestrierungsservern interessiert ist, ist auch Netbird einen Blick wert.
Es ist ein ähnliches Tool, der Server ist ebenfalls Open Source, und der selbst gehostete Control-Server kommt mit einer ordentlichen GUI sowie Funktionen der kostenpflichtigen Version.
https://netbird.io/knowledge-hub/tailscale-vs-netbird
Es wirkt robust, leistungsfähig und funktionsreich, aber Headscale im Self-Hosting ist deutlich einfacher und hat weniger Anforderungen.
Im Moment lasse ich Tailscale zwar weiterhin laufen, komme aber immer näher daran, es schrittweise abzulösen und vollständig auf Netbird umzusteigen.
Das zugehörige GitHub-Issue ist hier:
https://github.com/netbirdio/netbird/issues/1103
Es wäre gut, den Projektnamen Headscale in den Titel aufzunehmen.
Headscale ist ein Projekt, das schon mehrfach auf HN aufgetaucht ist.
Es wäre cool, wenn Headscale Peering/Föderation zwischen Instanzen unterstützen würde. Vielleicht nach der ACL-Überarbeitung.
Eines der Hauptprobleme sind Adresskonflikte.
Der Vorschlag lautet: ein reines IPv6-Overlay-Netzwerk im Unique-Local-Address-(ULA)-Bereich festlegen und die verbleibenden 121 Bit in die unteren 20 Bit für Geräteadressen (etwa 1 Million) und die oberen 101 Bit als Hash des öffentlichen Serverschlüssels aufteilen.
Dann könnte man den öffentlichen Schlüssel einer anderen Instanz hinzufügen, um zu föderieren, und die Kommunikation zwischen Nodes über Policies und ACLs verwalten.
Ich halte das für eine gute Idee, aber als ich sie 2023 vorbrachte, sagte der Maintainer kradalby, sie liege außerhalb des Scopes: https://github.com/juanfont/headscale/issues/1370
Ich nutze Headscale seit einem halben Jahr ohne Probleme.
Es ist so gut, dass ich mich frage, wie ich früher ohne ein Tailscale-Netzwerk gelebt habe.
Es ist für OpenBSD paketiert, und ich nutze dieses Paket als Server.
Ich mag Headscale und habe es gerade in Produktion genommen; es läuft sehr gut.
Für den Login verwenden wir eine Gmail-Domain, was den großen Vorteil hat, dass Nutzer ihre Geräte selbst registrieren können.
Beim früheren OpenVPN musste das Betriebsteam Zertifikate und Konfigurationen manuell weitergeben.
Der einzige Nachteil ist, dass Nutzer manchmal versehentlich den Tailscale-Login-Server statt des eigenen Servers verbinden und dann rätseln, warum sie nicht auf die Dienste zugreifen können.
Wir richten Dienste ein, die über Nutzergruppen zugänglich sind.
Wir verwenden noch eine ältere Headscale-Version, weil es Integrationen gibt, die auf die neue Control Plane portiert werden müssen.
Laut
headscale node list | wcsind es etwa 250 Nodes, die meisten davon Server.Mir gefällt nicht besonders, dass Tailscale auf magische Weise an Routing-Tabellen und Firewall-Regeln herumfummelt, aber insgesamt war das kein Problem und es hat recht gut funktioniert.
Mehrere Anwendungsfälle, zum Beispiel mobiler Zugriff oder die macOS-GUI, können Headscale nur nutzen, wenn der offizielle Tailscale-Client weiterhin die Möglichkeit behält, den Kontrollserver zu konfigurieren.
In dem Moment, in dem bei Tailscale der unvermeidliche Qualitätsabfall beginnt, wird diese Funktion verschwinden.
Ich bin derzeit ein sehr zufriedener Tailscale-Kunde, sage das aber aus der Erfahrung heraus, dass ich in der Vergangenheit mehrfach von anderen Firmen enttäuscht wurde, nachdem sie verkauft wurden oder ihnen das Venture-Kapital ausging.
Das klingt plausibel. Headscale wird vor allem von Homelab-Nutzern und kleinen Hobby-Anwendern verwendet und konkurriert nicht mit Pulsesecure, Cisco Anyconnect oder GlobalProtect, sondern mit selbst gehostetem OpenVPN oder WireGuard.
Es ist ein Weg, Tailscale Menschen nahezubringen, die in ihrer Freizeit gern neue Technik ausprobieren, aber die Kontrolle über ihre Infrastruktur nicht aufgeben wollen.
Diese Leute bringen dann Tailscale-Expertise und Begeisterung mit an ihren Arbeitsplatz.
Unternehmen haben meist wenig Lust, IT-Infrastruktur zu verwalten, sofern das nicht ihre Kernkompetenz ist.
Natürlich werden einige Unternehmen Headscale statt des eigentlichen Tailscale-Produkts wählen, aber angesichts von Unternehmensgröße und Beträgen dürfte das eine Minderheit sein.
Das ist eher eine Umsatzkostenposition und unterscheidet sich nicht groß von Facebook-Anzeigen oder Werbetafeln am Straßenrand im Silicon Valley.
Der Grund, warum wir Tailscale bei der Arbeit nicht nutzen können, ist, dass Traffic über Server geroutet wird, die wir nicht kontrollieren.
Ich würde Tailscale bei der Arbeit wirklich gern einsetzen, und es würde viele Probleme lösen.
Wenn wir Ports öffnen müssten, könnten wir damit leben, aber Traffic durch diesen Port zu tunneln, bereitet mir große Sorgen.
Sieht interessant aus. Ich frage mich, welchen Mehrwert es gegenüber einer WireGuard- + OpenWrt-Konfiguration bietet.
Sie unterliegen zentral verwalteten ACLs, und es funktioniert einfach.
Tailscale wird manchmal abwertend als „nur ein WireGuard-Orchestrator“ bezeichnet, tatsächlich ist es aber viel mehr als das.
Aus Produktsicht ist WireGuard lediglich ein Implementierungsdetail.
Ich habe mich früher für Netbird entschieden, weil mir die Headscale-UI zu rudimentär vorkam; vielleicht hat sich das in den letzten Jahren verbessert.
Es läuft auf unzähligen Clients, und auch meine Apple TVs sind mit dem Tailscale-Netzwerk verbunden.
Die Einrichtung dauerte etwa eine Minute, und sie können auch als Gateway dienen.
Mit Tailscale oder einem extern gehosteten Headscale lässt sich das so nutzen.
Ich frage mich, wie groß das Risiko ist, dass meine Geräte kompromittiert werden, wenn der Tailscale-Koordinationsserver kompromittiert wurde und Tailnet lock aktiviert ist.