--- title: "Tailscale vs WireGuard: Was die Control Plane bringt und was die SSH-Lücken kosten" description: "Tailscale läuft auf WireGuard. Der eigentliche Vergleich ist also ein nackter Tunnel gegen einen Tunnel mit Control Plane. Was diese Control Plane bringt, was sie an Geschwindigkeit und Geld kostet und was die Tailscale-SSH-Lücken vom Oktober wirklich ändern." author: Aleksei Aleinikov date: 2026-10-28 lang: de tags: [tailscale vs wireguard, ist tailscale sicher, tailscale ssh sicherheitslücke, headscale vs tailscale, tailscale alternative europa, netbird vs tailscale, wireguard fritzbox] canonical: https://www.alekseialeinikov.com/de/blog/topics/security/tailscale-vs-wireguard-vergleich source: alekseialeinikov.com --- # 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?** ![Tailscale vs WireGuard: derselbe verschlüsselte WireGuard-Tunnel, einmal von Hand konfiguriert und einmal mit einer Control Plane, die Schlüssel verteilt, NAT überwindet und identitätsbasierte Richtlinien durchsetzt.](https://www.alekseialeinikov.com/blog/tailscale-vs-wireguard.webp) ## 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. ![Tailscale vs WireGuard Architektur: Bei WireGuard wird jeder Peer von Hand konfiguriert und braucht einen erreichbaren Endpunkt; bei Tailscale verteilt ein Koordinationsserver Schlüssel und Richtlinien, während der Verkehr direkt über WireGuard oder über ein DERP- oder Peer-Relay als Fallback läuft.](https://www.alekseialeinikov.com/blog/tailscale-vs-wireguard-architecture.webp "Der Tunnel ist identisch. Alles drumherum ist das Produkt.") > [!KEY] > 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: | Test, ein Datenstrom | wireguard-go (Standard) | Kernel-WireGuard | wireguard-go von Tailscale | |---|---|---|---| | TCP, Bare Metal (i5-12400, 25 GbE), Apr. 2023 | 8,36 Gb/s | 11,8 Gb/s | 13,0 Gb/s | | TCP, AWS c6i.8xlarge, Apr. 2023 | 5,34 Gb/s | 2,67 Gb/s | 7,32 Gb/s | | UDP/QUIC, Bare Metal, Nov. 2023 | 2,94 Gb/s | 5,42 Gb/s | 12,46 Gb/s | | UDP/QUIC, AWS c6i.8xlarge, Nov. 2023 | 2,20 Gb/s | 2,74 Gb/s | 7,21 Gb/s | 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: | Pfad | Durchsatz (iperf3, TCP) | |---|---| | Über ein DERP-Relay | 2,2 Mbit/s | | Über ein selbst betriebenes Peer Relay | 27,5 Mbit/s | | Reines Internet, ohne Tunnel | 31,1 Mbit/s | 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 ` 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. > [!KEY] > 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. ![Tailscale SSH Sicherheitslücke erklärt: Ein autorisierter Peer verbindet sich über WireGuard, die Tailnet-Richtlinie erlaubt SSH, und der root-eigene SSH-Server in tailscaled leitete Unix-Sockets als root weiter, wodurch Docker-Socket und lokale API offenlagen, bis Version 1.104.4 die Weiterleitung auf den authentifizierten Nutzer umstellte.](https://www.alekseialeinikov.com/blog/tailscale-vs-wireguard-ssh-boundary.webp "Der Tunnel hielt. Die Rechtegrenze im Daemon nicht.") ### 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: ```bash 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: ```json { // 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. > [!WARNING] > Entziehst du Zugriff in der Policy-Datei, beendet das auch bestehende Tailscale-SSH-Sitzungen innerhalb von Sekunden. Das ist ein echter Vorteil gegenüber `authorized_keys`, hilft aber nur, wenn die Richtlinie von Anfang an eng war. ## 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 | | **WireGuard** | **Tailscale** | |---|---|---| | **Was es ist** | Tunnel-Protokoll und Implementierung | WireGuard-Datenebene plus Koordinationsdienst | | **Datenpfad** | Kernel-Modul unter Linux | wireguard-go im Userspace, direkt oder über Relay | | **Schlüsselverteilung** | Manuell | Automatisch über den Koordinationsserver | | **NAT-Traversal** | Keins. Eine Seite braucht einen erreichbaren Endpunkt | Eingebaut, mit DERP- und Peer-Relay-Fallback | | **Identität** | Nur öffentliche Schlüssel | SSO-Nutzer, Geräte und Tags | | **Zugriffskontrolle** | `AllowedIPs` pro Peer | Zentrale Policy-Datei mit Grants und SSH-Regeln | | **Zugriff entziehen** | Schlüssel auf jedem Peer entfernen | Eine Änderung in Richtlinie oder Admin-Konsole | | **Lizenz** | GPLv2 im Kernel | Client-Code BSD-3; GUI-Clients für Windows, macOS und iOS sowie die Control Plane sind proprietär | | **Kosten** | Kostenlos | Kostenlos bis 6 Nutzer, danach 8 oder 18 Dollar pro Nutzer und Monat | | **Dritter im Pfad** | Keiner | Koordinationsserver und, falls genutzt, DERP-Relays | | **Code mit root-Rechten** | Ein kleines Kernel-Modul | Ein Daemon mit Netzwerk, DNS und optionalen SSH- und Serve-Features | ## 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](https://www.alekseialeinikov.com/de/blog/topics/devops/cilium-vs-calico-kubernetes-cni-vergleich). 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](https://www.alekseialeinikov.com/de/blog/topics/security/ist-keycloak-kostenlos-keycloak-vs-authentik-2026), 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. ![Tailscale vs WireGuard Entscheidungsbaum: Feste Topologie mit erreichbarem Endpunkt führt zu reinem WireGuard; mobile Geräte hinter NAT und mehrere Nutzer führen zu Tailscale; die Anforderung, die Control Plane selbst zu besitzen, führt zu Headscale oder NetBird; Tailscale SSH bleibt Opt-in für Einzelnutzer-Hosts mit enger Richtlinie.](https://www.alekseialeinikov.com/blog/tailscale-vs-wireguard-decision.webp "Die meisten Setups entscheiden sich an den ersten beiden Fragen.") ## 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: ```bash wg genkey | tee privatekey | wg pubkey > publickey ``` ```ini # /etc/wireguard/wg0.conf auf dem Laptop [Interface] PrivateKey = 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: ```bash 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: ```bash 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: ```bash curl -fsSL https://pkgs.netbird.io/install.sh | sh netbird up # öffnet den SSO-Login netbird up --setup-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](https://www.alekseialeinikov.com/de/blog/topics/cloud/was-gehoert-in-eine-cloud-landing-zone-2026).