Tailscale vs WireGuard: Was die Control Plane bringt und was die SSH-Lücken kosten

„Sollte ich nicht einfach reines WireGuard nehmen?“ Diese Frage taucht alle paar Monate in jedem Homelab- und Plattform-Team-Chat wieder auf. Diese Woche kam sie mit einem konkreten Anlass zurück. Am 24. Oktober veröffentlichte ein Forscher einen Bericht namens „Tailworm“ über Rechteausweitung über Tailscale SSH. Tailscale reagierte am 26. Oktober mit einem Untersuchungs-Update und lieferte danach Fixes in Version 1.104.4, zusammen mit vier Security Bulletins und einer ausführlichen Analyse. Ein paar Tage lang war die lauteste Meinung im Netz, dass die ganze Idee eines verwalteten Mesh-VPNs ein Fehler gewesen sei.

Diese Reaktion wirft zwei Dinge durcheinander. Tailscale ist kein Konkurrent von WireGuard. Es betreibt WireGuard. Was es hinzufügt, ist eine Control Plane: die Maschinerie, die Schlüssel verteilt, einen Weg durch NAT findet, Menschen auf Maschinen abbildet und eine Richtlinie durchsetzt. Keiner der Fehler vom Oktober lag im Tunnel. Sie lagen in einem Feature, das darauf aufsetzt. Die ehrliche Frage lautet also nicht „Tailscale oder WireGuard“, sondern: Wie viel dieser Control Plane brauchst du, wer soll sie betreiben, und wie viel zusätzlichen Code willst du dafür auf jedem Knoten als root laufen lassen?

Die kurze Antwort

• Nimm reines WireGuard, wenn die Topologie klein und stabil ist: ein paar Server mit öffentlicher IP, eine Standortkopplung oder Smartphones und Laptops, die sich in einen Router einwählen, den du kontrollierst. Du bekommst eine winzige, prüfbare Codebasis im Linux-Kernel und keinen Dritten im Pfad.
• Nimm Tailscale, wenn viele Geräte zwischen Netzen wechseln, hinter NAT sitzen, das du nicht kontrollierst, und mehr als einer Person gehören. Der Wert liegt darin, dass Hinzufügen, Entfernen und Einschränken von Zugriffen eine Richtlinienänderung wird statt eines Schlüssel-Jonglierens.
• Nimm Headscale oder NetBird, wenn du diese Control Plane willst, aber nicht auf fremden Servern.
• Behandle Tailscale SSH und Serve als eigene Entscheidungen. Es sind optionale Features mit eigener Angriffsfläche, und genau dort lagen die Lücken vom Oktober.

Was WireGuard ist und was es bewusst nicht ist

WireGuard ist ein VPN-Protokoll samt Implementierung, das auf Kleinheit ausgelegt ist. Statt verhandelbarer Cipher-Suites nutzt es einen festen Satz moderner Primitive: das Noise-Protokoll-Framework, Curve25519, ChaCha20-Poly1305, BLAKE2s, SipHash24 und HKDF. Das Projekt beschreibt sein Ziel als Codebasis, die „von einer einzelnen Person umfassend überprüfbar“ ist. Seit Version 5.6 aus dem Jahr 2020 ist es Teil des Linux-Kernels.

Die zentrale Idee heißt Cryptokey Routing. Jeder Peer ist ein öffentlicher Schlüssel mit einer Liste von AllowedIPs. Ausgehend funktioniert diese Liste wie eine Routing-Tabelle: Pakete an diese Adressen werden für diesen Schlüssel verschlüsselt. Eingehend wirkt sie wie eine Zugriffsliste: Ein mit diesem Schlüssel entschlüsseltes Paket wird nur akzeptiert, wenn seine Quelladresse in der Liste steht. Peers können zwischen Netzen wechseln, der Tunnel folgt ihnen.

Ebenso bewusst ist, was WireGuard nicht tut. Die eigene Dokumentation sagt, dass „alle Fragen der Schlüsselverteilung und verteilter Konfigurationen“ außerhalb des Projektumfangs liegen. Mit reinem WireGuard baust du Folgendes selbst:

• Schlüsselverteilung. Jeder Peer muss den öffentlichen Schlüssel jedes Peers kennen, mit dem er spricht. Ein vollständiges Mesh aus 20 Geräten sind 190 Peer-Beziehungen, die synchron bleiben müssen.
• Erreichbarkeit. Mindestens eine Seite jedes Tunnels braucht einen erreichbaren UDP-Endpunkt. Hat keine Seite einen, etwa weil beide hinter NAT oder Carrier-Grade-NAT sitzen, brauchst du eine Portweiterleitung oder einen Hub-Server mit öffentlicher IP.
• Entzug von Zugriffen. Jemanden zu entfernen heißt, seinen Schlüssel auf jedem Peer zu löschen, der ihm vertraut hat.
• Identität. WireGuard kennt Schlüssel, keine Menschen. Es gibt keinen Login, kein SSO und kein „dieser Laptop gehört Alice“.
• Namensauflösung. DNS bringst du selbst mit.

Für eine Handvoll Maschinen ist das alles nicht schwer. In Deutschland ist der häufigste Fall die FRITZ!Box: Sie unterstützt neben IPSec auch WireGuard, und Smartphones verbindest du per QR-Code. Der Haken liegt beim Anschluss. Viele Kabelanschlüsse und manche Glasfaseranschlüsse laufen mit DS-Lite, also ohne eigene öffentliche IPv4-Adresse, und dann ist die FRITZ!Box von unterwegs über IPv4 nicht direkt erreichbar. Genau an dieser Stelle beginnen Homelabs, über Tailscale nachzudenken.

Was Tailscale hinzufügt: eine Control Plane um den Tunnel

Tailscale trennt das System in zwei Ebenen.

Die Datenebene ist WireGuard. Die Implementierung von Tailscale basiert auf wireguard-go, der Userspace-Implementierung in Go, hinter einem TUN-Device. Pakete zwischen zwei Geräten sind Ende-zu-Ende mit WireGuard-Schlüsseln verschlüsselt, die das Gerät nie verlassen.

Die Control Plane ist das, was WireGuard weggelassen hat. Ein Koordinationsserver tauscht öffentliche Schlüssel zwischen Knoten aus, vergibt jedem Knoten eine stabile Adresse und verteilt die Richtlinie, die festlegt, welche Knoten miteinander sprechen dürfen. Darum herum liegen die Features, die man im Alltag bemerkt:

• NAT-Traversal. Clients versuchen hartnäckig, einen direkten UDP-Pfad aufzubauen, selbst wenn beide Seiten hinter NAT sitzen.
• Relays. Scheitert der direkte Pfad, läuft der Verkehr über DERP-Relays. Das Relay leitet Pakete weiter, die es nicht entschlüsseln kann, die Verbindung bleibt also Ende-zu-Ende verschlüsselt. Seit Februar 2026 sind Peer Relays allgemein verfügbar, also selbst betriebene Relays auf deinen eigenen Knoten mit höherem Durchsatz.
• Identität. Nutzer melden sich über einen Identity Provider an, Geräte gehören Nutzern oder Tags.
• Richtlinie. Eine Tailnet-Policy-Datei legt fest, wer was erreichen darf, und Änderungen kommen innerhalb von Sekunden bei den Clients an.
• MagicDNS und Extras wie Subnet-Router, Exit Nodes, Serve, Funnel und Tailscale SSH.

WireGuard ist ein Tunnel. Tailscale ist ein System für Schlüsselverteilung und Richtlinien, das zufällig WireGuard-Tunnel benutzt. Fast jeder Streit über die beiden ist in Wahrheit ein Streit darüber, ob du dieses System willst und ob du es selbst betreiben möchtest.

Das hat eine wichtige Folge für das Vertrauensmodell. Bei reinem WireGuard kann nur einen Peer hinzufügen, wer die Konfiguration bearbeitet. Bei Tailscale entscheidet der Koordinationsserver, welche öffentlichen Schlüssel deine Knoten akzeptieren. Tailscales Antwort auf „was, wenn die Control Plane kompromittiert ist“ heißt Tailnet Lock, seit 2025 allgemein verfügbar: Neue Knotenschlüssel müssen von vertrauenswürdigen Schlüsseln auf deinen eigenen Geräten signiert sein, bevor andere Knoten sie akzeptieren. Wenn dieses Bedrohungsmodell für dich zählt, schalte es ein. Standardmäßig ist es aus.

Ist Tailscale langsamer als WireGuard?

Die Intuition sagt ja: Kernel-Code sollte eine Userspace-Implementierung in Go schlagen. Die veröffentlichten Zahlen sagen, dass es so einfach nicht ist.

Tailscale hat zwei direkte Vergleiche mit Kernel-WireGuard veröffentlicht, beide auf demselben Paar Linux-Hosts. Im April 2023 (Version 1.40) wurde TCP mit iperf3 gemessen, nachdem wireguard-go Segmentierungs- und Empfangs-Offloads bekommen hatte. Im November 2023 (Version 1.54) folgten UDP und QUIC mit Microsofts secnetperf, nachdem diese Offloads auf UDP-Verkehr ausgeweitet wurden. Dafür ist ein Linux-Kernel ab 6.2 nötig:

Lies diese Zahlen mit drei Einschränkungen. Sie stammen vom Hersteller. Tailscale selbst schreibt, dass die AWS-Ergebnisse an eine Grenze von etwa 7 Gb/s im darunterliegenden Netz stießen, nicht an eine der Software. Und sie sind alt: Bis Oktober 2026 hat Tailscale keinen neueren direkten Vergleich mit Kernel-WireGuard veröffentlicht. Der jüngste Performance-Beitrag vom September 2026 beschreibt stattdessen schrittweise Arbeit: etwa 5 % mehr Tempo unter Linux und Android durch schlauere Paketpuffer, die mit 1.104 kommen, und Multi-Queue-Verarbeitung für Subnet-Router, App Connectors und Exit Nodes in einem späteren Release. Was die Zahlen zeigen: „Userspace heißt langsam“ stimmt auf einem modernen Linux-Host nicht mehr.

Was wirklich Durchsatz kostet, ist der Pfad, nicht die Implementierung. In einem Beitrag vom Januar 2026 maß ein Tailscale-Ingenieur von Delhi aus zu einem Homelab in Minnesota über dieselbe Internetleitung:

DERP-Server sind geteilt und gedrosselt, damit alle fair Zugang bekommen. Genau dort sehen Leute die Geschwindigkeiten, die sie nach „Tailscale langsam“ suchen lassen. Führe tailscale ping <gerät> aus: Steht in den Antworten via DERP, läuft deine Verbindung über ein Relay. Die Gegenmittel in dieser Reihenfolge: direkte Verbindungen ermöglichen (UDP offen lassen, doppeltes NAT vermeiden), ein Peer Relay auf einem Knoten mit erreichbarem UDP-Port einrichten, und auf Linux-Subnet-Routern und Exit Nodes einen Kernel ab 6.2 mit den ethtool-Einstellungen für UDP-GRO aus Tailscales Performance-Leitfaden nutzen. Der Wechsel zu reinem WireGuard hilft bei einer Relay-Verbindung nur deshalb, weil reines WireGuard dich ohnehin zu einem erreichbaren Endpunkt zwingt.

Die Tailscale-SSH-Sicherheitslücke: Was tatsächlich passiert ist

Tailscale SSH ist ein optionales Feature. Aktivierst du es auf einem Linux-Host (tailscale set --ssh), übernimmt der Tailscale-Daemon Port 22 auf der Tailscale-Adresse des Hosts und betreibt einen eigenen SSH-Server. Die Authentifizierung kommt aus dem WireGuard-Knotenschlüssel und der Tailnet-Richtlinie statt aus authorized_keys. Dein normaler sshd läuft auf anderen Adressen weiter.

Das Design ist bequem, hat aber eine scharfe Kante. Der Daemon läuft als root, also startet auch der SSH-Server darin als root und muss für jede Sitzung, jeden weitergeleiteten Socket und jeden Unterprozess korrekt auf den richtigen Nutzer herunterstufen. OpenSSH hat diese Grenze über Jahrzehnte mit Privilege Separation gehärtet. Die Funde vom Oktober waren Fehler genau an dieser Grenze.

Zeitlinie, nach Tailscales Untersuchungs-Update und dem Blogbeitrag vom 28. Oktober:

• 23. Oktober: Bedenken zu Tailscale SSH machen in sozialen Medien die Runde.
• 24. Oktober: Der „Tailworm“-Bericht erreicht Tailscale am Morgen; der Forscher veröffentlicht ihn zwei Stunden später.
• 26. Oktober: Untersuchungs-Update mit vorläufigen Empfehlungen: SSH-Richtlinien eng fassen und SSH-Forwarding abschalten, wenn du es nicht brauchst.
• Fix: Tailscale 1.104.4, mit den Security Bulletins TS-2026-014 bis TS-2026-017 und „architektonischen Schutzmaßnahmen“ gegen ganze Klassen ähnlicher Fehler.

Was die Bulletins sagen:

• TS-2026-014 (die schwerwiegende): Tailscale SSH prüfte Unix-Socket-Pfade nur nach Namen, öffnete sie aber als root. Über ssh -L, ssh -R und eine Race Condition konnte ein Peer mit erlaubtem Forwarding Sockets erreichen, die nur root gehören, etwa den Docker-Socket oder die lokale API von tailscaled. Betroffen sind Hosts mit Tailscale SSH und erlaubtem Forwarding. Die Weiterleitung läuft jetzt als authentifizierter Nutzer.
• TS-2026-015: Eine autorisierte SSH-Sitzung konnte den Speicher von tailscaled über Window-Change-Nachrichten und angehängte Umgebungsvariablen unbegrenzt wachsen lassen. Der folgende OOM-Kill reißt jede Tailscale-Verbindung auf dem Knoten ab.
• TS-2026-016: Tailscale Serve mit Unix-Socket-Backends ließ sich auf privilegierte Sockets einschließlich der lokalen API lenken, und zwar von jemandem, der Serve-Konfiguration schreiben oder einen Backend-Pfad gegen einen Symlink tauschen konnte. Das ist ein lokaler Angreifer, kein entfernter, die Wirkung war aber die komplette Übernahme des Knotens.
• TS-2026-017: Mit Serve über TLS und HTTP/2 konnten parallele Anfragen an zwei verschiedene Mounts gegenseitig die Tailscale-App-Capabilities-Werte erhalten. Betroffen waren nur Apps, die Nutzer anhand dieses Headers autorisieren.

Was es nicht war. Trotz des Namens war das kein sich selbst verbreitender Wurm. Die SSH-Funde setzten einen Angreifer voraus, der bereits einen Knoten kontrolliert, dem die Tailnet-Richtlinie SSH auf das Ziel erlaubt. Tailscale beschreibt die Wirkung als laterale Bewegung, begrenzt auf Verbindungen, die die Richtlinie ohnehin erlaubte. Das ist ein echtes Problem, denn „begrenzt auf das, was die Richtlinie erlaubt“ heißt oft „alle Server“. Remote Code Execution aus dem Internet ist es aber nicht. Der Bericht enthielt außerdem fünf Funde zu Serve und Funnel: Drei waren echte Fehler und sind in 1.104.4 behoben, die anderen beiden funktionieren laut Tailscale wie vorgesehen. Ein Fehler in Conn25, der noch unveröffentlichten nächsten Generation der App Connectors, hat Nutzer nie erreicht.

Wo es hineinpasst. Es waren nicht die ersten Tailscale-SSH-Bulletins 2026. Im Juni behob TS-2026-004 eine Symlink-Umgehung bei der Unix-Socket-Weiterleitung, und TS-2026-006 einen Fall, in dem die UID 0@host an autogroup:nonroot vorbeikam. Im Juli behob TS-2026-009 einen Nutzernamen -i, der so an getent übergeben wurde, dass eine root-Sitzung entstand, und TS-2026-010 acceptEnv-Werte, die in Prozess-Kommandozeilen und Logs sichtbar waren. Serve hatte seine eigene Serie: TS-2026-005 ließ einen Nicht-root-Operator privilegierte Sockets proxen, und mit TS-2026-008 konnte eine einzige fehlerhafte Anfrage einen CPU-Kern dauerhaft auslasten, bei aktivem Funnel sogar aus dem ganzen Internet. Verschiedene Fehler, ein Thema: Features in einem root-Daemon tragen eine große, subtile Rechtegrenze.

Keines der Tailscale-SSH-Bulletins von 2026 betraf WireGuard, den Schlüsselaustausch oder den Tunnel. Jedes lag in einem Feature darüber. Das ist die nützlichste Lehre des Vorfalls für die Frage Tailscale vs WireGuard: Die Angriffsfläche ist nicht das VPN, sondern alles, was du drumherum einschaltest.

Was tun, wenn du Tailscale SSH nutzt

1. Aktualisiere jeden Knoten auf 1.104.4 oder neuer. Tailscale SSH ist serverseitiger Code, der Fix muss also auf den Hosts landen, auf die du dich verbindest.
2. Brauchst du keine Port- oder Socket-Weiterleitung, schalte sie ab. Tailscales Mitigation ist die Umgebungsvariable TS_SSH_DISABLE_FORWARDING=1 für tailscaled, gefolgt von einem Neustart. Sie schaltet nur das Forwarding ab, nicht Tailscale SSH. Bei Linux-Paketen, die /etc/default/tailscaled lesen:

echo 'TS_SSH_DISABLE_FORWARDING=1' | sudo tee -a /etc/default/tailscaled
sudo systemctl restart tailscaled
tailscale version   # sollte 1.104.4 oder neuer zeigen

3. Verschärfe den ssh-Abschnitt der Policy-Datei. Nenne Nutzer explizit, statt auf geteilten Hosts autogroup:nonroot zu erlauben, und stelle root und Produktion hinter den Check-Modus, der einen frischen Login beim Identity Provider erzwingt:

{
  // Auszug: groups, tagOwners und grants weggelassen. Die Policy-Datei ist HuJSON, Kommentare sind erlaubt.
  "ssh": [
    {
      "action": "accept",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self"],
      "users": ["autogroup:nonroot"]
    },
    {
      "action": "check",
      "src": ["group:sre"],
      "dst": ["tag:prod"],
      "users": ["deploy"],
      "checkPeriod": "1h"
    }
  ]
}

4. Oder behalte Tailscale fürs Netz und nimm OpenSSH für die Shell. Tailscales eigene Dokumentation sagt, dass Tailscale SSH für Mehrbenutzer-Maschinen oder für Client-Maschinen mit nicht vertrauenswürdigem Code eventuell nicht passt, weil dort jeder lokale OS-Nutzer ohne SSH-Schlüssel Tailscale-SSH-Verbindungen öffnen kann. Ebenso steht dort, dass du stattdessen einfach einen normalen SSH-Server über das Tailnet betreiben kannst. Du behältst das private Netz und verlierst nur den schlüssellosen Login. Tailscale selbst empfiehlt nicht, Tailscale SSH überall abzuschalten. Für geteilte oder besonders wertvolle Hosts ist die langweilige Variante trotzdem eine vernünftige.

Ist Tailscale sicher, kostenlos und Open Source?

Ist Tailscale ein VPN? Ja, aber nicht die Art, an die die meisten denken. Ein klassisches VPN schickt deinen Verkehr über den Server eines Anbieters. Tailscale baut ein privates Mesh zwischen deinen eigenen Geräten, und der Verkehr läuft direkt von Gerät zu Gerät, sobald es einen direkten Pfad gibt. Über eine andere Maschine ins Internet geht er nur, wenn du einen Exit Node wählst.

Ist Tailscale sicher? Die Kryptografie ist die von WireGuard, und die Server von Tailscale haben nicht die privaten Schlüssel, um deinen Verkehr zu entschlüsseln. Das Risiko liegt woanders: im Koordinationsserver, dem du die Schlüsselverteilung anvertraust (Tailnet Lock nimmt dir den Großteil dieses Vertrauens ab), und in den optionalen Features, die auf deinen Knoten mit root-Rechten laufen. Tailscale veröffentlicht seine Security Bulletins offen, auch die unangenehmen, und das ist ein gutes Zeichen. Zwei Voreinstellungen solltest du am ersten Tag ändern:

• Die Standardrichtlinie lässt jedes Gerät jedes andere auf jedem Port erreichen. Ersetze sie durch Grants, die abbilden, wer was erreichen soll.
• Der Client schickt Verbindungs-Logs an Tailscale, für den Support. Unter Linux schaltest du das mit TS_NO_LOGS_NO_SUPPORT=true in /etc/default/tailscaled ab, mit dem Preis, dass der Support dann weniger sieht.

Ist Tailscale kostenlos? Der Personal-Tarif kostet nichts für bis zu 6 Nutzer mit unbegrenzt vielen persönlichen Geräten. Das reicht für die meisten Homelabs und Familien. Teams zahlen 8 Dollar (Standard) oder 18 Dollar (Premium) pro Nutzer und Monat.

Ist Tailscale Open Source? Auf der Client-Seite größtenteils. Der Haupt-Client-Code steht unter BSD-3, die GUI-Clients für Windows, macOS und iOS sowie der Koordinationsserver sind aber proprietär. Wenn dir das wichtig ist, ersetzt Headscale den Koordinationsserver.

Tailscale vs WireGuard im direkten Vergleich

Wann reines WireGuard die richtige Antwort ist

• Die Topologie ist fest. Zwei Standorte, ein paar Cloud-VMs mit öffentlicher IP oder eine FRITZ!Box mit öffentlicher IPv4, in die sich alle einwählen. Einmal eingerichtet, selten angefasst.
• Du willst die kleinstmögliche vertrauenswürdige Codebasis. Ein Kernel-Modul, das für die Prüfung durch eine einzelne Person gebaut wurde, ist ein ganz anderes Audit-Ziel als ein funktionsreicher Daemon.
• Ein externer Koordinationsdienst ist nicht erlaubt. Regulierte oder abgeschottete Umgebungen können oft keine externe Control Plane akzeptieren, auch wenn sie nie Nutzdaten sieht.
• Du betreibst ohnehin Infrastructure as Code. Kommen die Peers sowieso aus Terraform oder Ansible, ist Schlüsselverteilung nur ein weiteres Template.

Reines WireGuard steckt auch in vielen Projekten, die du schon nutzt: Kubernetes-CNIs wie Cilium und Calico verschlüsseln Pod-Traffic beide mit WireGuard. Dort ist das CNI die Control Plane.

Wann sich Tailscale lohnt, vom Team bis zum Homelab

• Geräte wandern und sitzen hinter NAT, das du nicht kontrollierst. Laptops im Hotel-WLAN, Smartphones im Mobilfunk, ein Raspberry Pi hinter DS-Lite. Genau hier wird handgemachtes WireGuard zu Portweiterleitungen und einem Hub-Server.
• Mehr als eine Person braucht Zugriff, mit unterschiedlichen Rechten. Eine an Identitäten gebundene Richtlinie schlägt eine Tabelle voller öffentlicher Schlüssel.
• Offboarding muss schnell gehen. Einen Nutzer entfernen oder eine Regel einschränken wirkt an einer Stelle auf alle Geräte, und bei Tailscale SSH endet damit auch jede bereits offene Sitzung.
• Homelabs mit vielen Diensten. Proxmox, TrueNAS, Home Assistant und ähnliche Setups sind der Ort, an dem die Frage „Tailscale oder WireGuard fürs Homelab“ meist entsteht. Bist du der einzige Nutzer und hat dein Router eine öffentliche IP, reicht WireGuard auf dem Router. Teilst du Zugriff mit Familie oder Freunden oder hängt dein Anschluss hinter DS-Lite oder CGNAT, nimmt dir der kostenlose Tarif von Tailscale viel Arbeit ab.

Selbst gehostete Tailscale-Alternativen: Headscale und NetBird

Wenn der Einwand gegen Tailscale die gehostete Control Plane ist und nicht der Client, gibt es zwei etablierte Optionen.

Headscale ist eine quelloffene, BSD-3-lizenzierte Implementierung des Tailscale-Koordinationsservers. Du nutzt weiter die offiziellen Tailscale-Clients und richtest sie auf deinen eigenen Server aus. Der Umfang ist bewusst eng: ein einzelnes Tailnet, gedacht für private Nutzung oder eine kleine Open-Source-Organisation. Das Projekt gehört nicht zu Tailscale Inc., auch wenn einer der Maintainer dort arbeitet. Es ist beliebt, mit rund 45.000 GitHub-Sternen. Beachte, was es nicht ändert: Der Daemon auf jedem Gerät ist weiterhin der von Tailscale, Fehler in Tailscale SSH betreffen dich also weiterhin, wenn du das Feature aktivierst. Betreibst du Headscale mit SSO, passt ein quelloffener Identity Provider wie Keycloak, das überhaupt keinen bezahlten Tarif hat, gut dazu.

NetBird ist ein eigenständiges, WireGuard-basiertes Mesh der NetBird GmbH aus Berlin und damit die naheliegende Antwort auf die Suche nach einer Tailscale-Alternative aus Europa. Es nutzt Kernel-WireGuard, wo verfügbar, ICE und STUN für NAT-Traversal und Relays als Fallback. Der Client steht unter BSD-3, die Management-, Signal- und Relay-Dienste unter AGPLv3, und der gesamte Stack lässt sich auf einer kleinen VM mit eigener Domain selbst hosten. Die gehostete Version ist für bis zu 5 Nutzer und 100 Maschinen kostenlos, bezahlte Tarife kosten 6 und 12 Euro pro Nutzer und Monat. Für europäische Teams, die einen Anbieter unter EU-Recht wollen, ist das ein spürbarer Unterschied. NetBird bietet ebenfalls SSH-Zugriff mit zentralen Richtlinien und bringt damit dieselbe Klasse von Rechtegrenze zurück, also prüfe es mit derselben Sorgfalt.

ZeroTier und Cloudflare Tunnel tauchen in denselben Suchen auf, lösen aber andere Probleme. ZeroTier nutzt ein eigenes Protokoll statt WireGuard. Cloudflare Tunnel veröffentlicht Dienste über das Netz von Cloudflare, statt ein Mesh zwischen Geräten aufzubauen.

So startest du mit jeder Variante

Die ersten zehn Minuten sehen sehr unterschiedlich aus, und genau dieser Unterschied ist der Vergleich im Kleinen.

Reines WireGuard (Linux, ein Server mit öffentlicher IP, ein Laptop). Erzeuge auf jeder Maschine ein Schlüsselpaar und schreibe dann pro Seite eine Konfiguration:

wg genkey | tee privatekey | wg pubkey > publickey

# /etc/wireguard/wg0.conf auf dem Laptop
[Interface]
PrivateKey = <privater Schlüssel des Laptops>
Address = 10.8.0.2/32

[Peer]
PublicKey = <öffentlicher Schlüssel des Servers>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.8.0.0/24
PersistentKeepalive = 25

Die Server-Konfiguration spiegelt das mit ListenPort = 51820, einer eigenen Adresse und einem [Peer]-Block für den Laptop mit AllowedIPs = 10.8.0.2/32. Öffne UDP 51820 in der Firewall des Servers, starte auf beiden Seiten sudo wg-quick up wg0 und prüfe mit sudo wg show, ob ein aktueller Handshake da ist. Auf der FRITZ!Box erledigt die Oberfläche diese Schritte für dich, inklusive QR-Code fürs Smartphone. Jedes neue Gerät wiederholt das, und jedes Entfernen heißt, den Server zu bearbeiten.

Tailscale. Client installieren und über deinen Identity Provider anmelden:

curl -fsSL https://tailscale.com/install.sh | sh   # oder die Distributionspakete nutzen
sudo tailscale up
tailscale status

Dann folgen die zwei Schritte, die die meisten Anleitungen auslassen: die Allow-all-Standardrichtlinie durch Grants ersetzen und pro Host entscheiden, ob du Tailscale SSH überhaupt willst. Geräteschlüssel laufen absichtlich regelmäßig ab. Für Server kannst du das in der Admin-Konsole abschalten, Tailscale warnt aber, dass das die Sicherheit senkt. Tu es also nur für Maschinen, denen du vertraust.

Headscale. Den Server auf deiner eigenen VM betreiben und den normalen Tailscale-Client darauf zeigen lassen:

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

NetBird. Client installieren und mit NetBird Cloud verbinden oder beim Selbsthosten die eigene Management-URL angeben:

curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up                                  # öffnet den SSO-Login
netbird up --setup-key <KEY> --management-url https://netbird.example.com   # Server, selbst gehostet

Ein Installationsskript direkt in die Shell zu pipen ist bequem, aber nicht nötig. Tailscale und NetBird veröffentlichen beide signierte Paket-Repositories, die du auch selbst einbinden kannst.

Das Fazit

Tailscale und WireGuard wie Rivalen zu vergleichen, verdeckt die eigentliche Entscheidung. WireGuard ist ein hervorragender Tunnel, der bewusst beim Tunnel aufhört. Tailscale ist eine Control Plane, die diese Tunnel über viele Geräte und Menschen hinweg leicht anlegen, routen und entziehen lässt. Der Preis ist ein Koordinationsdienst eines Dritten und deutlich mehr privilegierter Code auf jeder Maschine.

Die Tailscale-SSH-Lücken vom Oktober machen diesen Preis greifbar, ohne die Kernantwort zu ändern. Der Tunnel hielt. Das Feature darüber nicht, und es wurde innerhalb weniger Tage nach dem Bericht behoben. Wenn du Tailscale nutzt, aktualisiere auf 1.104.4, halte SSH-Richtlinien eng und schalte nur die Features ein, die du brauchst. Ist deine Topologie klein und stabil, bleibt reines WireGuard die einfachste sichere Option. Und wenn du den Komfort ohne gehostete Control Plane willst, sind Headscale und NetBird reif genug, um sie ernst zu nehmen.

Für das größere Bild, wo private Konnektivität in einem Cloud-Fundament hingehört, siehe Was gehört in eine Cloud Landing Zone.