WireGuard und Tailscale VPN auf einem Linux-VPS

17 Min. Lesezeit·Matthieu·securitydebianubuntulinuxheadscalevpntailscalewireguard|

WireGuard von Grund auf einrichten oder Tailscale für verwalteten VPN-Zugang auf Ubuntu 24.04 und Debian 12 bereitstellen, mit DNS-Leak-Schutz, PreSharedKey-Härtung und einem neutralen Vergleich einschließlich Headscale.

Diese Anleitung behandelt zwei Ansätze für den VPN-Zugang zu einem Linux-VPS: WireGuard (manuell, volle Kontrolle) und Tailscale (verwaltet, sofort einsatzbereit). Beide verwenden das WireGuard-Protokoll. Der Unterschied liegt darin, wer die Schlüssel, das Routing und die Koordination verwaltet.

Wählen Sie den Abschnitt, der zu Ihrer Situation passt, oder lesen Sie alle drei Teile für eine fundierte Entscheidung.

Voraussetzungen:

  • Ein VPS mit Ubuntu 24.04 oder Debian 12 (funktioniert auf einem Virtua Cloud VPS)
  • SSH-Zugang mit einem Nicht-Root-Benutzer mit sudo-Rechten
  • Eine konfigurierte und aktive Firewall
  • Ein lokaler Rechner (Linux, macOS oder Windows) als VPN-Client

Warum sollten Sie per VPN auf Ihren Linux-VPS zugreifen?

Jeder Dienst, der auf einer öffentlichen IP erreichbar ist, ist ein Ziel. SSH-Brute-Force-Bots finden neue Server innerhalb von Minuten. Datenbank-Ports, Admin-Panels und API-Endpunkte werden ständig gescannt. Ein VPN hält Verwaltungsschnittstellen vollständig vom öffentlichen Internet fern.

Das Prinzip ist einfach: Binden Sie sensible Dienste an die VPN-Schnittstellenadresse statt an 0.0.0.0. Nur Geräte mit gültigen VPN-Schlüsseln können sie erreichen. Das öffentliche Internet sieht nie, dass diese Ports existieren.

Typische Anwendungsfälle:

  • Admin-Zugang ohne öffentliches SSH. Binden Sie sshd an die WireGuard-IP. Kein Port 22 mehr, der der Welt ausgesetzt ist. Fail2ban wird optional, wenn es nichts zu bruteforcen gibt.
  • Tunnel zu privaten KI-Inferenz-APIs. Sie betreiben Ollama oder einen privaten LLM-Endpunkt auf Ihrem VPS? Setzen Sie ihn hinter das VPN. Kein API-Gateway nötig, keine Token-Authentifizierung für den internen Zugriff.
  • Multi-Cloud-Mesh-Netzwerk. Verbinden Sie VPS-Knoten verschiedener Anbieter (Virtua, Hetzner, OVH) zu einem privaten Netzwerk. Dienste kommunizieren über verschlüsselte Tunnel ohne öffentliche Endpunkte.
  • Verschlüsselung des Datenverkehrs in nicht vertrauenswürdigen Netzwerken. Leiten Sie den gesamten Datenverkehr über den VPS, wenn Sie aus Cafés oder Hotel-WLANs arbeiten. Ihr ISP und der lokale Netzbetreiber sehen nur verschlüsselte WireGuard-Pakete.

Das Bedrohungsmodell zählt. Wenn Sie nur von einer festen Büro-IP auf Ihren VPS zugreifen, können Firewall-Regeln ausreichen. Aber wenn Sie von mehreren Standorten arbeiten, mehrere Geräte nutzen oder ein Team mit unterschiedlichen Zugriffsebenen verwalten, ist ein VPN die sauberere Lösung.

Wie richtet man WireGuard auf Ubuntu 24.04 oder Debian 12 ein?

WireGuard ist ein VPN-Protokoll, das seit Version 5.6 in den Linux-Kernel integriert ist. Es verwendet Curve25519 für den Schlüsselaustausch, ChaCha20 für die Verschlüsselung und umfasst etwa 4.000 Codezeilen (im Vergleich zu über 100.000 bei OpenVPN). Installieren Sie es mit apt, generieren Sie Schlüsselpaare, schreiben Sie eine Konfigurationsdatei und starten Sie den Tunnel. Der gesamte Vorgang dauert weniger als 10 Minuten.

Installieren Sie WireGuard auf dem Server:

sudo apt update && sudo apt install wireguard wireguard-tools -y

Das Paket wireguard stellt das Kernelmodul bereit. Das Paket wireguard-tools stellt die Userspace-Werkzeuge wg und wg-quick bereit.

Wie generiert man WireGuard-Schlüssel und konfiguriert den Server?

WireGuard verwendet asymmetrische Schlüsselpaare (eines pro Peer) plus einen optionalen Preshared Key als Post-Quanten-Schutz. Generieren Sie ein Server-Schlüsselpaar, ein Client-Schlüsselpaar und einen gemeinsamen Preshared Key. Der Preshared Key fügt eine Schicht symmetrischer Verschlüsselung über dem Curve25519-Austausch von WireGuard hinzu. Falls ein zukünftiger Quantencomputer den asymmetrischen Schlüsselaustausch bricht, schützt der symmetrische Preshared Key den Tunnel weiterhin.

Generieren Sie auf dem Server die Schlüssel mit einer restriktiven umask, damit Dateien mit 600-Berechtigungen erstellt werden:

umask 077
wg genkey | sudo tee /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.key
wg genpsk | sudo tee /etc/wireguard/psk.key

ls -la /etc/wireguard/

-rw------- 1 root root   45 Mar 19 10:01 psk.key
-rw------- 1 root root   45 Mar 19 10:01 server_private.key
-rw------- 1 root root   45 Mar 19 10:01 server_public.key

Alle drei Dateien haben die Berechtigung 600 (nur Lesen/Schreiben für den Besitzer). Der private Schlüssel und der Preshared Key dürfen den Server niemals verlassen.

Generieren Sie auf Ihrem lokalen Rechner (dem Client) ein eigenes Schlüsselpaar:

umask 077
wg genkey | tee client_private.key | wg pubkey > client_public.key

Sie benötigen den öffentlichen Schlüssel des Clients auf dem Server und den öffentlichen Schlüssel des Servers auf dem Client. Der Preshared Key kommt auf beide Seiten. Übertragen Sie niemals private Schlüssel.

IP-Weiterleitung aktivieren

Der Server muss Datenverkehr für VPN-Clients routen. Aktivieren Sie die IPv4- und IPv6-Weiterleitung:

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-wireguard.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-wireguard.conf
sudo sysctl -p /etc/sysctl.d/99-wireguard.conf

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Die Verwendung einer Datei in /etc/sysctl.d/ ist der direkten Bearbeitung von /etc/sysctl.conf vorzuziehen. Sie übersteht Paketupdates und macht transparent, welche Einstellungen zu welchem Dienst gehören.

Server-Konfigurationsdatei

Identifizieren Sie die öffentliche Netzwerkschnittstelle Ihres Servers:

ip route show default

default via 203.0.113.1 dev eth0 proto static metric 100

In diesem Beispiel ist die Schnittstelle eth0. Ihre könnte ens3, ens18 oder anders heißen. Verwenden Sie das, was nach dev steht.

Erstellen Sie die Serverkonfiguration:

sudo nano /etc/wireguard/wg0.conf

[Interface]
Address = 10.66.66.1/24, fd42:42:42::1/64
ListenPort = 51820
PrivateKey = <Inhalt von /etc/wireguard/server_private.key>
PostUp = nft add table ip wireguard; nft add chain ip wireguard forward { type filter hook forward priority 0 \; policy accept \; }; nft add rule ip wireguard forward iifname "wg0" accept; nft add table ip nat; nft add chain ip nat postrouting { type nat hook postrouting priority 100 \; }; nft add rule ip nat postrouting oifname "eth0" masquerade
PostDown = nft delete table ip wireguard; nft delete table ip nat

[Peer]
PublicKey = <Inhalt von client_public.key>
PresharedKey = <Inhalt von /etc/wireguard/psk.key>
AllowedIPs = 10.66.66.2/32, fd42:42:42::2/128

Ersetzen Sie eth0 in den PostUp/PostDown-Zeilen durch Ihren tatsächlichen Schnittstellennamen.

Was die einzelnen Abschnitte bewirken:

  • Address: Die VPN-IP, die diesem Server zugewiesen ist. /24 und /64 definieren die VPN-Subnetzgröße.
  • ListenPort: Der UDP-Port, auf dem WireGuard lauscht. 51820 ist die Konvention.
  • PostUp/PostDown: nftables-Regeln, die NAT-Masquerading aktivieren. Wenn ein VPN-Client Datenverkehr ins Internet sendet, schreibt der Server die Quell-IP auf seine eigene öffentliche IP um. So funktioniert ein Full-Tunnel-VPN.
  • AllowedIPs im [Peer]-Abschnitt: Welche VPN-IPs dieser Client verwenden darf. /32 bedeutet genau eine IP. Das verhindert, dass Clients andere VPN-Adressen fälschen.

Falls Sie ufw statt reinem nftables verwenden, ersetzen Sie PostUp/PostDown durch:

PostUp = ufw route allow in on wg0 out on eth0; iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostDown = ufw route delete allow in on wg0 out on eth0; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Sperren Sie die Konfigurationsdatei. Sie enthält Ihren privaten Schlüssel:

sudo chmod 600 /etc/wireguard/wg0.conf

Firewall öffnen und Tunnel starten

Erlauben Sie den WireGuard-UDP-Port in der Firewall:

sudo ufw allow 51820/udp

Oder direkt mit nftables:

sudo nft add rule inet filter input udp dport 51820 accept

Starten Sie den Tunnel. Die enable-Anweisung macht ihn neustartfest. Das --now-Flag startet ihn sofort:

sudo systemctl enable --now wg-quick@wg0

sudo systemctl status wg-quick@wg0

● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/usr/lib/systemd/system/wg-quick@.service; enabled; preset: enabled)
     Active: active (exited) since ...

Der Status zeigt active (exited), weil wg-quick die Schnittstelle einrichtet und sich dann beendet. Das Kernelmodul übernimmt den Tunnel ab diesem Punkt. Prüfen Sie den laufenden Tunnel:

sudo wg show

interface: wg0
  public key: aB3dEfGhIjKlMnOpQrStUvWxYz1234567890abc=
  private key: (hidden)
  listening port: 51820

peer: xY9zAbCdEfGhIjKlMnOpQrStUvWxYz1234567890=
  preshared key: (hidden)
  allowed ips: 10.66.66.2/32, fd42:42:42::2/128

Die Ausgabe (hidden) bedeutet, dass WireGuard sensibles Schlüsselmaterial schützt. Wenn Sie latest handshake für einen Peer sehen, hat sich dieser Peer erfolgreich verbunden.

Client-Konfiguration

Erstellen Sie auf Ihrem lokalen Rechner die WireGuard-Konfiguration:

sudo nano /etc/wireguard/wg0.conf

[Interface]
Address = 10.66.66.2/24, fd42:42:42::2/64
PrivateKey = <Inhalt von client_private.key>
DNS = 10.66.66.1

[Peer]
PublicKey = <Inhalt von server_public.key>
PresharedKey = <Inhalt von psk.key>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = YOUR_SERVER_PUBLIC_IP:51820
PersistentKeepalive = 25

Erläuterung der wichtigen Einstellungen:

  • AllowedIPs = 0.0.0.0/0, ::/0 leitet den gesamten Datenverkehr durch das VPN (Full Tunnel). Für Split Tunneling, bei dem nur VPN-Subnetz-Verkehr durch den Tunnel geht, verwenden Sie stattdessen AllowedIPs = 10.66.66.0/24, fd42:42:42::/64.
  • Endpoint ist die öffentliche IP und der Port des Servers. Der Client benötigt dies, um die Verbindung aufzubauen. Der Server benötigt den Endpunkt des Clients nicht, da er ihn aus eingehenden Paketen lernt.
  • PersistentKeepalive = 25 sendet alle 25 Sekunden ein Keepalive-Paket. Dies hält NAT-Zuordnungen aktiv, damit der Server den Client erreichen kann. Ohne dies bricht die Verbindung nach Ablauf des NAT-Timeouts ab (typisch 30-120 Sekunden Inaktivität).
  • DNS = 10.66.66.1 leitet DNS-Anfragen an die VPN-Adresse des Servers. Das verhindert DNS-Leaks (im nächsten Abschnitt erklärt).

Unter macOS und Windows verwenden Sie die WireGuard-App. Importieren Sie die Konfigurationsdatei oder fügen Sie sie ein.

Verbinden Sie sich vom Client:

sudo wg-quick up wg0

ping 10.66.66.1

PING 10.66.66.1 (10.66.66.1) 56(84) bytes of data.
64 bytes from 10.66.66.1: icmp_seq=1 ttl=64 time=4.23 ms
64 bytes from 10.66.66.1: icmp_seq=2 ttl=64 time=3.98 ms

Bestätigen Sie von Ihrem lokalen Rechner, dass sich Ihre öffentliche IP geändert hat (bei Full Tunnel):

curl -s https://ifconfig.me

Dies sollte die öffentliche IP des VPS zurückgeben, nicht Ihre Heim-IP.

Weitere Clients hinzufügen

Generieren Sie für jeden weiteren Client ein neues Schlüsselpaar und einen neuen Preshared Key (ein PSK pro Peer-Paar). Fügen Sie einen [Peer]-Block in die wg0.conf des Servers ein:

[Peer]
PublicKey = <neuer öffentlicher Client-Schlüssel>
PresharedKey = <neuer Preshared Key>
AllowedIPs = 10.66.66.3/32, fd42:42:42::3/128

Erhöhen Sie die IP-Adresse für jeden Client. Nach der Bearbeitung laden Sie die Konfiguration neu, ohne bestehende Verbindungen zu unterbrechen:

sudo wg syncconf wg0 <(sudo wg-quick strip wg0)

Dies wendet die neue Peer-Konfiguration an, ohne die Schnittstelle neu zu starten. Bestehende Verbindungen bleiben aktiv.

MTU-Optimierung

WireGuard fügt 60 Bytes Overhead pro Paket hinzu (28 Bytes für die äußeren IPv4- und UDP-Header, 32 Bytes für den WireGuard-Header). Wenn Ihr VPS ein Standard-MTU von 1500 Bytes hat, setzen Sie das WireGuard-MTU auf 1420 im [Interface]-Abschnitt:

MTU = 1420

Setzen Sie dies auf Server und Client. Unterschiedliche MTU-Werte verursachen Paketfragmentierung und Durchsatzverluste, die schwer zu diagnostizieren sind. Wenn Sie WireGuard über eine Verbindung mit bereits reduziertem MTU betreiben (PPPoE, VXLAN), ziehen Sie entsprechend ab.

Wie verhindert man DNS-Leaks mit WireGuard?

DNS-Leaks treten auf, wenn Ihr System DNS-Anfragen außerhalb des VPN-Tunnels sendet und damit offenlegt, welche Domains Sie besuchen. Das macht den Datenschutzvorteil des VPN-Routings zunichte. Die Lösung: Betreiben Sie einen lokalen DNS-Resolver auf dem VPN-Server und zeigen Sie den DNS des Clients durch den Tunnel darauf.

Installieren Sie Unbound auf dem Server:

sudo apt install unbound -y

Erstellen Sie eine Konfigurationsdatei, die Unbound auf der WireGuard-Schnittstelle lauschen lässt:

sudo nano /etc/unbound/unbound.conf.d/wireguard.conf

server:
    interface: 10.66.66.1
    interface: fd42:42:42::1
    interface: 127.0.0.1
    access-control: 10.66.66.0/24 allow
    access-control: fd42:42:42::/64 allow
    access-control: 127.0.0.0/8 allow
    do-ip6: yes
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: yes
    prefetch: yes

Die Direktiven hide-identity und hide-version verhindern, dass Unbound seine Softwareversion in DNS-Antworten preisgibt. Versionsinformationen helfen Angreifern, bekannte Schwachstellen gezielt auszunutzen. Die harden-*-Optionen erzwingen DNSSEC-Validierung und verhindern Cache Poisoning. Die Option use-caps-for-id fügt 0x20-Kodierung zu DNS-Anfragen hinzu, ein leichtgewichtiger Schutz gegen gefälschte Antworten.

Unter Ubuntu 24.04 lauscht systemd-resolved standardmäßig auf Port 53 und kollidiert mit Unbound. Deaktivieren Sie es:

sudo systemctl disable --now systemd-resolved
sudo rm /etc/resolv.conf
echo "nameserver 127.0.0.1" | sudo tee /etc/resolv.conf

Starten Sie Unbound:

sudo systemctl enable --now unbound

sudo systemctl status unbound

● unbound.service - Unbound DNS server
     Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; preset: enabled)
     Active: active (running) since ...

Testen Sie, ob Unbound von der WireGuard-Schnittstelle auflöst:

dig @10.66.66.1 example.com +short

Sie sollten eine oder mehrere IP-Adressen erhalten. Die genauen IPs hängen von den aktuellen DNS-Einträgen der Domain ab.

Die Client-Konfiguration setzt bereits DNS = 10.66.66.1. Wenn der WireGuard-Tunnel aktiv ist, gehen alle DNS-Anfragen durch den verschlüsselten Tunnel zu Unbound. Keine Anfragen gelangen zu Ihrem ISP.

Zur Bestätigung auf der Client-Seite, verbinden Sie sich mit dem VPN und prüfen Sie:

resolvectl status wg0

Der DNS-Server sollte nur 10.66.66.1 anzeigen. Sie können auch dnsleaktest.com verwenden.

Test Vor VPN Nach VPN (mit Unbound)
Angezeigter DNS-Server ISP-Resolver (z.B. 192.168.1.1) 10.66.66.1 (VPS Unbound)
Vom Testdienst gesehene IP Heim-/Büro-IP Öffentliche VPS-IP
DNS-Anfragen für ISP sichtbar Ja Nein

Für tiefergehende DNS-Sicherheit einschließlich DNSSEC und DNS-over-HTTPS siehe.

Kill Switch: Was passiert, wenn der Tunnel abbricht?

Wenn der WireGuard-Tunnel abbricht, fließt der Datenverkehr unverschlüsselt über Ihre Standardroute. Ihre echte IP und DNS-Anfragen werden offengelegt. Ein Kill Switch verhindert dies, indem er allen Nicht-VPN-Datenverkehr auf Firewall-Ebene blockiert.

Auf dem Client fügen Sie nftables-Regeln hinzu, die nur Datenverkehr über die WireGuard-Schnittstelle und die verschlüsselte Verbindung zum Server-Endpunkt erlauben:

sudo nft add table inet killswitch
sudo nft add chain inet killswitch output { type filter hook output priority 0 \; policy drop \; }
sudo nft add rule inet killswitch output oifname "wg0" accept
sudo nft add rule inet killswitch output ip daddr YOUR_SERVER_PUBLIC_IP udp dport 51820 accept
sudo nft add rule inet killswitch output oifname "lo" accept

Damit wird bei einem Ausfall von wg0 der gesamte ausgehende Datenverkehr blockiert. Keine DNS-Leaks, keine Klartextpakete. Der einzige erlaubte Datenverkehr ist der verschlüsselte WireGuard-Handshake zum Server.

Entfernen Sie den Kill Switch, um das normale Routing wiederherzustellen:

sudo nft delete table inet killswitch

Für einen persistenten Kill Switch, der sich automatisch aktiviert, speichern Sie diese Regeln in einer Datei und laden Sie sie mit einem systemd-Dienst, der vor wg-quick@wg0 startet.

Wie richtet man Tailscale auf einem Linux-VPS ein?

Tailscale ist ein Mesh-VPN-Dienst, der auf WireGuard aufbaut. Er übernimmt die Schlüsselverteilung, NAT-Traversal und Peer-Erkennung über einen Koordinationsserver. Sie installieren den Client, authentifizieren sich mit Ihrem Identity Provider und Ihre Geräte können sich gegenseitig erreichen. Kein manueller Schlüsselaustausch, keine Portweiterleitung, keine Firewall-Regeln zu öffnen.

Der Kompromiss: Tailscales Koordinationsserver ist ein Drittanbieterdienst. Er sieht die Metadaten Ihrer Geräte (IPs, Hostnamen, welche Geräte online sind), aber nie Ihren Datenverkehr, der Peer-to-Peer über WireGuard fließt.

Wie installiert man Tailscale auf Ubuntu 24.04 oder Debian 12?

Fügen Sie das offizielle Tailscale-Repository hinzu und installieren Sie das Paket. Das vermeidet curl | sh und ermöglicht die Verifizierung von Updates über apt.

Für Ubuntu 24.04 (Noble):

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install tailscale -y

Für Debian 12 (Bookworm):

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install tailscale -y

Starten Sie Tailscale und authentifizieren Sie sich:

sudo tailscale up

Dies gibt eine Authentifizierungs-URL aus. Öffnen Sie diese in Ihrem Browser und melden Sie sich mit Ihrem Identity Provider (Google, Microsoft, GitHub usw.) an. Nach der Authentifizierung tritt der VPS Ihrem Tailnet bei.

sudo systemctl status tailscaled

● tailscaled.service - Tailscale node agent
     Loaded: loaded (/usr/lib/systemd/system/tailscaled.service; enabled; preset: enabled)
     Active: active (running) since ...

Prüfen Sie die zugewiesene Tailscale-IP:

tailscale ip -4

100.64.0.1

Jedes Gerät in Ihrem Tailnet erhält eine stabile 100.x.x.x-Adresse (CGNAT-Bereich). Diese IP bleibt über Neustarts und Neuverbindungen hinweg bestehen. Verwenden Sie sie, um Ihren VPS von jedem anderen Gerät im selben Tailnet zu erreichen.

Prüfen Sie die Konnektivität zu Ihren anderen Geräten:

tailscale status

100.64.0.1    vps-frankfurt    youruser@  linux   -
100.64.0.2    laptop           youruser@  macOS   active; direct 203.0.113.50:41641

Die Bezeichnung direct bedeutet, dass der Datenverkehr Peer-to-Peer über WireGuard fließt. Steht dort relay, läuft der Datenverkehr über einen DERP-Relay-Server, was Latenz hinzufügt. DERP-Relaying tritt auf, wenn beide Peers hinter restriktiven NATs stehen, die direkte Verbindungen verhindern.

Schlüsselablauf für Server deaktivieren

Tailscale-Schlüssel laufen standardmäßig nach 180 Tagen ab. Bei Ablauf geht das Gerät offline, bis jemand es erneut authentifiziert. Für einen VPS, der verbunden bleiben muss, haben Sie zwei Optionen.

Option 1: Ablauf in der Admin-Konsole deaktivieren. Gehen Sie zur Machines-Seite, finden Sie Ihren VPS, klicken Sie auf das Menü und wählen Sie „Disable key expiry".

Option 2 (empfohlen): Einen getaggten Auth-Key verwenden. Getaggte Geräte haben den Schlüsselablauf automatisch deaktiviert. Generieren Sie einen wiederverwendbaren, getaggten Auth-Key in der Admin-Konsole unter Settings > Keys und treten Sie bei mit:

sudo tailscale up --auth-key=tskey-auth-XXXXX --advertise-tags=tag:server

Tags funktionieren auch mit ACLs (siehe unten), was sie zur besseren Wahl für Server-Infrastruktur macht.

Wie konfiguriert man einen Tailscale Exit Node auf Ihrem VPS?

Ein Exit Node leitet den gesamten Internetverkehr Ihrer Geräte über den VPS. Ihr ausgehender Datenverkehr scheint von der IP-Adresse des VPS zu stammen. Das funktioniert wie ein traditionelles VPN: alles verschlüsseln, über den VPS-Standort ausleiten.

Aktivieren Sie die IP-Weiterleitung auf dem VPS:

echo 'net.ipv4.ip_forward = 1' | sudo tee /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

Melden Sie den VPS als Exit Node an:

sudo tailscale set --advertise-exit-node

Genehmigen Sie den Exit Node in der Admin-Konsole. Finden Sie den VPS, klicken Sie auf das Menü, gehen Sie zu „Edit route settings" und aktivieren Sie „Use as exit node".

Von Ihrem Client-Gerät, verwenden Sie den Exit Node:

sudo tailscale set --exit-node=<vps-tailscale-ip>

Um den lokalen LAN-Zugang (Drucker, NAS, andere lokale Geräte) zu behalten, während der Internetverkehr über den Exit Node läuft:

sudo tailscale set --exit-node=<vps-tailscale-ip> --exit-node-allow-lan-access=true

Um das Routing über den Exit Node zu beenden:

sudo tailscale set --exit-node=

Bestätigen Sie, dass der Exit Node funktioniert, indem Sie Ihre öffentliche IP vom Client prüfen:

curl -s https://ifconfig.me

Dies sollte die öffentliche IP des VPS zurückgeben.

Subnet-Routing

Subnet-Routing macht ein privates Netzwerk hinter dem VPS für Ihr Tailnet zugänglich. Das ist nützlich, wenn Ihr VPS ein privates Datenbank-Subnetz oder interne Dienste erreichen kann, auf denen kein Tailscale läuft.

sudo tailscale set --advertise-routes=192.168.1.0/24

Genehmigen Sie die Route in der Admin-Konsole genauso wie Exit Nodes. Nach der Genehmigung können alle Tailnet-Geräte 192.168.1.0/24 über den VPS als Gateway erreichen, ohne Tailscale auf jedem Host in diesem Subnetz zu installieren.

Sie können mehrere Routen durch Kommatrennung ankündigen:

sudo tailscale set --advertise-routes=192.168.1.0/24,10.0.0.0/16

Für stark genutzte Subnet-Router mit vielen gleichzeitigen Verbindungen empfiehlt Tailscale den Kernel-Modus (nur Linux) gegenüber dem Userspace-Modus. Unter Linux ist der Kernel-Modus die Voreinstellung. Prüfen Sie mit:

tailscale debug prefs | grep RouteAll

Wie richtet man Tailscale-ACLs für den VPS-Zugang ein?

Standardmäßig können alle Geräte in einem Tailnet einander auf allen Ports erreichen. Für den Produktivbetrieb schränken Sie dies mit ACLs in der Tailnet-Policy-Datei ein.

Eine minimale Policy, die den VPS-Zugang auf eine Admin-Gruppe beschränkt:

{
  "groups": {
    "group:admins": ["alice@example.com", "bob@example.com"]
  },
  "tagOwners": {
    "tag:server": ["group:admins"]
  },
  "acls": [
    {
      "action": "accept",
      "src": ["group:admins"],
      "dst": ["tag:server:*"]
    }
  ]
}

Das bedeutet: Nur Mitglieder von group:admins können auf Geräte mit dem Tag tag:server zugreifen. Alle anderen Verbindungen werden standardmäßig abgelehnt. Bearbeiten Sie dies in der Admin-Konsole unter Access Controls.

Taggen Sie den VPS beim Beitritt zum Tailnet:

sudo tailscale up --advertise-tags=tag:server

Eine granularere Policy kann nach Port einschränken:

{
  "groups": {
    "group:admins": ["alice@example.com"],
    "group:developers": ["bob@example.com", "charlie@example.com"]
  },
  "tagOwners": {
    "tag:server": ["group:admins"]
  },
  "acls": [
    {
      "action": "accept",
      "src": ["group:admins"],
      "dst": ["tag:server:*"]
    },
    {
      "action": "accept",
      "src": ["group:developers"],
      "dst": ["tag:server:22,80,443"]
    }
  ]
}

Entwickler erhalten SSH- (22) und Web-Zugang (80, 443). Admins haben vollen Zugriff. Niemand sonst kann den Server erreichen. Tailscale setzt diese Regeln auf Client-Ebene durch, sodass Datenverkehr blockiert wird, bevor er den Server überhaupt erreicht.

MagicDNS

Tailscale enthält MagicDNS, das jedem Gerät einen im Tailnet auflösbaren Hostnamen gibt. Statt sich 100.64.0.1 zu merken, verbinden Sie sich per SSH mit vps-frankfurt. Aktivieren Sie es in der Admin-Konsole unter DNS-Einstellungen. Kein Unbound oder manuelle DNS-Konfiguration nötig.

Was ist Headscale und wann sollten Sie es einsetzen?

Headscale ist eine quelloffene, selbst gehostete Implementierung des Tailscale-Koordinationsservers. Es verwendet Standard-Tailscale-Clients, betreibt aber die Steuerungsebene auf Ihrer eigenen Infrastruktur. Keine Gerätebeschränkungen, keine Telemetrie, keine Abhängigkeit von Tailscales SaaS. Kompatibel mit allen offiziellen Tailscale-Clients (Linux, macOS, Windows, iOS, Android).

Die Architektur:

┌─────────────┐       ┌──────────────────┐       ┌─────────────┐
│  Client A    │──────▶│   Headscale      │◀──────│  Client B    │
│  (tailscale) │       │ (Ihr Server)     │       │  (tailscale) │
└──────┬───────┘       └──────────────────┘       └──────┬───────┘
       │                                                  │
       └────────────── WireGuard-Tunnel ──────────────────┘
                     (direkt, Peer-to-Peer)

Headscale übernimmt den Schlüsselaustausch, die Geräteregistrierung und die ACL-Durchsetzung. Der eigentliche VPN-Datenverkehr fließt direkt zwischen den Peers über WireGuard. Headscale sieht nie Ihren Datenverkehr, nur Koordinations-Metadaten.

Was Headscale heute unterstützt: Geräteregistrierung (CLI und OIDC), ACLs, Subnet-Router, Exit Nodes, MagicDNS, Pre-Auth-Keys und Tagging. Es deckt die Kernfunktionen von Tailscale ab.

Was es nicht unterstützt: Tailscale Funnel, Serve, Netzwerk-Flow-Logs und einige Beta-Funktionen. Die Administrationsoberfläche ist nur per CLI verfügbar. Von der Community erstellte Web-UIs gibt es (headscale-ui), decken aber nicht jede Funktion ab.

Wann Headscale sinnvoll ist:

  • Vorschriften verbieten Drittanbieter-Koordinationsserver. Für Tailscales SaaS können DSGVO-Auftragsverarbeitungsverträge erforderlich sein. Headscale eliminiert diese Abhängigkeit.
  • Sie benötigen mehr Geräte als der kostenlose Tailscale-Tarif erlaubt.
  • Sie wollen volle Audit-Kontrolle über Geräteregistrierung und Schlüsselverwaltung.
  • Sie bauen eine Infrastruktur auf, in der die Abhängigkeit von einem externen SaaS ein Single Point of Failure ist.

Wann nicht:

  • Sie benötigen Tailscales globales DERP-Relay-Netzwerk für zuverlässiges NAT-Traversal. Headscale kann DERP nutzen, aber Sie müssen eigene Relays betreiben oder die öffentlichen von Tailscale akzeptieren.
  • Sie wollen eine polierte Admin-Oberfläche. Headscale ist CLI-orientiert.
  • Sie haben ein kleines Team und keinerlei Lust, einen weiteren Dienst zu warten.

Ein vollständiges Headscale-Setup-Tutorial ist für einen zukünftigen Artikel geplant. Bis dahin siehe die Headscale-Dokumentation.

WireGuard vs Tailscale vs Headscale: Was passt zu Ihrem Anwendungsfall?

Verwenden Sie WireGuard, wenn Sie volle Kontrolle, minimale Latenz, Air-Gapped-Netzwerke oder regulatorische Anforderungen benötigen, die Drittanbieter-Koordinationsserver verbieten. Verwenden Sie Tailscale, wenn Sie mehrere Geräte verwalten, NAT-Traversal ohne Portweiterleitung brauchen oder ACLs ohne manuelle Konfiguration wollen. Für Teams, die Tailscale-Funktionen mit selbst gehosteter Kontrolle wollen, kommt Headscale in Frage.

Dimension WireGuard Tailscale Headscale
Einrichtungszeit 10-15 Min. pro Peer 2 Min. pro Gerät 30-60 Min. (Server + Clients)
Schlüsselverwaltung Manuell (selbst generieren, verteilen, rotieren) Automatisch (Koordinationsserver) Automatisch (Ihr Koordinationsserver)
NAT-Traversal Keines. Erfordert Portweiterleitung oder öffentliche IP auf mindestens einer Seite Integriert (DERP-Relays + STUN) Teilweise (eigene DERP oder öffentliche Relays)
Peer-Erkennung Manuelle Konfiguration pro Peer Automatisches Mesh Automatisches Mesh
ACLs Firewall-Regeln (nftables/iptables) Policy-Datei in der Admin-Konsole Policy-Datei auf Ihrem Server
Max. Geräte Unbegrenzt Kostenloser Tarif hat Limits (siehe Preisseite) Unbegrenzt
Multi-Cloud-Mesh Konfiguration auf jedem Knoten, N*(N-1)/2 Peer-Einträge Tailnet beitreten, Mesh bildet sich automatisch Wie Tailscale, selbst gehostete Kontrolle
Drittanbieter-Abhängigkeit Keine Tailscale Inc. (nur Koordination) Keine
DSGVO / Compliance Volle Kontrolle, kein Drittanbieter-Auftragsverarbeiter Tailscale verarbeitet Geräte-Metadaten Volle Kontrolle
DNS Manuell (Unbound usw.) MagicDNS (automatisch, Hostnamen pro Gerät) MagicDNS (mit Konfiguration)
Latenz Minimal (WireGuard auf Kernel-Ebene) Minimal bei Direktverbindung; +20-50 ms bei DERP-Relay Wie Tailscale
Team-Onboarding Konfigurationsdateien und Schlüssel manuell teilen Einladungslink, SSO-Login Registrierung via CLI oder OIDC
Post-Quanten-Schutz PreSharedKey (manuelle Einrichtung) Nicht benutzerkonfigurierbar Nicht benutzerkonfigurierbar

Entscheidungshilfen

Solo-Entwickler, ein VPS: WireGuard. Der einfachste Weg. Null Abhängigkeiten. Niedrigste mögliche Latenz. Sie generieren zwei Schlüssel und schreiben zwei Konfigurationsdateien.

Team von 3-15 Personen, mehrere Geräte: Tailscale. Der Koordinationsserver spart Stunden an Schlüsselverwaltung. ACLs sind sauberer als nftables-Regeln pro Peer zu pflegen. NAT-Traversal funktioniert ohne Netzwerkänderungen.

Reguliertes Umfeld oder Pflicht zur Selbsthosting: Headscale, wenn Sie die Tailscale-UX ohne Drittanbieter-Abhängigkeit wollen. Reines WireGuard, wenn Sie null bewegliche Teile wollen und Ihr Team Konfigurationen verwalten kann.

Multi-Cloud-Mesh (5+ Knoten bei verschiedenen Anbietern): Tailscale oder Headscale. Mit WireGuard erfordern 10 Knoten insgesamt 45 Peer-Einträge. Bei 20 Knoten sind es 190. Der Konfigurationsaufwand wächst quadratisch.

KI-Inferenz-Endpunkt-Zugang: Wenn Sie von Ihrem Laptop zu einem GPU-VPS tunneln, funktioniert beides. Tailscale ist schneller einzurichten. WireGuard fügt keinen messbaren Overhead für latenzsensitive Inferenzaufrufe hinzu. Bei Multi-GPU-Setups über verschiedene Anbieter lohnt sich das Tailscale-Mesh.

Fehlerbehebung

WireGuard-Tunnel aktiv, aber kein Datenverkehr fließt:

Prüfen Sie die IP-Weiterleitung:

sysctl net.ipv4.ip_forward

Sollte net.ipv4.ip_forward = 1 zurückgeben. Prüfen Sie, ob die Masquerade-Regeln geladen sind:

sudo nft list ruleset | grep masquerade

Wenn leer, wurden die PostUp-Regeln nicht ausgeführt. Starten Sie mit sudo systemctl restart wg-quick@wg0 neu und prüfen Sie journalctl -u wg-quick@wg0 auf Fehler.

WireGuard-Handshake wird nie abgeschlossen:

sudo wg show

Wenn latest handshake nie für einen Peer erscheint, ist UDP-Port 51820 irgendwo blockiert. Bestätigen Sie, dass der Server lauscht:

sudo ss -ulnp | grep 51820

UNCONN 0      0        0.0.0.0:51820      0.0.0.0:*

WireGuard verwendet das Kernelmodul direkt, daher zeigt ss möglicherweise keinen Prozessnamen für den Socket an.

Testen Sie dann von der Client-Seite. Wenn Ihr Client hinter einer Unternehmens-Firewall steht, kann UDP 51820 blockiert sein. Manche Netzwerke erlauben nur TCP 443.

Tailscale zeigt „offline" in der Admin-Konsole:

sudo systemctl status tailscaled

Wenn der Dienst läuft, aber offline angezeigt wird, authentifizieren Sie erneut:

sudo tailscale up --force-reauth

Wenn tailscaled nicht läuft, prüfen Sie auf Portkonflikte mit anderer VPN-Software.

DNS leckt weiterhin nach Unbound-Einrichtung:

Prüfen Sie, ob Unbound auf der WireGuard-IP lauscht:

ss -ulnp | grep :53

Suchen Sie 10.66.66.1:53 in der Ausgabe. Wenn Unbound nur an 127.0.0.1 bindet, überprüfen Sie die interface:-Zeilen in /etc/unbound/unbound.conf.d/wireguard.conf.

Unter Ubuntu prüfen Sie auch, ob systemd-resolved tatsächlich gestoppt ist:

sudo systemctl is-active systemd-resolved

Gibt es active zurück, konkurriert es mit Unbound um Port 53.

Dienst-Logs:

journalctl -u wg-quick@wg0 -f
journalctl -u tailscaled -f
journalctl -u unbound -f

Bereit, es selbst auszuprobieren?

Stellen Sie Ihren eigenen Server in Sekunden bereit. Linux, Windows oder FreeBSD. →