🛡️ WireGuard als nativer Dienst auf der Synology installieren – per SSH (inoffizielles Paket)

Ich hab da mal ‘ne blöde Frage – ist eigentlich irgendwas dagegen einzuwenden, WireGuard komplett ohne Umweg über Docker zu nutzen, selbst wenn man auf der Synology eh schon zig Container laufen hat? Also rein vom Aufwand und der Stabilität her? Ich find die Idee mit dem nativen WireGuard-Modul ja spannend, weil das ja im Gegensatz zu Docker-Lösungen quasi direkt im DSM „drin“ läuft und nicht nochmal extra eine Netzwerk-Bridge aufmacht. Müsste doch von der Performance her auch einen kleinen Tick fixer laufen, oder täusch ich mich da?

Bin mir nicht ganz sicher, ob dsa mit dem Autostart über das rc.d-Skript auf Dauer wirklich immer zuverlässig geht… Ich hab das damals bei einem älteren NAS-Modell gehabt, dass nach bestimmten DSM-Updates das Skript plötzlich ignoriert wurde. Gibts da vll einen Trick, wie man WireGuard wirklich robust immer starten lassen kann – oder bleibt da echt nur das regelmäßige Prüfen nach Updates? 🤔

Noch ein anderes Thema: Hat schonmal jemand probiert, mehrere WireGuard-Instanzen (also z.B. wg0 und wg1) gleichzeitig laufen zu lassen – etwa wenn man zwei getrennte Tunnel, z.B. für verschiedene Nutzer braucht? In der Standard-Docker-Lösung war das irgendwie fummelig, aber dsa native Modul müsste doch mehrere .conf-Dateien erlauben, oder? Weiß da jemand, wie man die jeweils sauber startet?

Sorry für die vielen Fragen, aber manchmal fehlt mir einfach der Überblick, wie tief man ins System damit reinfunken kann… Ich überlege, ob ich dann nicht gleich per Synology Drive oder Photos den Traffic direkt übers Tunnel lenke. Wäre ja eig. cool, wenn man z.B. immer automatisch ins Heimnetz reinspringen kann, sobald die App geöffnet wird.

Ich sehe das ganz ähnlich – nativ läuft WireGuard einfach näher am System, weniger Overhead, und man spart sich das Container-Verschachteln. Besonders wenn schon mehrere Docker-Container auf dem NAS werkeln, ist es angenehm, wenn wenigstens das VPN nicht noch eine zusätzliche Netzwerkschicht aufmacht. Die Performance ist beim nativen Modul in der Praxis tatsächlich meist minimal besser, besonders bei Durchsatz und Latenz. Was viele unterschätzen: Auch die Fehlersuche wird einfacher, weil man nicht ständig zwischen DSM, Docker-Netzen und Container-Logs switchen muss. 😊

Aus der Praxis kann ich aber ein paar Knackpunkte nennen, die man auf dem Schirm haben sollte – gerade bei Inkompatibilitäten nach DSM-Updates oder Kernel-Änderungen. Ich hab mir angewöhnt, nach jedem großen Update auf der Synology gezielt zu prüfen, ob das WireGuard-Modul noch lädt (mit lsmod | grep wireguard). Notfalls muss man das Kernel-Modul manchmal neu bauen oder die richtige Version nachziehen. Wer das nicht regelmäßig kontrolliert, steht unter Umständen plötzlich ohne VPN da…

Was den Autostart angeht: Das rc.d-Skript ist funktional, aber ich hab erlebt, dass gelegentlich nach Updates oder wenn DSM zickig wird, das Skript nicht ausgeführt wird oder Rechteprobleme auftreten. Hier hilft es, das Skript auf Standard-Shebang (#!/bin/sh) und Ausführbarkeit (chmod +x) zu prüfen. Wenn’s damit nicht läuft, kann man testweise auf einen systemd-approach umdenken – ist aber auf DSM ein ziemlicher Hack. Alternativ regelmäßige Healthchecks per Cron, die prüfen, ob das Interface läuft, und sonst einen Neustart triggern.

Abschließend noch ein schneller Vergleich, damit’s jeder im Blick hat:

Falls jemand das noch sauber mit UGREEN-Backuplösungen oder Synology Apps kombinieren will: Ich hab festgestellt, dass es am stabilsten läuft, wenn WireGuard als erstes Netz-Interface nach dem Hochfahren steht – dann meckert keine andere App wegen fehlender Connectivity...

Falls wer bessere Wege für Autostart/Update-Überwachung hat, gern her damit, ich probiere sowas immer gern! Bin mir auch nicht sicher, ob ich vll irgendwo was übersehe... 😅