Gateway startet nicht mehr (`/dev/net/tun` fehlt) — Synology — Wissensdatenbank — GateControl Home Gateway

Kurzfassung: Nach einem Neustart Ihrer Synology NAS (z. B. durch einen Stromausfall oder ein DSM-Update) startet der GateControl-Gateway-Container nicht mehr. Ursache ist ein fehlendes Gerät /dev/net/tun, weil manche Synology-Modelle das benötigte Kernelmodul beim Booten nicht automatisch laden. Die Lösung ist eine einmalig eingerichtete Aufgabe im DSM-Aufgabenplaner, die das Modul bei jedem Start lädt. Ein fertiges Skript finden Sie weiter unten.

Betrifft mich das?

Dieser Artikel ist für Sie relevant, wenn alle der folgenden Punkte zutreffen:

Sie betreiben den GateControl Gateway als Docker-Container auf einer Synology NAS mit DSM 7.
Der Container lief bisher problemlos, startet aber nach einem Neustart der NAS (Stromausfall, DSM-Update, manueller Reboot) nicht mehr.
Ein manueller Start des Containers schlägt ebenfalls fehl.

Dieselbe Ursache und Lösung gilt auch für andere TUN-basierte Container wie WireGuard oder OpenVPN.

Symptome

Der Container gatecontrol-gateway-gateway-1 ist nach einem Neustart gestoppt und lässt sich im Container Manager nicht starten.
Beim Start erscheint eine Docker-Fehlermeldung, die /dev/net/tun erwähnt, z. B.:

error gathering device information while adding custom device "/dev/net/tun": no such file or directory

Über SSH auf der NAS:

ls -l /dev/net/tun
# -> ls: cannot access '/dev/net/tun': No such file or directory

Schnelldiagnose

Melden Sie sich per SSH lokal auf der NAS an (im Heimnetz, Port 22) und führen Sie aus:

ls -l /dev/net/tun
lsmod | grep -iw tun

Gibt es /dev/net/tun nicht und fehlt in lsmod eine Zeile, die mit tun beginnt → dann ist genau dieses Problem die Ursache, und die Lösung unten behebt es.

Hinweis: Falls der Zugriff auf Ihre NAS oder andere Dienste über den GateControl Gateway läuft, ist dieser Weg bei gestopptem Gateway nicht erreichbar. Nutzen Sie dann den direkten Zugang im lokalen Netzwerk oder die DSM-Weboberfläche.

Ursache

Der GateControl Gateway nutzt eine WireGuard-Verbindung. Dafür benötigt er das virtuelle Netzwerkgerät /dev/net/tun, das vom Linux-Kernelmodul tun bereitgestellt wird.

Auf manchen Synology-Modellen wird dieses Modul beim Systemstart nicht automatisch geladen. Solange die NAS aber durchläuft, bleibt ein einmal geladenes Modul aktiv — und der Gateway läuft monatelang einwandfrei. Automatische Updates tauschen lediglich den Container aus, ohne die NAS neu zu starten, daher bleibt /dev/net/tun dabei erhalten.

Erst bei einem echten Neustart der NAS (Stromausfall, DSM-Update, manueller Reboot) verschwindet das Modul — und damit /dev/net/tun. Der Container findet das Gerät nicht mehr und kann nicht starten. Das erklärt, warum das Problem oft plötzlich nach langer störungsfreier Laufzeit auftritt und nicht jede NAS betrifft (auf manchen Modellen lädt ein anderes Paket, z. B. VPN Server, das Modul bereits mit).

Technischer Hintergrund: Der GateControl Gateway verwendet die Userspace-Variante wireguard-go. Diese benötigt kein WireGuard-Kernelmodul (das Synology nicht mitliefert), wohl aber das allgemeine TUN/TAP-Gerät /dev/net/tun.

Lösung: TUN-Modul beim Start automatisch laden

Wir richten eine Aufgabe im DSM-Aufgabenplaner ein, die das tun-Modul bei jedem Systemstart als Administrator (root) lädt.

Warum kein installierbares Paket? DSM 7 erlaubt es nicht, unsignierte Pakete mit root-Rechten zu installieren. Das Laden eines Kernelmoduls erfordert aber root-Rechte. Der Aufgabenplaner ist der einzige von Synology vorgesehene Weg, einen solchen Befehl beim Booten als root auszuführen.

Schritt für Schritt

Öffnen Sie Systemsteuerung → Aufgabenplaner.
Erstellen → Ausgelöste Aufgabe → Benutzerdefiniertes Skript.
Reiter Allgemein:
- Aufgabe: TUN beim Boot laden
- Benutzer: root
- Ereignis: Hochfahren
Reiter Aufgabeneinstellungen → Feld Benutzerdefiniertes Skript: Fügen Sie den Inhalt des Skripts load-tun.sh ein (siehe unten).
Mit OK speichern. DSM fragt zur Bestätigung ggf. nach Ihrem DSM-Passwort — das ist normal für Aufgaben, die als root laufen.
Markieren Sie die neue Aufgabe und klicken Sie auf Ausführen. Damit wird das Modul sofort geladen, ohne dass Sie neu starten müssen.

Das Skript

#!/bin/sh
# Lädt das TUN/TAP-Kernelmodul und stellt /dev/net/tun bereit.

# 1. Modul laden (modprobe zuerst, sonst direkt suchen und laden)
modprobe tun 2>/dev/null \
  || insmod "$(find /lib/modules -name 'tun.ko*' 2>/dev/null | head -1)" 2>/dev/null

# 2. Abbrechen, falls das Modul nicht geladen werden konnte
if ! grep -q '^tun ' /proc/modules; then
    logger -t load-tun "FEHLER: TUN-Modul konnte nicht geladen werden"
    exit 1
fi

# 3. Geräteknoten sicherstellen
[ -d /dev/net ]     || mkdir -p /dev/net
[ -c /dev/net/tun ] || mknod /dev/net/tun c 10 200
chmod 0666 /dev/net/tun
logger -t load-tun "/dev/net/tun ist bereit"

# 4. (Optional, nur GateControl) Gateway-Container starten:
# /usr/local/bin/docker start gatecontrol-gateway-gateway-1

exit 0

💡 Tipp für GateControl-Nutzer: Entfernen Sie in Zeile 4 das führende #, damit die Aufgabe nach dem Laden des Moduls auch direkt den Gateway-Container startet. Passen Sie den Containernamen bei Bedarf an Ihren Projektnamen an.

Ergebnis prüfen

Nach Ausführen der Aufgabe (oder nach dem nächsten Neustart) prüfen Sie:

ls -l /dev/net/tun
# erwartet: crw-rw-rw- 1 root root 10, 200 ... /dev/net/tun

lsmod | grep -iw tun
# erwartet: eine Zeile, die mit "tun" beginnt

Starten Sie anschließend den GateControl-Gateway-Container (Container Manager oder docker start). Er sollte nun wieder als „Up / healthy" laufen.

Bleibt das auch nach dem nächsten Neustart erhalten?

Ja. Weil die Aufgabe als „Hochfahren"-Ereignis eingerichtet ist, wird das Modul bei jedem Systemstart automatisch geladen. Das Problem tritt nicht erneut auf — auch nicht nach dem nächsten Stromausfall.

⚠️ Wichtig: Deaktivieren oder löschen Sie diese Aufgabe nicht. Andernfalls fehlt /dev/net/tun nach dem nächsten Neustart wieder.

Gateway startet nicht mehr (`/dev/net/tun` fehlt) — Synology