WireGuard, Tailscale oder Headscale: Was passt zum VPS?

WireGuard vs Tailscale: die kurze Antwort

WireGuard vs Tailscale ist keine Wahl zwischen zwei Protokollen, denn Tailscale ist WireGuard. Tailscale verwendet dieselbe Verschlüsselung und denselben Tunnel und ergänzt diese um eine Steuerungsebene: einen Koordinationsserver, der öffentliche Schlüssel austauscht, Adressen zuweist, Löcher durch NAT (network address translation) für Verbindungen öffnet und eine Zugriffsrichtlinie anwendet. Sie entscheiden, wie viel dieser Koordination Sie selbst betreiben möchten.

Es gibt drei klare Antworten. Verwenden Sie reines WireGuard, wenn Sie einen Server und eine kleine Anzahl von Clients haben, die sich alle mit diesem Server 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 Knoten verwaltet.

Was Ihnen die Control Plane tatsächlich bietet

Reines WireGuard bietet keine Erkennung. Jeder Peer besteht aus einem Textblock, den Sie manuell eintragen: einem öffentlichen Schlüssel, einer AllowedIPs-Zeile und einer Endpoint-Zeile, 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 ist fast jede selbst gehostete WireGuard-Installation als Hub-and-Spoke-Netzwerk aufgebaut: ein Server mit öffentlicher IP-Adresse und Clients, die ausschließlich mit ihm kommunizieren.

Eine Control Plane macht die 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, und Ihr Datenverkehr läuft niemals über den Koordinationsserver. Der Server überträgt Metadaten: welche Knoten vorhanden sind, welcher Schlüssel zu welchem Knoten gehört und wer mit wem kommunizieren darf.

Daraus ergeben sich drei konkrete Vorteile.

NAT-Traversal. Zwei Laptops hinter zwei Heimroutern haben keine öffentliche IP-Adresse, über die sie sich direkt erreichen 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 Datenfluss und akzeptiert die Antwort. Wenn das fehlschlägt, wird der Datenverkehr über ein DERP-Relay geleitet. 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 die Schlüssel nie besitzt. 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 ausgestellt haben, funktioniert unbegrenzt weiter, sofern Sie den Peer-Block nicht manuell löschen. Tailscale lässt stattdessen Knotenschlüssel 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 Verbindungen mehr herstellen. Für einen Server oder einen Subnetzrouter können Sie den Ablauf pro Gerät deaktivieren, wenn sich dort niemand zur Anmeldung aufhalten wird.

Richtlinien statt Routing. In reinem WireGuard ist AllowedIPs gleichzeitig die Routing-Tabelle und die Zugriffskontrollliste. Daher muss „Alice darf die Datenbank erreichen“ als IP-Bereich 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 und sonst nichts erreichen darf. Diese Regel bleibt auch dann bestehen, wenn die Maschine eine neue Adresse erhält.

Die Kosten der Steuerungsebene

Der Koordinierungsserver 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 gehört dieser Server einem Unternehmen außerhalb Ihrer Kontrolle. Das Unternehmen kann Ihre Pakete nicht lesen, weil die privaten WireGuard-Schlüssel auf Ihren Rechnern verbleiben. Die Struktur Ihres Netzwerks kann das Unternehmen jedoch einsehen. Außerdem hängt Ihre Verbindungsfähigkeit davon ab, dass dessen Dienst verfügbar ist und Ihr Konto ordnungsgemäß geführt wird.

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

Der dritte Kostenpunkt ist die Abrechnung. Im Juli 2026 ist der Personal-Tarif für bis zu 6 Benutzer mit einer unbegrenzten Anzahl von Geräten kostenlos. Standard kostet $8 pro Benutzer und Monat. Premium kostet $18 pro Benutzer und Monat. Ein Haushalt bleibt kostenlos. Ein Team mit zehn Personen nicht.

Wann plain WireGuard die richtige Wahl ist

Wählen Sie plain WireGuard, wenn die Topologie tatsächlich aus einem Hub und mehreren Speichen besteht. Ein VPS mit öffentlicher IP-Adresse, drei oder vier Geräte, die eine Verbindung zu ihm herstellen, und keine Anforderung, dass diese Geräte einander erreichen 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.

Es ist auch die richtige Wahl, wenn Sie die Ebene verstehen möchten, auf der alles andere aufbaut. Ein WireGuard-VPN auf einem VPS selbst hosten beschreibt die Generierung von Schlüsseln, 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, beschreibt 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 an dem Punkt unpraktisch, an dem jedes Gerät jedes andere Gerät erreichen muss. Ein vollständiges Mesh aus N Knoten benötigt N mal N minus eins 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 Datenverkehr unbemerkt von dem Peer weg, der diesen Eintrag zuerst hatte. Dabei wird nirgendwo ein Fehler ausgegeben.

Wann Tailscale die richtige Lösung ist

Wählen Sie Tailscale, wenn sich die Rechner bewegen. Laptops in Hotelnetzwerken, ein Telefon mit mobilen Daten oder ein Heimserver hinter einem Router, den Sie nicht kontrollieren. Genau diese Fälle unterstützt einfaches 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 Installationsprogramm:

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 der Rechner 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, in dem Sie keine Firewall kontrollieren.

Danach erledigen zwei Einstellungen den größten Teil der nützlichen Konfiguration. 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 selbst eine Route in Ihr Netzwerk einschleusen. Linux-Clients benötigen außerdem sudo tailscale set --accept-routes, weil Linux beworbene Routen standardmäßig nicht akzeptiert. Eine Route, die auf der Serverseite genehmigt aussieht, bleibt auf einem Linux-Laptop daher wirkungslos, bis Sie diese Einstellung setzen.

Ein Exit-Node leitet den gesamten Datenverkehr eines Clients über einen Rechner. Das entspricht dem vollständigen Tunnelbetrieb, der normalerweise mit „einem VPN“ gemeint ist:

sudo tailscale set --advertise-exit-node

Wann Headscale die richtige Lösung ist

Headscale ist eine Open-Source-Implementierung des Koordinationsservers 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 bei einer direkten Verbindung zwischen Peers, sofern das Netzwerk dies zulässt. Geändert hat sich, dass die Knotenliste, die Schlüssel und die Richtlinie in einer SQLite-Datei auf einer Festplatte liegen, die Sie selbst besitzen. Niemand außerhalb kann die Struktur Ihres Netzwerks sehen, Ihr Konto deaktivieren oder Ihnen Gebühren pro Benutzer berechnen.

Der dafür erforderliche Aufwand ist erheblich. Sie betreiben jetzt einen öffentlich erreichbaren HTTPS-Dienst. Dazu gehören ein DNS-Name, ein Zertifikat und ein Reverse-Proxy, der WebSocket-Upgrades korrekt weiterleitet. Sie sind für dessen Verfügbarkeit verantwortlich. Wenn der Koordinationsserver ausfällt, können sich neue Knoten nicht registrieren und vorhandene Knoten keine Änderungen abrufen. Headscale ist außerdem noch nicht bei Version 1.0, und seine Minor-Releases enthielten bereits inkompatible Änderungen. Lesen Sie deshalb vor jedem Upgrade das Changelog. Headscale als eigenen Tailscale-Steuerungsserver betreiben behandelt die Installation, config.yaml, Preauth-Schlüssel und die zu öffnenden Ports.

Ein Problem wird oft erst spät erkannt. 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 die Konfiguration auf ein anderes Relay. Dieses Relay ist dann eine einzelne Maschine in einer einzelnen Region und kein weltweiter Verbund. Peers auf der anderen Seite des Planeten spüren diesen Unterschied.

So entscheiden Sie in einem Durchgang

Fragen Sie, wie viele Computer miteinander kommunizieren müssen. Wenn alle nur mit dem Server kommunizieren, benötigt plain WireGuard für dasselbe Ergebnis weniger Software.

Fragen Sie, ob die Computer über stabile öffentliche Adressen verfügen. Wenn sich die meisten hinter NAT befinden, das Sie nicht kontrollieren, benötigen Sie eine Steuerebene. Das schwierige Problem ist dabei das Hole Punching. Es lohnt sich nicht, diese Funktion 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 unpraktisch macht, betreiben Sie Headscale selbst. Sie müssen dann auch den Steuerungsserver verwalten.

Sie können Ihre Entscheidung mit geringem Aufwand ändern. Da die Datenebene in allen drei Fällen dasselbe Protokoll verwendet, ist der Wechsel von plain WireGuard zu einem koordinierten Mesh die Installation eines Clients und keine Neuentwicklung. Der Wechsel von Tailscale zu Headscale besteht darin, jeden Knoten erneut bei einem anderen Anmeldeserver zu registrieren.

Was keines der drei Verfahren bietet

Keines davon ist eine Firewall. Ein Tunnel entscheidet, welche Pakete übertragen werden, nicht welche Dienste Verbindungen annehmen. Ein Server, der über den Tunnel erreichbar ist, bleibt aus dem Internet auf jedem Port erreichbar, den Sie offen gelassen haben. Lassen Sie daher weiterhin UFW-Firewallregeln auf dem VPS ihre Aufgabe erfüllen. Die Tailscale-Richtliniendatei schränkt ein, welche anderen Knoten den Server erreichen dürfen. Für die öffentliche Schnittstelle hat sie keine Wirkung.

Keines davon bietet eine Authentifizierung pro Dienst. Keines davon erstellt ein Auditprotokoll darüber, was ein Benutzer nach der Verbindung getan hat. Betrachten Sie alle drei als Transportmechanismen. Führen Sie die Anmeldeprüfungen in der Anwendung durch.

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 die Koordination: Schlüsselaustausch, Adresszuweisung, NAT-Traversal mit STUN und DERP-Relays, Ablauf von Schlüsseln sowie eine Richtliniendatei, in der Benutzer statt IP-Bereichen angegeben werden. Diese Aufgaben müssen Sie bei einfachem WireGuard selbst übernehmen. Sie werden schwierig, sobald sich Computer zwischen verschiedenen Netzwerken bewegen.

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

Normalerweise nicht. Peers verbinden sich direkt miteinander, sobald der Koordinationsserver sie miteinander bekannt gemacht hat. tailscale status zeigt bei diesen Peer-Zeilen direct an. Kann kein direkter Pfad hergestellt werden, wird der Netzwerkverkehr 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 den Inhalt daher 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 verwendet dasselbe Steuerungsprotokoll. Die offiziellen Clients verbinden sich daher mit sudo tailscale up --login-server https://headscale.example.com. Desktop- und mobile Apps können ebenfalls auf einen benutzerdefinierten Anmeldeserver 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 vollständiges Netzwerk migrieren.

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

Ein Tailscale-Client benötigt keinen eingehenden Port. Er baut die Verbindung zum Koordinationsserver ausgehend auf und hält sie offen. Ein selbst gehosteter Headscale-Server benötigt eingehende Ports: 443 für das Steuerungsprotokoll, 80 bei Verwendung einer HTTP-01-Zertifikatsprüfung und 3478/udp nur bei aktiviertem integrierten Relay. Einfaches WireGuard benötigt seinen UDP-Listen-Port, normalerweise 51820, auf dem Server. Der Port muss außerdem in jeder separaten Netzwerk-Firewall geöffnet sein, die Ihr Anbieter betreibt.

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. Einfaches WireGuard mit einem korrekt konfigurierten Endpoint verbindet sich immer direkt. Tailscale und Headscale verbinden sich meistens direkt 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 meldet, ob die Route direkt oder über ein Relay verläuft. Alternativ können Sie mit iperf3 den Durchsatz über den Tunnel messen.