Headscale selbst hosten auf einem dedizierten Server: Schritt für Schritt

Zuerst die Antwort: was Sie bauen

Ein kleiner Server mit Headscale (der Open-Source-Implementierung von Tailscales Koordinationsserver), bei dem die offiziellen Tailscale-Apps auf jedem Gerät auf diesen Server zeigen statt auf die Cloud von Tailscale. Dasselbe WireGuard-Mesh, dieselben Clients, dieselbe NAT-Traversal; die Control Plane (Schlüssel, Peer-Listen, ACLs) läuft auf Ihrer eigenen Hardware, ohne Kosten pro Nutzer. Der Aufbau dauert etwa eine halbe Stunde und braucht:

• Eine kleine Always-on-Linux-Maschine mit einer öffentlichen IP: Der Footprint von Headscale ist winzig; jeder bescheidene Server oder VPS-Slice reicht mehr als aus.
• Ein DNS-Name, der darauf zeigt (headscale.example.com, ersetzen Sie ihn durchgängig durch Ihren eigenen).
• Ports: 443 (oder der von Ihnen gewählte Port) für Clients; 80, wenn Sie den Standard-Let's-Encrypt-Ablauf nutzen; 3478/udp, wenn Sie das eingebettete Relay aktivieren.

Es lohnt sich, das aus unserem Vergleich der Mesh-VPNs zu wiederholen (wo diese Option den Platz "Tailscale-UX, selbst gehostete Kontrolle" gewann): Headscale ist bewusst auf ein einzelnes Tailnet begrenzt, ein Netzwerk, ein Team oder eine Organisation. Es ist die Self-Host-Antwort für private Infrastruktur und kleine Organisationen, kein Multi-Tenant-Klon von Tailscale für Unternehmen. Für diesen Umfang ist es exzellent.

Schritt 1: Installation

Der vom Projekt empfohlene Weg sind die offiziellen .deb-Pakete (Ubuntu 22.04+/Debian 12+), die den headscale-Benutzer, das Konfigurationsskelett und die systemd-Unit für Sie einrichten. Holen Sie sich die aktuelle Version (v0.29.x zum Zeitpunkt der Erstellung, prüfen Sie die Releases):

wget https://github.com/juanfont/headscale/releases/download/v0.29.2/headscale_0.29.2_linux_amd64.deb
apt install ./headscale_0.29.2_linux_amd64.deb

(Docker-Images existieren, aber das Projekt unterstützt Docker-Deployment ausdrücklich nicht offiziell; auf Ihrem eigenen Server ist das Paket sowohl einfacher als auch der unterstützte Weg.)

Schritt 2: Konfiguration

Alles befindet sich in /etc/headscale/config.yaml. Das minimale funktionierende Delta zum mitgelieferten Beispiel:

server_url: https://headscale.example.com:443
listen_addr: 0.0.0.0:443

# TLS, the simple way: built-in Let's Encrypt
tls_letsencrypt_hostname: headscale.example.com

Drei Entscheidungen, die es wert sind, bewusst getroffen zu werden:

• TLS: Die eingebaute Let's-Encrypt-Integration ist die Option mit den wenigsten beweglichen Teilen. Die standardmäßige HTTP-01-Challenge braucht einen erreichbaren Port 80; alternativ validiert TLS-ALPN-01 direkt auf 443. Ein Reverse Proxy (nginx/Caddy) davor funktioniert ebenfalls und ist verbreitet, aber beachten Sie den ehrlichen Hinweis in den Docs, dass die Reverse-Proxy-Anleitung von der Community gepflegt wird, WebSocket-Upgrades konfiguriert werden müssen und das Proxying über Cloudflare ausdrücklich nicht unterstützt wird. Weniger Schichten, weniger Überraschungen: direktes TLS ist hier die Empfehlung.
• Datenbank: SQLite ist die Standardeinstellung und in diesem Umfang die richtige Antwort, eine Datei unter /var/lib/headscale/db.sqlite.
• DNS: Der Abschnitt dns: gibt Ihrem Mesh MagicDNS-Namen (im Stil von base_domain: ts.example.com); legen Sie das jetzt fest, ein späteres Umbenennen ist lästig.

Danach:

systemctl enable --now headscale
headscale users create jesse

Schritt 3: Clients verbinden

Installieren Sie auf jedem Gerät die normale Tailscale-App und richten Sie sie auf Ihren Server aus:

tailscale up --login-server https://headscale.example.com

Der Befehl gibt eine URL aus; ruft man sie auf, erhält man den Node-Key, den Sie serverseitig genehmigen (headscale nodes register --user jesse --key <key>). Bei unbeaufsichtigten Maschinen (Servern, die dem Mesh beitreten) überspringen Sie den interaktiven Schritt mit einem Pre-Auth-Key:

headscale preauthkeys create --user jesse --expiration 1h
tailscale up --login-server https://headscale.example.com --authkey <key>

Headscale unterstützt die letzten zehn Tailscale-Client-Releases unter Linux, Windows, macOS, iOS und Android (mobile und Desktop-Plattformen brauchen einen kleinen zusätzlichen Schritt, um einen eigenen Server einzustellen; die Docs behandeln jede einzeln, und Ihr Server liefert sogar Hilfeseiten unter /windows und /apple). Sobald zwei Geräte dabei sind, führen Sie tailscale status aus und pingen zwischen ihnen: Sie haben ein Mesh.

Für SSO statt CLI-Benutzerverwaltung ist die OIDC-Unterstützung von Headscale solide: richten Sie sie auf Authentik, Keycloak, Entra ID oder Google aus (aktivieren Sie PKCE, wie von den Docs empfohlen), und die Geräteregistrierung wird zu einem Browser-Login.

Schritt 4: ACLs

Im Auslieferungszustand erreicht jeder Node jeden Node, gut für eine Person, nicht für ein Netzwerk mit Servern unterschiedlicher Sensibilität. Die Policy ist eine HuJSON-Datei (JSON mit Kommentaren), dasselbe Format wie bei Tailscale:

// /etc/headscale/policy.hujson
{
  "tagOwners": { "tag:server": ["jesse@"] },
  "acls": [
    // everyone reaches web things on servers
    { "action": "accept", "src": ["*"], "dst": ["tag:server:80,443"] },
    // only jesse reaches SSH anywhere
    { "action": "accept", "src": ["jesse@"], "dst": ["*:22"] }
  ]
}

Referenzieren Sie sie über policy.path in der Konfiguration und laden Sie den Dienst neu, um Änderungen zu übernehmen. Anmerkungen zum aktuellen Stand des Projekts: Die Policy-Engine ist v2 (Groups, Tags, Autogroups wie autogroup:internet für die Exit-Node-Steuerung), die neuere grants-Syntax ist die Richtung, in die sich das Projekt entwickelt, und eine ehrliche Lücke: OIDC-Groups können in Policy-Regeln noch nicht verwendet werden. Default-Deny-Denken gilt hier genau wie bei jeder Firewall: Schreiben Sie die Accepts, die Sie meinen, sonst nichts.

Schritt 5: Ihr eigenes DERP-Relay (optional, lohnt sich)

Wenn zwei Peers keine direkte Verbindung herstellen können (hartes NAT auf beiden Seiten, UDP blockiert), fällt der Datenverkehr auf ein DERP-Relay zurück. Standardmäßig bedeutet das die öffentliche Relay-Flotte von Tailscale: funktional, aber der eine Moment, in dem Ihr selbst gehostetes Mesh stillschweigend von der Infrastruktur eines anderen abhängt, mit welcher Latenz auch immer deren nächstgelegener Node liegt. Headscale bettet einen DERP-Server ein; ihn zu aktivieren hält gerelayten Datenverkehr auf Ihrer eigenen Maschine:

derp:
  server:
    enabled: true
    stun_listen_addr: "0.0.0.0:3478"

Öffnen Sie 3478/udp direkt zum Server (STUN kann nicht über einen Reverse Proxy laufen). Pakete, die über das Relay laufen, sind weiterhin Ende-zu-Ende WireGuard-verschlüsselt (DERP leitet nur Chiffretext weiter; es kann nichts lesen), der Gewinn liegt hier also bei Latenz und Eigenständigkeit, nicht bei Vertraulichkeit. In einem gut gepeerten Netzwerk ist der Unterschied spürbar: Ihr Worst-Case-Pfad ist dann ein Sprung über Ihren eigenen latenzarmen Server statt ein Umweg über ein entferntes öffentliches Relay.

Headscale betreiben

• Backups: Der gesamte Zustand besteht aus drei Dingen: /var/lib/headscale/ (Datenbank + Noise-Key), /etc/headscale/ (Config + Policy). Erstellen Sie Snapshots oder Datei-Backups davon; die Wiederherstellung auf einer frischen Maschine ist Kopieren-und-Starten.
• Upgrades: Lesen Sie den Changelog (das Projekt ist ehrlich bei Breaking Changes: v0.26 ersetzte die Policy-Engine; v0.29 änderte die Wildcard-Semantik), installieren Sie dann das neue .deb-Paket und starten Sie neu. Clients verbinden sich automatisch wieder.
• Ressourcen: Das Projekt veröffentlicht keine Sizing-Zahlen und muss das auch nicht; es koordiniert problemlos Hunderte Geräte auf minimaler Hardware. Der eine Skalierungshinweis der Maintainer: Die Kosten liegen in der CPU-gebundenen Neuberechnung der Map, wenn sich die Topologie ändert, es zählt also Anzahl und Fluktuation der Verbindungen, nicht der Traffic; Daten fließen Peer-to-Peer und nie über den Koordinationsserver (außer beim DERP-Fallback, siehe oben).
• Sichtbarkeit: Es gibt bewusst keine mitgelieferte Web-UI; die CLI deckt die Administration ab, und Drittanbieter-UIs (headscale-admin, Headplane und ähnliche) existieren als Community-Projekte; behandeln Sie sie auch so, und beachten Sie, dass manche die Policy im database-Modus voraussetzen.

Die ehrlichen Grenzen

Wählen Sie Headscale im Wissen, was es nicht ist. Ein einzelnes Tailnet: keine Multi-Tenancy, by Design und laut FAQ. Community-betrieben: Es ist eine unabhängige Open-Source-Neuimplementierung (historisch mit einem Tailscale-Mitarbeiter, der in persönlicher Eigenschaft beitrug), kein Vendor-Produkt mit einem SLA; neue Tailscale-Features kommen erst an, wenn sie neu implementiert wurden, nicht am Tag des Launches. Sie sind der Betreiber: TLS-Erneuerungen, Upgrades, Backups und der Pager um drei Uhr nachts liegen bei Ihnen. Lesen Sie diese Trade-offs eher als Kosten denn als den eigentlichen Sinn, dann ist Tailscales gehosteter Free Tier (oder NetBird, laut unserem Vergleich) das besser passende Werkzeug. Lesen Sie sie als Souveränität, machen Sie weiter; das ist eines der lohnendsten Self-Host-Projekte überhaupt: hoher Nutzen, minimaler Betriebsaufwand.

Häufig gestellte Fragen

Ist Headscale produktionsreif?

Für den vorgesehenen Anwendungsbereich (das Tailnet einer einzelnen Organisation, betrieben von jemandem, der mit dem Betrieb eines Linux-Dienstes vertraut ist) ja: Das Projekt ist ausgereift, wird aktiv veröffentlicht und wird genau dafür breit eingesetzt. Die Einschränkungen betreffen den Scope, nicht die Qualität: keine Multi-Tenancy, kein Vendor-Supportvertrag, und gelegentliche Breaking Changes zwischen Minor-Versionen, die einen Betreiber voraussetzen, der Changelogs liest. Setzen Sie es für eine Flotte Ihrer eigenen Server und Geräte ein, ist es solide; dehnen Sie es Richtung "Produkt für Kunden", verlassen Sie sein Design.

Warum verbinden sich meine Geräte, aber der Datenverkehr läuft langsam über den Server?

Sie sind auf DERP-Relaying zurückgefallen, meist erkennbar in tailscale status als Relay-Tag statt einer direkten Adresse. Direkte WireGuard-Pfade berühren Ihre Headscale-Box nie, wenn also "alles über den Server läuft", bedeutet das, dass NAT-Traversal fehlgeschlagen ist (hartes NAT, blockiertes UDP) und Pakete über das Relay laufen. Lösungen in dieser Reihenfolge: sicherstellen, dass UDP an keinem der beiden Enden blockiert ist, das eingebettete DERP aktivieren (damit der Fallback wenigstens Ihr eigenes schnelles Relay ist), und bei dauerhaft gerelayten Paaren prüfen, ob eine Seite einen direkten Port öffnen kann; ein dedizierter Server mit offenem UDP ist ein idealer, immer direkt erreichbarer Anchor-Node.

Kann ich mein Mesh nutzen, um das private Management-Netzwerk meiner Server zu erreichen?

Ja. Das ist genau der Betreiber-Anwendungsfall, den der Vergleichsartikel hervorgehoben hat. Betreiben Sie einen Node innerhalb des privaten Segments als Subnet-Router (tailscale up --advertise-routes=10.0.0.0/24 ..., genehmigt mit headscale nodes approve-routes), und autorisierte Mesh-Mitglieder erreichen das gesamte Segment (IPMI, interne Dienste), ohne dass irgendetwas davon einen öffentlichen Listener hat. Sichern Sie die Route hinter einer strikten ACL ab und behandeln Sie den Subnet-Router-Node mit der Sorgfalt einer Bastion; er ist jetzt die Brücke in Ihr sensibelstes Netzwerk.

Wie schneidet das im Vergleich zu einfach WireGuard betreiben ab?

Headscale ist im Kern WireGuard; was Sie hinzufügen, ist die Control Plane: automatische Schlüsselverteilung, NAT-Traversal, MagicDNS, ACLs und mobile Apps, die auch Nicht-Experten nutzen können. Für zwei statische Server bleibt reines WireGuard einfacher. Der Wendepunkt kommt mit roamenden Geräten, wachsenden Peer-Zahlen oder Menschen, die eine App mit einem Schalter verdienen; an diesem Punkt liefert Headscale das Produkterlebnis und behält dabei die Eigenschaft von reinem WireGuard, auf die es ankam: keine fremde Infrastruktur in Ihrem Control Path.

Deployment auf Serverside

Ein Headscale-Host will genau das, was ein kleiner dedizierter Server oder eine Cloud-Instance hier bietet: eine Always-on-Maschine mit einer stabilen öffentlichen IP in einem gut gepeerten Netzwerk (ASN 55285, wo Ihr eingebettetes DERP-Relay seinen Latenzvorteil auch wirklich einlöst) hinter permanenter DDoS-Mitigation, denn der eine öffentliche Listener Ihres Koordinationsservers verdient Schutz. Größere Meshes, die Subnet-Router in private Netzwerke verankern, passen von Natur aus zur dedizierten Leitung.

Passende Weiterlektüre: die Mesh-VPN-Entscheidung, die dieser Leitfaden konsequent zu Ende führt, Firewall-Regeln für den Host darunter, und die Hardening-Checkliste, die Sie vorher durchgehen sollten.