WireGuard, Tailscale oder Headscale: Was passt?

WireGuard vs Tailscale: die kurze Antwort

WireGuard vs Tailscale ist keine Wahl zwischen zwei Protokollen, weil Tailscale selbst WireGuard ist. Tailscale verwendet dieselbe Verschlüsselung und denselben Tunnel und ergänzt sie um eine Control Plane: einen Koordinationsserver, der öffentliche Schlüssel austauscht, Adressen verteilt, NAT (Network Address Translation) durchquert und eine Zugriffsrichtlinie anwendet. Sie entscheiden, wie viel dieser Koordination Sie selbst betreiben möchten.

Es gibt drei klare Antworten. Verwenden Sie plain WireGuard, wenn Sie einen Server und eine überschaubare Anzahl von Clients haben, die sich alle mit ihm verbinden. Verwenden Sie Tailscale, wenn jede Maschine jede andere Maschine erreichen soll, ohne dass Sie eine Konfigurationsdatei pflegen müssen. Verwenden Sie Headscale, wenn Sie dieses Mesh möchten, aber nicht wollen, dass ein Drittanbieter die Liste der Nodes verwaltet.

Was die Control Plane tatsächlich leistet

Plain WireGuard bietet keine Serviceerkennung. Jeder Peer besteht aus einem Textblock, den Sie manuell eintragen: einem öffentlichen Schlüssel, einer AllowedIPs-Zeile und einer Endpoint, wenn dieser Peer erreichbar ist. Wenn Sie eine Maschine zu einem Netzwerk mit zehn Maschinen hinzufügen, müssen Sie zehn Konfigurationsdateien bearbeiten, weil jede Seite den Schlüssel der jeweils anderen Seite benötigt. Deshalb verwendet fast jede selbst gehostete WireGuard-Umgebung eine Hub-and-Spoke-Topologie: einen Server mit öffentlicher IP-Adresse und Clients, die ausschließlich mit diesem Server kommunizieren.

Eine Control Plane macht diese Bearbeitung überflüssig. Jeder Knoten registriert sich einmal, erhält eine Adresse aus dem 100.64.0.0/10-CGNAT-Bereich (Carrier-Grade NAT) und bekommt die öffentlichen Schlüssel der Knoten mitgeteilt, die er erreichen darf. Der Tunnel bleibt eine direkte WireGuard-Verbindung zwischen zwei Peers. Ihr Datenverkehr läuft nie über den Koordinationsserver. Der Server überträgt Metadaten: welche Knoten vorhanden sind, welcher Schlüssel zu welchem Knoten gehört und welche Knoten miteinander kommunizieren dürfen.

Daraus ergeben sich drei konkrete Vorteile.

NAT-Traversierung. Zwei Laptops hinter zwei Heimroutern haben keine öffentliche IP-Adresse, über die sie direkt miteinander kommunizieren können. Tailscale verwendet STUN (Session Traversal Utilities for NAT), um die externe Adresse und den Port jeder Seite zu ermitteln. Anschließend senden beide Seiten gleichzeitig Pakete, sodass jeder Router zuerst einen ausgehenden Datenfluss erkennt und die Antwort akzeptiert. Wenn das fehlschlägt, wird der Datenverkehr auf ein DERP-Relay umgeleitet. Dabei handelt es sich um ein von Tailscale betriebenes verschlüsseltes Relay. Ihre Daten bleiben auch über das Relay Ende-zu-Ende-verschlüsselt, weil das Relay nicht über die Schlüssel verfügt. Führen Sie tailscale status aus. Jede Peer-Zeile enthält dann direct oder relay. Mit tailscale netcheck sehen Sie, welches Relay am nächsten liegt und ob Ihr Netzwerk UDP überhaupt zulässt.

Schlüsselrotation mit Ablaufdatum. WireGuard-Schlüssel laufen nie ab. Ein Schlüssel, den Sie vor drei Jahren erstellt haben, funktioniert dauerhaft, sofern Sie den Peer-Block nicht manuell löschen. Tailscale lässt Knotenschlüssel stattdessen ablaufen. Im Oktober 2026 beträgt der Standardzeitraum für ein neues Tailnet 180 Tage. Eine Maschine, die sich nicht erneut authentifiziert hat, stellt keine Verbindungen mehr her. Für einen Server oder einen Subnet Router, bei dem sich niemand anmelden wird, können Sie den Ablauf pro Gerät deaktivieren.

Richtlinien statt Routing. Bei Plain WireGuard ist AllowedIPs gleichzeitig die Routingtabelle und die Zugriffskontrollliste. Die Aussage „Alice darf die Datenbank erreichen“ muss daher als IP-Bereich formuliert werden. Tailscale verwendet eine separate Richtliniendatei, deren Regeln Benutzer, Gruppen und Tags benennen. Eine Regel kann festlegen, dass tag:laptop tag:db auf Port 5432 und nichts anderes erreichen darf. Diese Regel bleibt auch dann bestehen, wenn die Maschine eine neue Adresse erhält.

Die Kosten der Control Plane

Der Koordinationsserver kennt Ihr Netzwerk. Er speichert den öffentlichen Schlüssel jedes Knotens, jeden Knotennamen, die vergebenen Adressen und die Richtlinie. Bei gehostetem Tailscale ist das ein Unternehmen außerhalb Ihrer Kontrolle. Ihre Pakete kann das Unternehmen nicht lesen, weil die privaten WireGuard-Schlüssel auf Ihren Rechnern bleiben. Die Struktur Ihres Netzwerks kann es jedoch einsehen. Außerdem hängt Ihre Verbindungsfähigkeit davon ab, dass der Dienst verfügbar ist und Ihr Konto ordnungsgemäß geführt wird. Wie schwer dieser Aspekt wiegt, hängt davon ab, was ein kompromittierter Koordinationsserver oder ein gestohlenes Identitätskonto mit den dort gespeicherten Informationen tatsächlich anrichten könnte. Deshalb lohnt es sich, Tailscales Vertrauensmodell vollständig zu lesen.

Es gibt einen zweiten, leicht zu übersehenden Kostenfaktor. Tailscale läuft auf jedem Rechner als Daemon. Sie müssen diese Software daher auf jedem Rechner aktuell halten. Plain WireGuard unter Ubuntu 24.04 ist ein Kernelmodul, das mit der Distribution ausgeliefert und zusammen mit dem Kernel aktualisiert wird.

Der dritte Kostenfaktor ist die Abrechnung. Seit October 2026 ist der Personal-Plan für bis zu 6 Benutzer mit einer unbegrenzten Anzahl von Benutzergeräten kostenlos. Standard kostet $8 pro Benutzer und Monat. Premium kostet $18 pro Benutzer und Monat. Ein Haushalt bleibt damit kostenlos. Ein Team mit zehn Personen nicht. Ob Sie diese Grenze überschreiten, hängt hauptsächlich von der Anzahl der Benutzerplätze und nicht von der Anzahl der Geräte ab. Es gibt jedoch eine Ausnahme: Server und andere markierte Geräte haben ein eigenes Kontingent. Jeder Plan umfasst 50 markierte Ressourcen. Seit October 2026 nennt die Preisseite $1 pro Monat für jede weitere Ressource. Was der kostenlose Plan tatsächlich abdeckt sollten Sie lesen, bevor Sie den siebten Benutzer einladen oder den einundfünfzigsten Server markieren.

Wann reines WireGuard die richtige Wahl ist

Wählen Sie reines WireGuard, wenn die Topologie tatsächlich einem Hub-and-Spoke-Modell entspricht. Ein VPS mit öffentlicher IP, drei oder vier Geräte, die sich damit verbinden, und keine Anforderung, dass diese Geräte untereinander kommunizieren müssen. Die Konfiguration passt auf einen Bildschirm, es gibt keinen Daemon zu aktualisieren, kein Konto, das verloren gehen kann, und kein externer Dienst steht zwischen Ihnen und Ihrem Server.

Es ist auch die richtige Wahl, wenn Sie die Ebene verstehen möchten, auf der alles andere aufbaut. Self-hosting eines WireGuard-VPN auf einem VPS führt durch die Schlüsselgenerierung, wg0.conf, IP-Forwarding, NAT und die Handshake-Fehler. Die Schlüssel und der Handshake laufen weiterhin unter jedem Tailnet, und IP-Forwarding wird sofort relevant, sobald ein Tailnet-Knoten als Subnet-Router oder Exit-Node fungiert. Falls Sie noch die ältere Option abwägen, behandelt WireGuard vs OpenVPN die vier Fälle, in denen OpenVPN weiterhin Vorteile bietet.

Die Installation ist kurz:

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

Reines WireGuard wird dort unkomfortabel, wo jedes Gerät jedes andere Gerät erreichen muss. Ein Full-Mesh aus N Knoten erfordert N mal N minus eins Peer-Blöcke. Bei sechs Geräten sind das dreißig Blöcke, die manuell synchron gehalten werden müssen, und ein doppelter AllowedIPs-Eintrag entzieht dem Peer, der diesen Eintrag zuerst hatte, stillschweigend den Datenverkehr, ohne dass irgendwo eine Fehlermeldung ausgegeben wird.

Wenn Tailscale die richtige Lösung ist

Wählen Sie Tailscale, wenn sich die Geräte bewegen. Laptops in Hotelnetzwerken, ein Telefon mit Mobilfunkverbindung oder ein Heimserver hinter einem Router, den Sie nicht kontrollieren. Genau diese Fälle unterstützt reines WireGuard schlecht, weil keine der beiden Seiten einen stabilen öffentlichen Endpunkt für Endpoint hat.

Installieren Sie den Client mit einem Befehl aus dem offiziellen Installer:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

tailscale up gibt eine URL aus. Öffnen Sie sie, melden Sie sich an, und das Gerät wird dem Netzwerk hinzugefügt. Sie müssen keinen Schlüssel kopieren und keinen eingehenden Port öffnen, weil der Daemon eine ausgehende Verbindung zum Koordinationsserver herstellt und offen hält. Deshalb funktioniert ein Tailscale-Knoten auch in einem Netzwerk, in dem Sie keine Firewall kontrollieren.

Danach übernehmen zwei Einstellungen den größten Teil der wichtigen Aufgaben. Ein Subnet Router kündigt ein gesamtes LAN im Netzwerk an. Dadurch müssen Sie den Client nicht auf jedem Gerät installieren:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24

Die Route bleibt inaktiv, bis Sie sie in der Administrationskonsole genehmigen. Das ist beabsichtigt: Ein Knoten kann nicht selbstständig eine Route in Ihr Netzwerk einschleusen. Linux-Clients benötigen außerdem sudo tailscale set --accept-routes, weil Linux angekündigte Routen standardmäßig nicht akzeptiert. Eine serverseitig genehmigte Route hat auf einem Linux-Laptop daher trotzdem keine Wirkung, bis Sie diese Einstellung setzen. Wenn Sie genau dieses Szenario benötigen, beschreibt einen Subnet Router auf einem VPS betreiben den Genehmigungsschritt und die Weiterleitungseinstellungen in einer Reihenfolge, die eine nur teilweise funktionierende Route vermeidet.

Ein Exit Node leitet den normalen Internetverkehr eines Clients über ein Gerät. Gemeint ist damit sämtlicher Verkehr, der nicht bereits an ein anderes Gerät im Tailnet oder an eine genehmigte Subnet-Route gerichtet ist. Das entspricht dem vollständigen Tunnelbetrieb, den die meisten mit „VPN“ meinen. Unter Linux müssen Sie vor der Ankündigung dieselben IP-Forwarding-Einstellungen wie oben setzen:

sudo tailscale set --advertise-exit-node

Dieses Flag ist der einfache Teil. Einen VPS in einen Exit Node umwandeln behandelt die anschließenden Schritte: die Route in der Administrationskonsole genehmigen und anschließend das DNS- und IPv6-Verhalten korrigieren, das den Verkehr sonst über den falschen Weg ausleitet. Wenn Sie nur einen Webdienst und kein gesamtes Netzwerk erreichen möchten, stellt Serve und Funnel stattdessen HTTPS vor einen einzelnen lokalen Port. Der Zugriff kann dabei auf das Tailnet beschränkt oder für das öffentliche Internet geöffnet werden.

Wann Headscale die richtige Wahl ist

Headscale ist eine Open-Source-Implementierung des Koordinierungsservers und läuft auf einem VPS, den Sie selbst besitzen. Die offiziellen Tailscale-Clients verbinden sich damit statt mit dem gehosteten Dienst:

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

Am Datenpfad ändert sich nichts. Es bleibt bei WireGuard, und die Verbindungen laufen weiterhin direkt zwischen den Peers, sofern das Netzwerk dies zulässt. Geändert hat sich nur, dass die Knotenliste, die Schlüssel und die Richtlinie in einer SQLite-Datei auf einem Datenträger liegen, den Sie selbst besitzen. Niemand außerhalb kann die Struktur Ihres Netzwerks einsehen, Ihr Konto deaktivieren oder Ihnen Gebühren pro Benutzer berechnen.

Der Aufwand ist jedoch real. Sie betreiben jetzt einen öffentlich erreichbaren HTTPS-Dienst. Dafür benötigen Sie einen DNS-Namen, ein Zertifikat und einen Reverse Proxy, der WebSocket-Upgrades korrekt weiterleitet. Sie sind für seine Verfügbarkeit verantwortlich. Wenn der Koordinierungsserver ausfällt, können sich neue Knoten nicht registrieren und vorhandene Knoten keine Änderungen abrufen. Headscale ist außerdem noch vor Version 1.0, und seine Minor-Releases enthielten bereits inkompatible Änderungen. Lesen Sie daher vor jedem Upgrade das Changelog. Headscale als eigenen Tailscale-Kontrollserver betreiben behandelt die Installation, config.yaml, Preauth-Schlüssel und die zu öffnenden Ports.

Ein Punkt wird häufig erst spät bemerkt. Headscale verfügt nicht über Tailscales globales Relay-Netzwerk. Wenn zwei Peers keine direkte Verbindung herstellen können, aktivieren Sie entweder das integrierte Relay auf Ihrem eigenen Server oder verweisen in der Konfiguration auf ein anderes Relay. Dieses Relay ist dann eine einzelne Instanz in einer einzelnen Region und kein weltweites Netzwerk. Peers auf der anderen Seite des Planeten bemerken diesen Unterschied. Wenn Sie diesen Teil nicht selbst aufbauen möchten, ist NetBird selbst hosten eine weitere Möglichkeit, die Steuerung im eigenen Haus zu behalten. Der Quickstart startet die Management-, Signal- und Relay-Dienste gemeinsam auf einem VPS. NetBird ist allerdings nicht wie Headscale ein direkt einsetzbarer Tailscale-Server: Es verwendet eigene Clients und ein eigenes Richtlinienmodell. Lesen Sie daher wie sich NetBird und Tailscale bei Zugriffsregeln und Relays unterscheiden, bevor Sie sich anstelle von Headscale dafür entscheiden.

So entscheiden Sie in einem Durchgang

Fragen Sie, wie viele Rechner miteinander kommunizieren müssen. Wenn alle Rechner lediglich mit dem Server kommunizieren, ist plain WireGuard für dasselbe Ergebnis die Lösung mit weniger Software.

Fragen Sie, ob die Rechner über stabile öffentliche Adressen verfügen. Wenn sich die meisten hinter NAT befinden, das Sie nicht kontrollieren, benötigen Sie eine Control Plane. Der schwierige Teil ist Hole Punching. Das lohnt sich nicht, selbst neu zu entwickeln.

Fragen Sie, wer die Struktur Ihres Netzwerks kennen darf. Wenn externe Unternehmen ausgeschlossen sind oder die Anzahl Ihrer Benutzer eine Abrechnung pro Benutzer zu teuer macht, setzen Sie Headscale ein. Dabei müssen Sie den Control Server selbst betreiben. Wenn die Abrechnung den Ausschlag gibt, führen Sie die Berechnung vor der Migration durch. Was ein Team Ihrer Größe tatsächlich bezahlt hängt hauptsächlich davon ab, wie viele Personen Konten besitzen, und nicht davon, wie viele Rechner Sie betreiben. Das gilt, bis Ihre getaggten Server die 50 überschreiten, die in jedem Tarif enthalten sind. Diese beiden Zahlen liegen nur selten nahe beieinander.

Sie können Ihre Entscheidung mit geringem Aufwand ändern. Da die Data Plane in allen drei Varianten dasselbe Protokoll verwendet, besteht der Wechsel von plain WireGuard zu einem koordinierten Mesh lediglich aus der Installation des Clients und erfordert kein Redesign. Der Wechsel von Tailscale zu Headscale besteht darin, jeden Node erneut bei einem anderen Login Server zu registrieren.

Was keine der drei Lösungen bietet

Keine der drei Lösungen ist eine Firewall. Ein Tunnel legt fest, welche Pakete übertragen werden, nicht welche Dienste Verbindungen annehmen. Ein Server, der über den Tunnel erreichbar ist, bleibt aus dem Internet über jeden Port erreichbar, den Sie offengelassen haben. Halten Sie daher weiterhin die UFW-Firewall-Regeln auf dem VPS aktiv.

Die Policy-Datei von Tailscale schränkt ein, auf welche Ziele andere Knoten zugreifen dürfen. Für die öffentliche Schnittstelle hat sie keine Wirkung.

Keine der drei Lösungen bietet eine dienstbezogene Authentifizierung. Keine erstellt eine Audit-Spur der Aktionen eines Benutzers nach der Anmeldung. Betrachten Sie alle drei als Transportmechanismen. Die Anmeldeprüfungen gehören in die Anwendung.

FAQ

Ist Tailscale nur WireGuard mit zusätzlichen Schritten?

Tailscale nutzt das WireGuard-Protokoll für den Datenpfad, daher sind die Verschlüsselung und der Tunnel identisch. Was Tailscale hinzufügt, ist die Koordination: Schlüsselaustausch, Adressvergabe, NAT-Traversal mittels STUN- und DERP-Relays, Schlüsselablauf sowie eine Richtliniendatei, die Benutzer statt IP-Bereiche benennt. Das sind die Teile, die Ihnen reines WireGuard selbst überlässt und die schwierig werden, sobald sich Maschinen zwischen Netzwerken bewegen.

Läuft mein Datenverkehr über die Server von Tailscale?

Normalerweise nicht. Peers verbinden sich direkt miteinander, sobald der Koordinationsserver sie bekannt gemacht hat, und tailscale status zeigt direct in diesen Peer-Zeilen an. Wenn kein direkter Pfad hergestellt werden kann, greift der Datenverkehr auf ein DERP-Relay zurück und die Zeile zeigt relay an. Selbst dann überträgt das Relay nur verschlüsselte Pakete und besitzt nicht Ihre privaten WireGuard-Schlüssel, kann also den Inhalt nicht lesen. Führen Sie tailscale netcheck aus, um zu prüfen, ob Ihr Netzwerk das für direkte Verbindungen erforderliche UDP blockiert.

Kann ich Headscale mit den offiziellen Tailscale-Apps verwenden?

Ja. Headscale spricht dasselbe Kontrollprotokoll, daher verbinden sich die offiziellen Clients mit sudo tailscale up --login-server https://headscale.example.com. Desktop- und Mobil-Apps können ebenfalls auf einen benutzerdefinierten Login-Server verwiesen werden, wobei sich die Einstellung auf jeder Plattform an einer anderen Stelle befindet. Bei mobilen Apps ist am ehesten eine bestimmte Version erforderlich. Testen Sie ein Telefon, bevor Sie ein ganzes Netzwerk migrieren.

Muss ich für Tailscale oder Headscale weiterhin Ports öffnen?

Ein Tailscale-Client benötigt keinen eingehenden Port, da er sich zum Koordinationsserver verbindet und diese Verbindung offen hält. Ein selbst gehosteter Headscale-Server benötigt hingegen eingehende Ports: 443 für das Kontrollprotokoll, 80 bei Verwendung einer HTTP-01-Zertifikats-Challenge und 3478/udp nur, wenn Sie das integrierte Relay aktivieren. Reines WireGuard benötigt seinen UDP-Listen-Port, üblicherweise 51820, offen auf dem Server sowie auf jeder separaten Netzwerk-Firewall Ihres Anbieters.

Welche der drei Lösungen ist am schnellsten?

Der Durchsatz ist identisch, da alle drei Pakete mit WireGuard übertragen. Der Unterschied zeigt sich beim Verbindungsaufbau und bei der Pfadqualität. Reines WireGuard mit einem korrekten Endpoint verbindet sich jedes Mal direkt. Tailscale und Headscale verbinden sich meist direkt und weichen auf ein Relay aus, wenn das Netzwerk Hole-Punching blockiert; ein Relay-Pfad erhöht die Latenz. Messen Sie Ihren Pfad mit tailscale ping <node>, das anzeigt, ob die Route direkt oder über ein Relay verläuft, oder mit iperf3 über den Tunnel. Wenn dieser Wert bei einem direkten Pfad weit unter Ihrer Leitungsgeschwindigkeit liegt, liegt das Problem nicht an der Wahl zwischen diesen drei Optionen, sondern an der üblichen Ursache einer Pfad-MTU-Diskrepanz, die sich mit oder ohne Control Plane identisch verhält.