Dein Homelab steht zu Hause, und du bist es nicht. Dazwischen sitzt ein Router, der völlig zu Recht nicht mit Fremden redet. Zwei Werkzeuge bringen dich hinein, ohne die Haustür für das ganze Internet offen zu lassen.
Kurz gesagt
WireGuard ist der Tunnel. Tailscale ist ein Dienst auf WireGuard-Basis, der Schlüsselverwaltung, Verbindungsaufbau durch NAT, Zugriffsregeln und Gerätenamen dazugibt [1][5]. Unsere Einschätzung: Nimm reines WireGuard, wenn du ein Gateway hast, das von außen erreichbar ist, nur wenige Geräte und keinen Dritten im Pfad willst. Nimm Tailscale, wenn dein Anschluss keine eingehenden Verbindungen zulässt, die Geräteliste wächst oder du Regeln pro Person und Gerät willst. Viele Homelabs nutzen am Ende beides. Keines von beiden ersetzt Updates und Logins an den Diensten dahinter.
So funktioniert’s
- Was WireGuard ist. WireGuard verpackt IP-Pakete verschlüsselt in UDP. Du legst eine Netzwerkschnittstelle an, gibst ihr deinen privaten Schlüssel und die öffentlichen Schlüssel deiner Gegenstellen und schickst Pakete hindurch. Schlüsselverteilung und das Ausrollen von Konfigurationen sind ausdrücklich nicht Teil des Projekts, ganz im Stil von SSH [1]. Die Kernidee heißt Cryptokey-Routing: Jede Gegenstelle hat einen öffentlichen Schlüssel und eine Liste von
AllowedIPs. Beim Senden wirkt die Liste wie eine Routing-Tabelle. Beim Empfangen wirkt sie wie eine Zugriffsliste, denn ein Paket dieser Gegenstelle mit einer anderen Absenderadresse wird verworfen [1]. Der Entwurf antwortet nicht auf unauthentifizierte Pakete, wodurch WireGuard laut Autor für Scanner unsichtbar bleibt [3]. - Was du selbst tust. Du erzeugst pro Gerät ein Schlüsselpaar. Die Kurzanleitung zeigt
umask 077und dannwg genkey | tee privatekey | wg pubkey > publickey[2]. Du schreibst pro Gerät eine Konfiguration, undwg-quick up wg0liest/etc/wireguard/wg0.confund richtet Schnittstelle und Routen ein.wg-quick down wg0baut sie wieder ab [4]. Außerdem musst du dafür sorgen, dass die Gegenstellen sich erreichen. WireGuard sichert den Verkehr zwischen zwei Geräten, sorgt aber nicht dafür, dass sie sich verbinden können. Eventuell brauchst du eine Portweiterleitung am Router, und ein Tunnel, der hinter NAT still bleibt, brauchtPersistentKeepalive, wofür die Kurzanleitung 25 Sekunden vorschlägt [2][5]. Jedes Gerätepaar braucht einen Eintrag, ein vollvermaschtes Netz wächst also quadratisch mit der Zahl der Geräte [5]. - Was Tailscale dazugibt. Du installierst den Client und meldest dich an. Danach verteilt Tailscale Schlüssel und Konfiguration [5]. Unter Linux sind das
curl -fsSL https://tailscale.com/install.sh | shund danachsudo tailscale up, das eine Anmelde-URL ausgibt [10]. Die Geräte bilden ein „Tailnet“. Tailscale versucht, sie direkt durch NAT zu verbinden, ohne Portweiterleitung, und leitet den verschlüsselten Verkehr über Relays, wenn das scheitert. Zwei Geräte im selben LAN sprechen lokal miteinander [5]. Die Datenebene ist WireGuard, und laut Tailscale verlassen die privaten Schlüssel nie das Gerät, sodass Tailscale den Verkehr nicht entschlüsseln kann [5]. - Relays und Firewalls. Die Relay-Server heißen DERP. Sie helfen beim Verbindungsaufbau und sind die letzte Rückfalllösung. Sie leiten Verkehr weiter, der schon verschlüsselt ist [6].
tailscale statuszeigt pro Gerät, ob die Verbindung „direct“ ist oder über ein „relay“ läuft [7]. Tailscale schreibt, dass du meistens keinen Firewall-Port öffnen musst. Erwartet werden ausgehend TCP 443, ausgehend UDP ab Quellport 41641 (Standard, änderbar) und ausgehend UDP 3478 für STUN [7]. - Geräte ohne Client erreichen. Ein Drucker oder die Weboberfläche eines NAS kann Tailscale nicht ausführen, aber ein Linux-Rechner daneben kann als Subnet Router arbeiten. Du schaltest IP-Weiterleitung ein, bewirbst die Route und bestätigst sie in der Admin-Konsole. Standardmäßig schreibt der Router die Absenderadresse um, der Verkehr hinter ihm erscheint also als Verkehr des Routers. Geräte hinter einem Subnet Router zählen nicht zum Gerätelimit eines Tarifs [8]. Ein Subnet Router ist kein Exit Node. Ein Exit Node schickt deinen Internetverkehr über diese Maschine, ein Subnet Router öffnet nur bestimmte private Netze [8].
- Namen und Regeln. Tailscale bietet MagicDNS-Namen und Zugriffsregeln, die du einmal für Nutzer, Gruppen und Tags schreibst [5]. Mit reinem WireGuard erreichst du dasselbe nur, indem du zwischen Geräten, die nicht miteinander reden sollen, keine Tunnel einrichtest, und mit der Firewall des Betriebssystems [5].
- Wem du vertraust. Bei Tailscale kann die Steuerungsebene Knoten hinzufügen und entfernen. Mit Tailnet Lock signieren deine eigenen vertrauenswürdigen Knoten neue Knoten, nach dem Prinzip „Trust on first use“. Zum Stand der letzten Prüfung der Seite am 2. Dez. 2025 gab es das in den Tarifen Personal und Enterprise [14]. Du kannst die Steuerungsebene auch selbst betreiben, mit Headscale, einer quelloffenen Neuimplementierung für ein einzelnes Tailnet, die nicht zu Tailscale Inc. gehört und deren README sagt, dass Reverse Proxys und Container dafür weder unterstützt noch empfohlen werden [17]. Die Anmeldung läuft über einen Identitätsanbieter wie Apple, Google, GitHub, Microsoft, Okta oder OneLogin oder über einen eigenen OIDC-Anbieter. Es gibt keine Tailscale-Passwörter und keine Anmeldung per E-Mail, und ein Tailnet lässt sich nicht von oder zu GitHub oder Apple als Anbieter umziehen [15].
- Geschwindigkeit. Tailscales eigene Vergleichsseite sagt, dass reines WireGuard schneller ist. Den größten Unterschied gibt es unter Linux, wo WireGuard als Kernelmodul laufen kann und Tailscale damals die Userspace-Umsetzung nutzte. Eine über Relay laufende Tailscale-Verbindung ist langsamer als eine direkte [5]. Die Seite enthält auch Aussagen vom Dezember 2020, also miss auf deiner eigenen Hardware. Unsere Einschätzung: An einem Heimanschluss bremst dich eher der Upload als der Tunnel.
- Kosten. WireGuard ist freie Software. Stand 24. Okt. 2026 nennt die Preisseite von Tailscale einen kostenlosen Tarif Personal für bis zu 6 Nutzer mit unbegrenzt vielen Nutzergeräten und einen Tarif Standard für 8 US-Dollar pro Nutzer und Monat [16]. Tarife und Preise ändern sich, prüfe also die Seite. Ob die Bedingungen des Tarifs Personal eine gewerbliche Nutzung abdecken, haben wir nicht geprüft. Lies sie zuerst, wenn du ihn für ein Unternehmen nutzt.
- Schlüssellaufzeit. Tailscale-Geräte müssen sich standardmäßig nach 180 Tagen neu anmelden. Für Server kannst du den Ablauf abschalten, und Geräte, die du zum ersten Mal mit einem Tag versiehst, haben ihn standardmäßig aus [13]. Ein abgelaufener Schlüssel beendet Verbindungen stillschweigend, ein Server, den du aus der Ferne erreichen willst, sollte also nicht davon abhängen. Ein statischer WireGuard-Schlüssel läuft nicht ab. Er wechselt aber auch nicht von allein, das Ersetzen ist also deine Aufgabe (unsere Einschätzung).
- Nimmt dein Anschluss eingehende Verbindungen an? Reines WireGuard braucht einen Endpunkt, den andere erreichen. Teilt dein Anbieter IPv4-Adressen unter mehreren Kunden auf, wie es Dual-Stack Lite tut [18], kannst du nicht damit rechnen, einen Port für eingehendes IPv4 weiterzuleiten (unsere Lesart). Bleiben ein IPv6-Endpunkt oder ein kleiner gemieteter Server als Knotenpunkt. Sieh auf die Statusseite deines Routers, bevor du planst. Tailscale braucht keinen eingehenden Port [5][7].
- Was gegen beide spricht. WireGuard: Jedes Gerät ist Handarbeit, Schlüssel und Endpunkte musst du selbst in Ordnung halten, es gibt keine Nutzerverwaltung und kein zentrales Protokoll, und ein offener UDP-Port zu Hause ist eine dauerhafte Angriffsfläche, die du pflegst. Tailscale: Ein Dritter sitzt im Steuerpfad, du hängst an einem Konto bei einem Identitätsanbieter, Relays kosten Geschwindigkeit, und der kostenlose Tarif hat Grenzen, die sich ändern können. Bei beiden: Ein Tunnel ins LAN gibt einem gestohlenen Laptop dieselbe Reichweite, also begrenze, was der Tunnel erreichen darf.
Im Vergleich
| WireGuard allein | Tailscale | |
|---|---|---|
| Was es ist | Tunnelprotokoll und Werkzeuge [1] | Dienst auf WireGuard-Basis [5] |
| Schlüssel und Konfiguration | von Hand, pro Gerät [2][5] | wird für dich erledigt [5] |
| Eingehende Verbindung nötig | ja, ein Endpunkt muss erreichbar sein [5] | nein, NAT-Traversal und Relays [5][7] |
| Geräte ohne Client erreichen | Route über ein selbst eingerichtetes Gateway | Subnet Router [8] |
| Zugriffsregeln | AllowedIPs und eigene Firewall [1][5] | zentrale Regeln für Nutzer, Gruppen, Tags [5] |
| Dritter im Pfad | keiner | Steuerungsebene, Anmeldeanbieter, Relays [6][14][15] |
| Selbst betriebene Steuerung | nicht zutreffend | Headscale als Option [17] |
| Kosten, 24. Okt. 2026 | freie Software | kostenloser Tarif Personal, bis zu 6 Nutzer; Standard 8 US-Dollar pro Nutzer und Monat [16] |
Ein Homelab-Beispiel
Am 14.10.2026 haben wir entschieden, dass ein Handy das Bytearium-Heimnetz über WireGuard auf unserem UniFi-Gateway erreichen soll, als Split-Tunnel, der nur Heimnetzverkehr trägt. Das Gateway hängt hinter dem Router des Internetanbieters (doppeltes NAT). Deshalb stehen eine UDP-Portweiterleitung an diesem Router, ein Dyndns-Name für den Endpunkt und die Prüfung auf eine öffentliche IPv4-Adresse statt Dual-Stack Lite am Anfang. Auf dem Handy decken die erlaubten Adressen nur das Heimnetz und das Tunnelnetz ab, das DNS-Feld bleibt leer, damit die Namensauflösung des Handys unberührt bleibt, und der Tunnel startet von selbst im Mobilfunk und in fremden WLANs, aber nicht zu Hause. Ob der Tunnel schon eingerichtet ist, haben wir nicht erfasst, und Tailscale kommt in unserem Inventar nicht vor (Stand 14. bis 18.10.2026). Was folgt, ist ein allgemeiner Ablauf für deinen eigenen Linux-Server und kein Bericht über unseren.
Reines WireGuard, ein Server und ein Laptop. Wähle ein Tunnelnetz, das sich nicht mit deinem LAN überschneidet, hier 10.8.0.0/24. Der Aufbau folgt dem Beispiel des Projekts [1][4]:
# Server: /etc/wireguard/wg0.conf
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <privater-Schluessel-des-Servers>
[Peer]
# Laptop
PublicKey = <oeffentlicher-Schluessel-des-Laptops>
AllowedIPs = 10.8.0.2/32# Laptop: /etc/wireguard/wg0.conf
[Interface]
Address = 10.8.0.2/24
PrivateKey = <privater-Schluessel-des-Laptops>
[Peer]
PublicKey = <oeffentlicher-Schluessel-des-Servers>
Endpoint = vpn.example.org:51820
AllowedIPs = 10.8.0.0/24, 192.168.10.0/24
PersistentKeepalive = 25Die AllowedIPs des Laptops nennen nur den Tunnel und das Heim-LAN, das ist der Split-Tunnel. Ein Wert von 0.0.0.0/0 würde alles über zu Hause schicken, und wg-quick kümmert sich dann um die Standardroute [4]. Starte mit sudo wg-quick up wg0 und sieh dir sudo wg show an. Damit der Laptop weitere Rechner im LAN erreicht, muss der Server Pakete weiterleiten, und diese Rechner brauchen eine Rückroute nach 10.8.0.0/24, oder der Server schreibt Absenderadressen um. Für solche Firewall-Regeln sind die Schlüssel PostUp und PostDown von wg-quick gedacht [4].
Tailscale als Subnet Router auf einem Linux-Server. Die Befehle folgen der Tailscale-Dokumentation [8][10]. Ersetze 192.168.10.0/24 durch dein LAN:
curl -fsSL https://tailscale.com/install.sh | sh
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 up
sudo tailscale set --advertise-routes=192.168.10.0/24Bestätige die Route dann auf der Seite „Machines“ der Admin-Konsole, ergänze eine Zugriffsregel, die deinem Nutzer das Subnetz erlaubt, und prüfe von einem anderen Gerät mit tailscale ip -4 auf dem Router und einem Ping. Linux-Clients übernehmen Subnetz-Routen nur mit sudo tailscale set --accept-routes [8]. Tailscale rät, dass deine Firewall Weiterleitung standardmäßig verbietet, bevor du IP-Weiterleitung einschaltest [8], und dass du den Schlüsselablauf auf dem Server abschalten solltest [13].
Tailscale in Docker, als Knoten für einen Container-Stack, mit festem Tag, den es Stand 24. Okt. 2026 auf Docker Hub gibt [12]. Der Aufbau folgt Tailscales Beispiel für eigenständiges Docker [9] und der Parameterliste [11]. Erzeuge den Auth-Key in der Admin-Konsole, lege ihn in einer .env-Datei als TS_AUTHKEY=... ab und behandle ihn wie ein Passwort:
services:
tailscale:
image: tailscale/tailscale:v1.104.2
hostname: homelab-node
environment:
TS_AUTHKEY: "${TS_AUTHKEY}"
TS_STATE_DIR: "/var/lib/tailscale"
volumes:
- "./tailscale-state:/var/lib/tailscale"
cap_add:
- net_admin
- net_raw
restart: unless-stoppedOhne das Zustandsverzeichnis entsteht bei jedem Neustart ein neuer Knoten in der Admin-Konsole [11]. Der Container läuft standardmäßig im Userspace-Netzwerk, das überall funktioniert, aber langsamer ist als Kernel-Netzwerk [11].
Prüfliste
- Prüfe vor der Wahl auf der Statusseite deines Routers, ob dein Anschluss überhaupt eingehende Verbindungen annimmt.
- Entscheide, wer Zugriff braucht: nur du oder auch Familie und Freunde. Die Antwort spricht für WireGuard oder Tailscale.
- Wähle ein Tunnelnetz ohne Überschneidung mit deinem LAN und halte
AllowedIPsso schmal, wie die Aufgabe es erlaubt. - Erzeuge Schlüssel mit
umask 077und lege private Schlüssel weder auf geteilte Laufwerke noch ins Repository. - Leite nur den einen UDP-Port weiter, den WireGuard braucht, nie einen ganzen Rechner.
- Setze eine Firewall-Regel, die Weiterleitung standardmäßig verbietet, bevor du IP-Weiterleitung einschaltest.
- Schreibe in Tailscale Regeln mit Nutzern, Gruppen oder Tags und teste sie mit einem Gerät, dem der Zugriff verwehrt sein muss.
- Prüfe den Schlüsselablauf auf jedem Tailscale-Server und entscheide, ob er aus sein soll.
- Pinne den Docker-Tag, notiere das Datum und lies die Release-Notes, bevor du ihn änderst.
- Teste den Rückweg: Schalte den Tunnel am Handy aus und prüfe, dass du das LAN nicht mehr erreichst.
- Halte fest, wer was erreichen darf, und entferne Geräte, die du nicht mehr nutzt.