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 Ihnen die Control Plane tatsächlich bringt

Plain WireGuard bietet keine Dienstsuche. Jeder Peer besteht aus einem Textblock, den Sie manuell schreiben: einem öffentlichen Schlüssel, einer AllowedIPs-Zeile und einer Endpoint-Zeile, falls 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 ist fast jedes selbst gehostete WireGuard-Setup als Hub-and-Spoke aufgebaut: ein 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 Netzwerkverkehr läuft nie über den Koordinationsserver. Der Server überträgt Metadaten: welche Knoten vorhanden sind, welcher Schlüssel zu ihnen gehört und wer mit wem kommunizieren darf.

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. Dadurch erkennt jeder Router zuerst einen ausgehenden Datenstrom und akzeptiert die Antwort. Wenn das fehlschlägt, wird der Netzwerkverkehr über ein DERP-Relay geleitet, das von Tailscale betrieben wird und den Datenverkehr verschlüsselt weiterleitet. Ihre Daten bleiben auch über das Relay Ende-zu-Ende-verschlüsselt, weil das Relay die Schlüssel nie erhält. Führen Sie tailscale status aus. In jeder Peer-Zeile steht 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. Seit Juli 2026 beträgt die standardmäßige Ablaufdauer für ein neues Tailnet 180 Tage. Eine Maschine, die sich nicht erneut authentifiziert hat, kann keine Verbindung mehr herstellen. Für einen Server oder einen Subnetzrouter, an dem sich niemand anmelden wird, können Sie den Ablauf pro Gerät deaktivieren.

Richtlinien statt Routing. Bei Plain WireGuard ist AllowedIPs gleichzeitig die Routing-Tabelle und die Zugriffskontrollliste. Daher muss die Aussage „alice darf die Datenbank erreichen“ als IP-Adressbereich ausgedrückt werden. Tailscale verwendet eine separate Richtliniendatei, deren Regeln Benutzer, Gruppen und Tags benennen. Eine Regel kann festlegen, dass tag:laptop tag:db über Port 5432 erreichen darf und sonst nichts. Diese Regel bleibt auch dann gültig, wenn eine Maschine eine neue Adresse erhält.

Kosten der Control Plane

Der Koordinationsserver kennt Ihr Netzwerk. Er enthält den öffentlichen Schlüssel jedes Knotens, den Namen jedes Knotens, die zugewiesenen Adressen und die Richtlinie. Bei gehostetem Tailscale ist das ein Unternehmen außerhalb Ihrer Kontrolle. Das Unternehmen kann Ihre Pakete nicht lesen, weil die privaten WireGuard-Schlüssel auf Ihren Rechnern verbleiben. Es kann jedoch die Struktur Ihres Netzwerks sehen. Außerdem hängt Ihre Verbindungsfähigkeit davon ab, dass der Dienst verfügbar ist und Ihr Konto ordnungsgemäß geführt wird. Wie schwer diese Aspekte wiegen, hängt davon ab, was ein kompromittierter Koordinationsserver oder ein gestohlenes Identitätskonto mit den dort gespeicherten Informationen tatsächlich tun könnte. Deshalb lohnt sich eine vollständige Lektüre von Tailscales Vertrauensmodell.

Es gibt noch 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 wird und zusammen mit dem Kernel aktualisiert wird.

Der dritte Kostenfaktor ist die Abrechnung. Im Juli 2026 ist der Personal-Plan für bis zu 6 Benutzer mit unbegrenzt vielen Geräten kostenlos. Der Standard-Plan kostet $8 pro Benutzer und Monat. Der Premium-Plan kostet $18 pro Benutzer und Monat. Ein Haushalt bleibt kostenlos. Für ein Team mit zehn Personen gilt das nicht. Ob Sie diese Grenze überschreiten, hängt von der Anzahl der Benutzerkontingente und nicht von der Anzahl der Geräte ab. Lesen Sie daher was der kostenlose Plan tatsächlich abdeckt, bevor Sie den siebten Benutzer einladen.

Wann Plain WireGuard die richtige Wahl ist

Verwenden Sie Plain WireGuard, wenn die Topologie tatsächlich aus Hub und Spokes besteht. Ein VPS mit öffentlicher IP-Adresse, drei oder vier Geräte, die sich mit ihm verbinden, und keine Anforderung, dass diese Geräte untereinander kommunizieren können. Die Konfiguration passt auf einen Bildschirm. Es gibt keinen Daemon, den Sie aktualisieren müssen, kein Konto, das Sie verlieren können, und keinen externen Dienst zwischen Ihnen und Ihrem Server.

Plain WireGuard ist auch die richtige Wahl, wenn Sie die Grundlage verstehen möchten, auf der alles andere aufbaut. Eine WireGuard-VPN auf einem VPS selbst hosten erklärt die Schlüsselerzeugung, wg0.conf, IP-Weiterleitung, NAT und Fehler beim Handshake. Jeder dieser Mechanismen läuft weiterhin unter einem Tailnet. Wenn 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

Plain WireGuard wird unpraktisch, sobald jedes Gerät jedes andere Gerät erreichen muss. Ein vollständiges Mesh aus N Knoten benötigt N mal N minus 1 Peer-Blöcke. Bei sechs Geräten sind das dreißig Blöcke, die Sie manuell synchron halten müssen. Ein doppelter AllowedIPs-Eintrag leitet den Netzwerkverkehr unbemerkt von dem Peer um, der diesen Eintrag zuerst hatte. Eine Fehlermeldung wird dabei nirgends ausgegeben.

Wenn Tailscale die richtige Lösung ist

Verwenden Sie Tailscale, wenn sich die Geräte bewegen. Dazu gehören Laptops in Hotelnetzwerken, ein Telefon im Mobilfunknetz oder ein Heimserver hinter einem Router, den Sie nicht kontrollieren. Genau diese Fälle kann einfaches WireGuard nur schlecht abbilden, weil keine der beiden Seiten einen stabilen öffentlichen Endpunkt für Endpoint hat.

Die Installation des Clients erfolgt 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 eingebunden. 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, dessen Firewall Sie überhaupt nicht kontrollieren.

Danach erledigen zwei Einstellungen den größten Teil der wichtigen Aufgaben. Ein Subnet Router macht ein gesamtes LAN im Netzwerk verfügbar. 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 eigenstä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 genehmigt wirkende Route bleibt auf einem Linux-Laptop daher wirkungslos, 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 der Reihenfolge, die eine teilweise funktionsfähige Route verhindert.

Ein Exit Node leitet den gesamten Datenverkehr eines Clients über ein Gerät. Das ist das Verhalten eines vollständigen Tunnels, das üblicherweise mit „VPN“ gemeint ist:

sudo tailscale set --advertise-exit-node

Dieses Flag ist der einfache Teil. Einen VPS in einen Exit Node umwandeln beschreibt die anschließenden Schritte: Genehmigen Sie die Route in der Administrationskonsole und korrigieren Sie danach das DNS- und IPv6-Verhalten. Andernfalls kann der Datenverkehr den falschen Weg nehmen. Wenn Sie nicht ein gesamtes Netzwerk, sondern nur einen Webdienst 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 Koordinationsservers und läuft auf einem VPS, den Sie selbst betreiben. 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 Liste der Nodes, die Schlüssel und die Richtlinien in einer SQLite-Datei auf einem Datenträger liegen, den Sie selbst kontrollieren. Außenstehende können die Struktur Ihres Netzwerks nicht einsehen, Ihr Konto nicht deaktivieren und Ihnen keine Gebühren pro Benutzer berechnen.

Der damit verbundene Aufwand ist real. Sie betreiben nun 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 Koordinationsserver nicht erreichbar ist, können sich neue Nodes nicht registrieren und bestehende Nodes 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-Koordinationsserver betreiben behandelt die Installation, config.yaml, Preauth-Keys und die zu öffnenden Ports.

Ein Punkt wird oft erst spät bemerkt. Headscale verfügt nicht über Tailscales globales Relay-Netzwerk. Wenn zwei Peers keine direkte Verbindung herstellen können, müssen Sie entweder das integrierte Relay auf Ihrem eigenen Server aktivieren oder die Konfiguration auf ein anderes Relay verweisen. Dieses Relay ist dann ein einzelner Server in einer einzelnen Region und kein weltweites Netzwerk. Peers auf der anderen Seite des Planeten spüren diesen Unterschied. Wenn Sie diesen Teil nicht selbst einrichten möchten, ist NetBird selbst hosten die andere Möglichkeit, die Control Plane im eigenen Umfeld zu betreiben. Der Quickstart startet die Management-, Signal- und Relay-Dienste gemeinsam auf einem VPS.

So entscheiden Sie in einem Durchgang

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

Fragen Sie, ob die Rechner über stabile öffentliche Adressen verfügen. Wenn sich die meisten Rechner hinter NAT befinden, das Sie nicht kontrollieren, benötigen Sie eine Control Plane, weil Hole Punching der schwierige Teil ist und sich eine eigene Implementierung dafür nicht lohnt.

Fragen Sie, wer die Struktur Ihres Netzwerks kennen darf. Wenn externe Unternehmen ausgeschlossen sind oder die Abrechnung pro Benutzerkonto bei Ihrer Benutzerzahl problematisch wird, setzen Sie Headscale ein und akzeptieren Sie, dass Sie nun den Control Server betreiben. Wenn die Abrechnung der ausschlaggebende Faktor ist, führen Sie die Berechnung vor der Migration durch, denn was ein Team Ihrer Größe tatsächlich bezahlt hängt davon ab, wie viele Personen Benutzerkonten haben, nicht davon, wie viele Rechner Sie betreiben. Diese beiden Zahlen liegen nur selten nahe beieinander.

Sie können Ihre Entscheidung kostengünstig ändern. Da die Data Plane in allen drei Varianten dasselbe Protokoll verwendet, ist der Wechsel von einfachem WireGuard zu einem koordinierten Mesh lediglich eine Client-Installation und keine Neuentwicklung. 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 einfach WireGuard mit zusätzlichen Schritten?

Tailscale verwendet das WireGuard-Protokoll für den Datenpfad. Verschlüsselung und Tunnel sind daher identisch. Tailscale ergänzt eine Koordinationsebene: Schlüsselaustausch, Adresszuweisung, NAT-Traversal mit STUN und DERP-Relays, Ablaufzeiten für Schlüssel sowie eine Policy-Datei, in der Benutzer statt IP-Bereichen angegeben werden. Diese Aufgaben überlässt Ihnen plain WireGuard. Sie werden schwierig, sobald sich Geräte zwischen verschiedenen Netzwerken bewegen.

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

Normalerweise nicht. Peers verbinden sich direkt miteinander, sobald der Koordinationsserver sie einander bekannt gemacht hat. tailscale status zeigt in diesen Peer-Zeilen direct an. Kann kein direkter Pfad hergestellt werden, wird der Datenverkehr auf ein DERP-Relay umgeleitet. Die Zeile enthält dann relay. Auch in diesem Fall überträgt das Relay verschlüsselte Pakete. Es besitzt Ihre privaten WireGuard-Schlüssel nicht und kann daher deren Inhalt nicht lesen. Führen Sie tailscale netcheck aus, um zu prüfen, ob Ihr Netzwerk das UDP blockiert, das direkte Verbindungen benötigen.

Kann ich Headscale mit den offiziellen Tailscale-Apps verwenden?

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

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

Ein Tailscale-Client benötigt keinen eingehenden Port. Er baut eine ausgehende Verbindung zum Koordinationsserver auf und hält sie offen. Ein selbst gehosteter Headscale-Server benötigt dagegen eingehende Ports: 443 für das Steuerungsprotokoll, 80 bei Verwendung einer HTTP-01-Zertifikatsprüfung und 3478/udp nur bei aktiviertem integriertem Relay. Plain WireGuard benötigt seinen UDP-Listen-Port, normalerweise 51820. Dieser muss auf dem Server sowie in jeder separaten Netzwerk-Firewall Ihres Providers geöffnet sein.

Welche der drei Varianten ist am schnellsten?

Der Durchsatz ist identisch, weil alle drei Varianten Pakete mit WireGuard übertragen. Unterschiede zeigen sich beim Verbindungsaufbau und bei der Pfadqualität. Plain WireGuard stellt mit einem korrekten Endpoint jedes Mal eine direkte Verbindung her. Tailscale und Headscale stellen meistens eine direkte Verbindung her und verwenden ein Relay, wenn das Netzwerk Hole Punching blockiert. Ein Relay-Pfad erhöht die Latenz. Messen Sie Ihren eigenen Pfad mit tailscale ping <node>. Der Befehl zeigt, ob die Route direkt oder über ein Relay verläuft. Alternativ können Sie mit iperf3 über den Tunnel messen. Liegt dieser Wert bei einem direkten Pfad deutlich unter der Leitungsrate, ist nicht die Wahl zwischen den drei Varianten die Ursache. Die übliche Ursache ist eine nicht passende Pfad-MTU, die sich mit und ohne Steuerungsebene gleich auswirkt.