WireGuard Mesh Networking: Ein Zero-Trust-Netzwerk zwischen Servern und NAS mit Tailscale und Netmaker aufbauen

Praxisnahe Anleitung zum Aufbau eines Zero-Trust-Mesh-Netzwerks zwischen entfernten Servern und einem NAS mit WireGuard, über zwei konkrete Wege: Tailscale (SaaS) und Netmaker (selbst gehostet).

Nov 6, 2026 0 5

WireGuard Mesh Networking: Ein Zero-Trust-Netzwerk zwischen Servern und NAS mit Tailscale und Netmaker aufbauen

Zwei Server über ein Punkt-zu-Punkt-VPN auf Basis von WireGuard zu verbinden, dauert nur wenige Minuten. Das Problem beginnt, wenn die Anzahl der Knoten auf fünf, zehn, zwanzig wächst: Cloud-Server bei verschiedenen Anbietern, ein NAS vor Ort, ein paar Raspberry Pis und die Laptops des Teams. Jedes einzelne Peer-Paar manuell zu konfigurieren, wird schnell zum Albtraum aus öffentlichen Schlüsseln, IP-Adressen und Konfigurationsdateien, die bei jeder Änderung von Hand aktualisiert werden müssen.

Hier kommt das Konzept des Mesh Networking ins Spiel: ein Netzwerk, in dem jedes Gerät direkt mit jedem anderen autorisierten Gerät kommunizieren kann, ohne über einen einzigen zentralen Punkt zu laufen, und in dem der Zugriff nicht davon abhängt, sich "innerhalb des Unternehmensperimeters" zu befinden, sondern von expliziten Regeln, die bei jeder Verbindung geprüft werden. Dieses zweite Prinzip hat einen Namen: Zero Trust. In diesem Leitfaden zeigen wir, wie man ein Zero-Trust-Mesh zwischen entfernten Servern und einem NAS konkret aufbaut - mit WireGuard als kryptografischer Grundlage und zwei Tools, die es auf sehr unterschiedliche Weise orchestrieren: Tailscale (SaaS-Dienst) und Netmaker (selbst gehostet).

WireGuard kurz erklärt: warum es zum Standard wurde

WireGuard ist ein modernes VPN-Protokoll, das leicht zu überprüfen (sein Quellcode ist um Größenordnungen kleiner als bei OpenVPN oder IPsec) und schnell sein soll, da es seit Version 5.6 direkt im Linux-Kernel läuft. Es verwendet moderne Kryptografie wie Curve25519 für den Schlüsselaustausch und ChaCha20 für die Verschlüsselung des Datenverkehrs und identifiziert jedes Gerät über ein Paar aus öffentlichem und privatem Schlüssel statt über Benutzername und Passwort.

Die Grenze von "reinem" WireGuard liegt nicht in der Sicherheit, sondern in der Organisation: Standardmäßig ist es für Punkt-zu-Punkt-Verbindungen gedacht. Ein Mesh mit vielen Knoten aufzubauen bedeutet, die Schlüssel jedes Peers manuell zu erzeugen und an alle anderen zu verteilen, die AllowedIPs-Adressen bei jeder Änderung zu aktualisieren und alles von Hand nachzuverfolgen. Genau das automatisieren Tailscale und Netmaker: Beide setzen unter der Haube auf das WireGuard-Protokoll, fügen aber eine automatische Orchestrierungsschicht hinzu (Schlüsselverteilung, Peer-Erkennung, Zugriffsregeln), die es auch bei Dutzenden von Knoten handhabbar macht.

Das Zero-Trust-Prinzip, angewandt auf das Netzwerk

Das traditionelle Netzwerksicherheitsmodell basiert auf einem Perimeter: Befindet sich ein Gerät "innen" (im Büro, im Unternehmens-VPN), wird ihm fast vollständig vertraut. Das Problem: Ist dieser Perimeter einmal durchbrochen - ein gestohlenes Zugangsdatum, ein kompromittierter Laptop - hat ein Angreifer freie Bahn, sich lateral zwischen den Systemen zu bewegen.

Das Zero-Trust-Prinzip dreht diesen Ansatz um: Kein Gerät und kein Benutzer gilt automatisch als vertrauenswürdig, auch nicht solche, die sich bereits "innerhalb" des Netzwerks befinden. Jede Verbindung wird einzeln authentifiziert und autorisiert, nach dem Prinzip der geringsten Rechte: Ein Backup-Server soll nur das NAS erreichen können, auf das er schreibt, nicht aber die Produktionsdatenbank oder den Arbeitsplatz des Administrators. Auf ein WireGuard-Mesh angewandt bedeutet das konkret zwei Dinge: eine starke Identität für jeden Knoten (der WireGuard-öffentliche Schlüssel, eindeutig pro Gerät) und ein Regelsystem (eine ACL, Access Control List), das explizit entscheidet, wer mit wem sprechen darf, anstatt zuzulassen, dass "jeder im Netzwerk" alles erreicht.

Tailscale und Netmaker: zwei unterschiedliche Philosophien

Sowohl Tailscale als auch Netmaker bauen ein automatisiertes WireGuard-Mesh auf, gehen dabei aber von entgegengesetzten Voraussetzungen aus. Tailscale ist ein SaaS-Dienst: Die Steuerungsebene (Authentifizierung, Schlüsselverteilung, Verwaltungsoberfläche) wird von Tailscales eigenen Servern betrieben, während der Datenverkehr zwischen den Geräten, wo möglich, direkt Peer-to-Peer läuft. Netmaker hingegen ist für den Selbsthosting-Einsatz gedacht: Man installiert die Steuerungsebene (die kostenlose, Open-Source-Community-Edition) auf dem eigenen Server und bleibt Eigentümer der gesamten Infrastruktur, Daten eingeschlossen.

Dieser Unterschied zeigt sich auch bei den Preisen. Tailscale bietet einen kostenlosen "Personal"-Plan für nicht-kommerzielle Nutzung mit bis zu 6 Nutzern und unbegrenzten Geräten; Team-Pläne starten bei 8 US-Dollar pro Nutzer und Monat (Standard-Plan), bis zu 18 US-Dollar beim Premium-Plan für größere Organisationen. Netmaker bietet dagegen eine kostenlose Open-Source-Community-Edition ohne angegebene Begrenzung bei Geräten oder Netzwerken, dazu kostenpflichtige Team- und Business-Pläne, die nach aktiven Verbindungen abgerechnet werden, ab etwa 2 US-Dollar pro Verbindung und Monat, gedacht für alle, die zusätzliche Funktionen wie automatisches Failover oder erweiterte Benutzerverwaltung wollen.

Praktisch bedeutet das: Wer sofort starten möchte, ohne einen zusätzlichen Server zu betreiben, und sich wohl damit fühlt, die Steuerungsebene einem externen Anbieter zu überlassen, ist mit Tailscale am schnellsten unterwegs. Wer hingegen Priorität darauflegt, die gesamte Infrastruktur - einschließlich des Servers, der entscheidet, "wer mit wem sprechen darf" - unter eigener Kontrolle zu behalten, sollte Netmaker in Betracht ziehen, auf Kosten eines zusätzlichen zu verwaltenden Servers.

Erster Weg: ein Zero-Trust-Mesh mit Tailscale

Tailscale wird über einen schlanken Client auf jedem Gerät installiert, das dem Netzwerk beitreten soll (Server, Laptops, Raspberry Pis). Nach der Authentifizierung erhalten die Geräte eine stabile virtuelle IP-Adresse im privaten Bereich 100.64.0.0/10 (derselbe Bereich, der für CGNAT verwendet wird) und können sich gegenseitig erreichen.

Ein NAS freigeben, ohne darauf etwas zu installieren

Viele NAS-Geräte unterstützen keine direkte Installation eines Tailscale-Clients, oder man möchte das System des Herstellers lieber nicht antasten. Die Lösung ist das Muster des Subnet Routers: Man installiert Tailscale auf einem dauerhaft eingeschalteten Gerät im selben lokalen Netzwerk wie das NAS (etwa einem kleinen Linux-Server oder einem Raspberry Pi) und lässt es als "Brücke" fungieren, die das gesamte Subnetz dem Mesh zugänglich macht, ohne dass das NAS selbst irgendetwas über WireGuard oder Tailscale wissen muss.

Auf dem Brückengerät startet man den Client, nachdem man IP-Forwarding auf Systemebene aktiviert hat, mit:

tailscale up --advertise-routes=192.168.1.0/24

wobei 192.168.1.0/24 das lokale Subnetz ist, in dem sich das NAS befindet. Das allein reicht nicht aus: Die angekündigte Route muss von einem Administrator in der Web-Verwaltungskonsole genehmigt werden (Bereich "Machines", Gerät mit dem Badge "Subnets"), sofern sie nicht bereits durch eine autoApprovers-Regel in der Policy-Datei abgedeckt ist. Erst dann können andere Mesh-Knoten - sofern sie mit tailscale set --accept-routes auf das Akzeptieren von Routen eingestellt sind (Standardverhalten unter macOS, iOS, Android und Windows) - das NAS unter seiner ursprünglichen lokalen IP-Adresse erreichen, als befänden sie sich im selben LAN.

Zugriffsregeln schreiben (ACLs/Grants)

Standardmäßig erlaubt ein neues "Tailnet" (so heißt Tailscales privates Netzwerk) allen Geräten, sich gegenseitig zu erreichen: Alles ist erlaubt außer expliziten Regeln. Um Zero Trust tatsächlich durchzusetzen, muss man diese Logik umkehren - die standardmäßig erlaubende Regel entfernen und nur die tatsächlich benötigten Berechtigungen in der JSON-Policy-Datei festlegen. Die moderne Syntax heißt grants (gegenüber dem älteren acls-Format bevorzugt, wobei beide koexistieren können), und jede Regel legt Quelle, Ziel und erlaubte Ports fest:

{
  "hosts": {
    "backup-server": "100.64.0.10",
    "nas": "100.64.0.20"
  },
  "grants": [
    {
      "src": ["backup-server"],
      "dst": ["nas"],
      "ip": ["tcp:445", "tcp:22"]
    }
  ]
}

In diesem Beispiel kann nur der Backup-Server das NAS erreichen, und nur über die Ports SMB (445) und SSH (22): Kein anderes Gerät im Mesh - selbst eines mit vollem Zugriff auf andere Systeme - kann darauf zugreifen. Um Berechtigungen über mehrere Geräte hinweg zu organisieren, lassen sich Tags verwenden, die im Abschnitt tagOwners der Policy zugewiesen werden: Ein Tag verschiebt den "Besitz" eines Geräts von einem einzelnen menschlichen Konto auf das Tag selbst, sodass der Zugriff nicht mehr davon abhängt, wer sich ursprünglich auf dieser Maschine angemeldet hat. Ein nicht ganz triviales praktisches Detail: Ein Tag von einem Gerät zu entfernen ist nicht einfach - oft muss man den Knoten aus dem Netzwerk entfernen und von Grund auf neu registrieren -, es lohnt sich also, das Tag-Schema sorgfältig zu planen, bevor man es produktiv einsetzt.

SSH-Zugriff ohne zu verwaltende Schlüssel

Ein praktischer Vorteil, sich für das gesamte Netzwerk auf die Tailscale-Identität zu verlassen, ist die Möglichkeit, "schlüssellosen" SSH-Zugriff zu aktivieren: Aktiviert man ihn auf einem Server mit tailscale set --ssh, basiert die SSH-Authentifizierung auf der Tailnet-Identität statt auf Schlüsseln, die manuell erzeugt, verteilt und widerrufen werden müssen. Die Regeln, wer sich per SSH anmelden darf und mit welchem Systembenutzer, werden in einem separaten Block der Policy definiert:

{
  "ssh": [
    {
      "action": "check",
      "src": ["group:sysadmin"],
      "dst": ["tag:server"],
      "users": ["deploy"]
    }
  ]
}

Mit "action": "check" erfordert der Zugriff eine periodische Neuauthentifizierung (das Intervall wird mit checkPeriod festgelegt), nützlich bei besonders sensiblen Servern; mit "action": "accept" erfolgt der Zugriff sofort nach erfolgter Identitätsprüfung. In beiden Fällen muss die SSH-Konfiguration des Betriebssystems diesen konkreten Benutzer ebenfalls erlauben.

Zwei praktische Hinweise vor dem Produktivbetrieb: Die Schlüssel der Knoten laufen standardmäßig nach 180 Tagen ab, was einen Subnet Router oder einen Exit Node unbemerkt vom Netz trennen kann, wenn man das Ablaufen bei Geräten mit dauerhafter Infrastrukturfunktion nicht deaktiviert; und Änderungen an der Policy werden sofort beim Speichern wirksam, sodass eine zu restriktive Regel genau die SSH-Sitzung unterbrechen kann, mit der man gerade arbeitet - es lohnt sich daher immer, das Diff der Änderungen vor dem Bestätigen zu prüfen.

Zweiter Weg: ein selbst gehostetes Mesh mit Netmaker

Wenn die vollständige Kontrolle über die Infrastruktur Priorität hat, ermöglicht Netmaker Community Edition die Installation der eigenen Steuerungsebene auf einem Server, ohne auf einen externen Anbieter angewiesen zu sein, der entscheidet, wer auf was zugreifen darf.

Anforderungen und Installation

Für die Community Edition benötigt Netmaker einen Ubuntu-24.04-Server (eine VM, Bare Metal oder sogar dieselbe Maschine, auf der die übrigen Dienste laufen), mit mindestens 1 GB RAM, 1 CPU und 2 GB Speicher zum Testen, für den Produktivbetrieb aber mindestens 2 GB RAM und 2 CPUs. Benötigt werden eine statische öffentliche IP-Adresse und idealerweise ein Domainname mit Zugriff auf die DNS-Verwaltung, da Dashboard, API, MQTT-Broker und Monitoring-Tools (Prometheus, Grafana) jeweils eine eigene öffentliche Subdomain brauchen (oder eine Wildcard wie *.netmaker.beispiel.de). Zu öffnen sind die Ports 80/TCP und 443/TCP für Zertifikate und die Weboberfläche sowie Port 51821/UDP für den WireGuard-Verkehr des Agenten.

Die geführte Installation der Community Edition läuft darauf hinaus, das offizielle Skript aus dem GitHub-Repository von Netmaker herunterzuladen und auszuführen:

curl -sfL https://raw.githubusercontent.com/gravitl/netmaker/master/scripts/nm-quick.sh -o /root/nm-quick.sh
chmod +x /root/nm-quick.sh
sudo /root/nm-quick.sh

Das Skript richtet automatisch TLS-Zertifikate ein (über Caddy), ebenso den für die Client-Kommunikation genutzten MQTT-Broker und das Admin-Dashboard. Ein nützlicher Hinweis für alle, die Cloudflare als DNS-Proxy nutzen: Das Proxying ("graue Wolke" statt orange) muss bei den von Netmaker genutzten Einträgen deaktiviert werden, sonst wird der MQTT-Verkehr auf eine Art blockiert, die Netmaker selbst nicht diagnostizieren kann.

Netzwerk erstellen und Knoten hinzufügen

Beim ersten Login im Dashboard legt man ein Administratorkonto an und erstellt dann ein neues Netzwerk, wobei man einen privaten Adressbereich wählt, der sich nicht mit einem bereits genutzten Netzwerk überschneidet (für Netzwerke mit weniger als 254 Maschinen reicht ein Block wie 10.11.12.0/24 völlig aus). Der Netmaker-Server tritt dem Netzwerk automatisch als erster Knoten bei.

Um einen entfernten Server oder das Brückengerät zum NAS hinzuzufügen, erzeugt man im Dashboard einen Enrollment Key (Bereich "Keys") und legt fest, wie oft er verwendet werden kann und für welche Netzwerke er Zugriff gewährt. Auf dem neuen Host installiert man, nachdem man geprüft hat, dass WireGuard und systemd vorhanden sind, den netclient für das eigene Betriebssystem und registriert den Knoten mit:

netclient register -k  -s grpc.meinedomain.de -p 50051

Kurz darauf erscheint der Knoten im Admin-Dashboard, und man kann die Konnektivität mit einem einfachen Ping an seine private Mesh-Adresse von einem anderen, bereits verbundenen Knoten aus überprüfen. Für Knoten, die später zu einem bereits bestehenden Netzwerk hinzugefügt werden, kann man alternativ ein dediziertes Registrierungstoken anstelle des Enrollment Keys verwenden, das genau für diesen Fall gedacht ist.

Netmaker regelt die Sicherheit des Mesh über netzwerkweite ACLs (welche Knoten innerhalb desselben virtuellen Netzwerks miteinander sprechen dürfen) und Tags, die Enrollment Keys zugewiesen werden können - ein anderer Mechanismus, aber konzeptionell verwandt mit den grants von Tailscale: Auch hier geht es darum, zu verhindern, dass "Teil des Mesh zu sein" automatisch bedeutet, "Zugriff auf alles zu haben".

Sicherheits-Best-Practices, unabhängig vom gewählten Tool

Unabhängig vom gewählten Weg gelten einige Vorsichtsmaßnahmen für beide. Erstens: das automatische Ablaufen von Schlüsseln auf Geräten deaktivieren, die eine dauerhafte Infrastrukturrolle spielen, wie der Subnet Router, der das NAS freigibt, oder der Netmaker-Server selbst - ein unerwartet abgelaufener Schlüssel auf einem kritischen Knoten bedeutet einen stillen Ausfall. Zweitens: beim Schreiben von Zugriffsregeln stets das Prinzip der geringsten Rechte anwenden und jedem Knoten nur die Ports und Peers gewähren, die er tatsächlich benötigt - nicht "alles Nötige plus etwas zur Sicherheit", denn das ist genau das Gegenteil des Zero-Trust-Gedankens. Drittens: sowohl den zugrunde liegenden WireGuard-Client als auch die Orchestrierungssoftware (Tailscale oder Netmakers netclient) aktuell halten, da beide regelmäßig Sicherheitskorrekturen erhalten. Viertens, oft unterschätzt: die Zugriffsregeln testen, bevor man sich im Produktivbetrieb darauf verlässt, und dabei nicht nur prüfen, ob autorisierte Verbindungen funktionieren, sondern auch, ob nicht autorisierte tatsächlich blockiert werden.

Welches Tool wählen?

Eine universelle Antwort gibt es nicht, aber einige praktische Hinweise. Für ein Homelab, ein kleines Team oder alle, die sofort starten möchten, ohne einen zusätzlichen Server zu verwalten, bietet Tailscale den schnellsten Weg, einen großzügigen kostenlosen Plan für die private Nutzung und eine Policy-Verwaltung, die granular genug ist, um ein echtes Zero-Trust-Modell umzusetzen. Für alle, die bereits eine eigene Serverinfrastruktur betreiben, Compliance-Anforderungen haben, die Daten und Steuerungsebene vor Ort verlangen, oder einfach nicht von einem externen SaaS-Anbieter für etwas so Kritisches wie den Netzwerkzugriff abhängig sein wollen, bietet Netmaker Community Edition dieselben WireGuard-basierten Sicherheitsgarantien - zum Preis eines zusätzlichen Servers, der verwaltet und aktuell gehalten werden muss. In beiden Fällen ist das Endergebnis dasselbe: ein verschlüsseltes Mesh, schnell, weil auf WireGuard basierend, und nach dem Prinzip gestaltet, dass keine Verbindung standardmäßig gewährt wird, sondern nur, weil sie explizit autorisiert wurde.