Das NAS im Internet veröffentlichen (Zugriff von außen)

15 min · 8 Abschnitte

Diese Anleitung macht aus deinem NAS deine Cloud: einen eigenen Namen (meinhaus.duckdns.org), ein gültiges Zertifikat und Zugriff von überall, ohne Warnungen des Browsers. Als Nebenwirkung lässt sich die Oberfläche als Anwendung installieren (PWA): Mit einem selbst signierten Zertifikat bremst der Browser den Service Worker aus, mit einem gültigen nicht.

Der Weg sind vier Schritte, in dieser Reihenfolge:

1. 80 und 443 im Router öffnen (und nur die).
2. Ein Domainname, der deiner IP folgt (DDNS).
3. Das Zertifikat von Let's Encrypt ausstellen.
4. Das Panel und die Apps über den Reverse Proxy veröffentlichen.

Das NAS zu veröffentlichen ist die Änderung, die in seinem ganzen Leben die meiste Angriffsfläche hinzufügt. Der Abschnitt Sicherheit ist kein Anhang: Lies ihn, bevor du den ersten Port öffnest.

Wenn du es nur zu Hause nutzt, gibt es einen kürzeren Weg

Wenn du nicht von außen hineinkommen musst und dich nur die Warnung des Browsers stört — und dass sich das Panel auf dem Handy nicht als Anwendung installieren lässt —, brauchst du nichts von alledem.

Dein NAS hat sein eigenes Zertifikat. Unter Systemsteuerung → Externer Zugriff → Zertifikat gibt es einen Knopf zum Herunterladen, mit den Schritten für das Gerät, von dem aus du gerade schaust (iPhone, Android, Windows, Mac oder Linux). Installiere es auf jedem Handy und jedem Computer, von dem aus du hineingehst, und die Warnung verschwindet auf diesem; danach lässt sich das Panel auch als Anwendung installieren.

Das musst du Gerät für Gerät machen — Vertrauen gehört jedem selbst —, aber nur ein einziges Mal: Es gilt weiter, auch wenn das NAS seine Adresse wechselt. Und sei dir bewusst, was du mit dem Installieren sagst: Dieses Gerät vertraut ab dann jeder Seite, die ihm dein NAS zeigt. Im Heimnetz ist das normal, aber installiere es nur auf deinen eigenen Geräten.

Wie es am Ende verkabelt ist

Internet ──► Router ──► NAS · Apache ──┬──► 127.0.0.1:5001   Panel von LGM-OS
             80 und 443  :443 TLS      ├──► 127.0.0.1:8096   Jellyfin
                         :80 leitet um └──► 127.0.0.1:8080   Nextcloud

Apache ist das Einzige, das von außen lauscht: Es beendet das TLS mit dem Zertifikat von Let's Encrypt und leitet über 127.0.0.1 an jeden Dienst weiter. Weder die Ports des Panels (5001 und 5000) noch die der Apps verlassen das NAS.

1. Bevor du anfängst

• Feste IP für das NAS in deinem Netz: eine DHCP-Reservierung im Router oder eine feste IP unter Systemsteuerung → Netzwerk. Wenn das NAS seine IP wechselt, zeigt die Weiterleitung der Ports nicht mehr auf das NAS.
• Eine echte öffentliche IP (kein CGNAT). Prüf das so:

curl -s https://api.ipify.org; echo      # die IP, mit der dich das Internet sieht

Vergleich diesen Wert mit der WAN-IP, die dein Router zeigt. Wenn sie nicht übereinstimmen oder die des Routers im Bereich 100.64.0.0 – 100.127.255.255 liegt, sitzt du hinter CGNAT: Die Weiterleitung der Ports wird nicht funktionieren, was du auch machst. Bitte deinen Anbieter um eine öffentliche IP (meist kostenlos, und danach zu fragen reicht) oder nimm ein VPN bzw. einen Tunnel.

• Ein Domainname: ein eigener oder ein kostenloser mit DDNS (Schritt 3).

2. Ports im Router: 80 und 443, sonst nichts

Der Port 80 ist nicht optional, auch wenn du nichts Unverschlüsseltes ausliefern willst: Let's Encrypt prüft, dass die Domain dir gehört, indem es eine Datei über den Port 80 anfordert, und ohne diese Prüfung gibt es kein Zertifikat. Was du aber machen solltest: Der Port 80 leitet nur auf 443 um.

Warum 5001 und 5000 NICHT geöffnet werden

Das sind die Ports des Panels: 5001 verschlüsselt und 5000 im Klartext, der nur auf 5001 umleitet. Sie zu veröffentlichen ist ein Fehler, auch wenn es wie der kurze Weg aussieht:

• Der 5000 läuft unverschlüsselt. Was von dort aus durchs Internet reist, liest jeder unterwegs mit, angefangen bei der Adresse, auf die du geschickt wirst.
• Der 5001 liefert das selbst signierte Zertifikat aus, der Browser warnt also immer, und du gewöhnst dich daran, Zertifikatswarnungen wegzuklicken — und genau das macht einen Angriff von jemandem, der sich dazwischenstellt, gegen dich erst möglich.
• Er legt die ganze API der Verwaltung direkt offen, ohne die Header, die Umleitung und das Filtern, die der Proxy davor anwendet.
• Mit einem ungültigen Zertifikat bleibt die PWA halb gelähmt, und einige Funktionen des Browsers schalten sich ab.

Mit dem Reverse Proxy kommst du unter https://meinhaus.duckdns.org ins Panel (Port 443, mit gültigem Zertifikat), und 5001 und 5000 lauschen weiterhin nur zu Hause, und dort gehören sie hin.

Öffne auch nicht 445 (SMB), 2049 (NFS), 3389 oder — außer du weißt sehr genau, was du tust — 22 (SSH). Das sind Protokolle für das lokale Netz; SMB im Internet ist die Tür, durch die die meiste Ransomware in Privathaushalte kommt.

Die Firewall des NAS zählt auch

Wenn du die Firewall eingeschaltet hast (Systemsteuerung → Sicherheit → Firewall), lässt sie ab Werk nur das Panel und SSH durch: Auch wenn der Router weiterleitet, bekommt Apache nichts. Füge zwei Regeln hinzu und fass die Quelle nicht an (sie müssen von jeder IP aus erreichbar sein):

3. DDNS mit DuckDNS, Schritt für Schritt

Fast kein Anbieter für zu Hause gibt eine feste IP: Sie wechselt alle paar Tage oder bei jedem Neustart des Routers. Ein Dienst für dynamisches DNS hält den Namen auf der aktuellen IP. DuckDNS ist kostenlos, verlangt keine Karte und funktioniert gut.

1. Geh auf https://www.duckdns.org und drück einen der Knöpfe sign in with (Google, GitHub, Reddit…). Leg kein neues Passwort an: Nimm das Konto, das du schon hast.
2. Schreib im Kästchen add domain den Namen, den du willst (zum Beispiel meinhaus), und drück add domain. Deine Domain ist meinhaus.duckdns.org.
3. Oben auf der Seite siehst du token: xxxxxxxx-xxxx-…. Kopier ihn. Dieser Token ist das Passwort deiner Domain: Gib ihn nicht weiter und lass ihn nicht auf Screenshots stehen.
4. Auf dem NAS: Systemsteuerung → Externer Zugriff → Dynamische Domain (DDNS). Wähl den Anbieter DuckDNS, schreib die vollständige Domain (meinhaus.duckdns.org), füg den Token ein und lass den Abstand, wie er ist (er nimmt 5 bis 1440 Minuten; unter 5 fangen die Anbieter an, Anfragen abzulehnen). Schalt den Schalter ein und speichere; mit „Jetzt aktualisieren“ prüfst du sofort, dass der Token taugt. Das Panel zeigt die zuletzt veröffentlichte IP und den Fehler der letzten Aktualisierung, falls es einen gab. Die anderen unterstützten Anbieter sind Cloudflare (ein API-Token mit der Berechtigung Zone · DNS · Edit) und No-IP (der Schlüssel aus dem Bereich Dynamic DNS).
5. Prüf, dass es auflöst (vom NAS aus, oder mit nslookup von Windows aus):

getent hosts meinhaus.duckdns.org    # muss deine öffentliche IP zurückgeben
curl -s https://api.ipify.org; echo  # …dieselbe wie diese

Wenn du dafür lieber nicht vom NAS abhängst, schau nach, ob dein Router einen DDNS-Client mit DuckDNS mitbringt: Er aktualisiert die IP auch, wenn das NAS aus ist, und das ist robuster. Der Aufruf, falls du ihn in einem Skript oder für eine Aktualisierung von Hand brauchst, ist:

curl -s "https://www.duckdns.org/update?domains=meinhaus&token=DEIN-TOKEN&ip="
# es antwortet OK (aktualisiert) oder KO (Domain oder Token falsch)

Ein leerer Parameter ip heißt „nimm die IP, von der aus ich dich gerade aufrufe“.

Zwei nützliche Einzelheiten zu DuckDNS: Änderungen brauchen ein paar Minuten, bis sie sich verteilt haben, und jede Subdomain (filme.meinhaus.duckdns.org) löst auf dieselbe IP auf, ohne dass du etwas einrichtest — und genau das erlaubt es, mehrere Apps über ihren Namen zu veröffentlichen (Schritt 5).

Mit einer eigenen Domain ist Schritt 3 gleichwertig: Lass einen A-Eintrag auf deine öffentliche IP zeigen (oder nimm das DDNS deines DNS-Anbieters) und mach ab Schritt 4 genauso weiter.

4. Das Zertifikat ausstellen

Voraussetzungen, alle drei gleichzeitig: Die Domain löst auf deine öffentliche IP auf, der Port 80 kommt beim NAS an und Apache läuft. Bevor du irgendetwas ausstellst, prüf von außerhalb deines Netzes (mobile Daten am Handy, nicht das WLAN zu Hause), dass http://meinhaus.duckdns.org irgendetwas antwortet — und sei es die Standardseite von Apache. Wenn das nicht geht, geht das Zertifikat auch nicht.

Aus der Oberfläche: Systemsteuerung → Externer Zugriff → Zertifikat. Schreib die Domain, eine Kontakt-E-Mail (Let's Encrypt benutzt sie nur, um dich zu warnen, wenn ein Zertifikat abläuft, ohne erneuert zu werden), akzeptier die Bedingungen und drück Zertifikat ausstellen. Sobald es ausgestellt ist, sorgt Im Panel verwenden dafür, dass die Oberfläche selbst es ausliefert: Sie startet ein paar Sekunden neu und kommt über https mit deiner Domain zurück, ohne Warnungen.

Dasselbe über die Konsole, falls du lieber hineinschaust:

sudo certbot --apache -d meinhaus.duckdns.org -m du@mail.de --agree-tos --no-eff-email

Wenn du den Reverse Proxy schon aus dem Panel heraus verwaltest, nimm stattdessen certbot certonly --apache …: --apache allein schreibt die vhosts um, um TLS hinzuzufügen, und würde die überschreiben, die das Panel erzeugt. Mit certonly wird nur das Zertifikat ausgestellt und die Konfiguration bleibt beim Panel.

Was du danach wissen solltest:

• Die Dateien landen in /etc/letsencrypt/live/meinhaus.duckdns.org/ (fullchain.pem und privkey.pem). Verschieb sie nicht: certbot ersetzt sie beim Erneuern.
• Sie laufen nach 90 Tagen ab und erneuern sich von allein. Das Paket installiert einen Timer; prüf ihn mit systemctl list-timers certbot.timer und probe ihn mit sudo certbot renew --dry-run.
• Let's Encrypt begrenzt die fehlgeschlagenen Versuche (5 pro Stunde und Domain). Wenn es scheitert, beheb die Ursache, bevor du es noch einmal versuchst; stur zu wiederholen lässt dich eine Weile gar nichts ausstellen. Zum Ausprobieren nimm --dry-run.

Wenn du das Zertifikat von Hand mit certbot ausgestellt hast, bekommt das Panel davon nichts mit: Es bleibt beim selbst signierten auf 5001, und die Kopie, die du machst, wird alt, sobald certbot erneuert. Dieser Haken beim Ausrollen hält sie aktuell (certbot führt ihn bei jeder wirksamen Erneuerung aus):

sudo tee /etc/letsencrypt/renewal-hooks/deploy/10-lgm-os.sh >/dev/null <<'EOF'
#!/bin/sh
# certbot führt dieses Skript bei jeder wirksamen Erneuerung aus.
D=meinhaus.duckdns.org
cp "/etc/letsencrypt/live/$D/fullchain.pem" /etc/nas/tls/cert.pem
cp "/etc/letsencrypt/live/$D/privkey.pem"  /etc/nas/tls/key.pem
chgrp nas /etc/nas/tls/key.pem && chmod 640 /etc/nas/tls/key.pem
systemctl restart nas-backend
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/10-lgm-os.sh

5. Apps über Unterdomains veröffentlichen (Reverse Proxy)

Die Idee: ein Name pro Dienst, alle kommen über 443 herein, und Apache verteilt sie nach dem Namen, den der Browser verlangt.

Unter Systemsteuerung → Externer Zugriff → Reverse Proxy → Neue Regel, mit einem Dienst pro Regel:

1. Öffentliche Domain: der vollständige Name (filme.meinhaus.duckdns.org).
2. Ziel-Host und Ziel-Port: meist 127.0.0.1 und der Port der App. Die Auswahl der laufenden Container füllt sie für dich aus; wenn die App keinen Port veröffentlicht, schreib sie von Hand.
3. HTTP auf HTTPS umleiten: Lass es an. Wer den Namen ohne https:// tippt, landet trotzdem auf der verschlüsselten Verbindung.
4. Das verwaltete Zertifikat verwenden: an, wenn dieser Name von dem Zertifikat aus Schritt 4 abgedeckt ist.
5. Regel aktiv: Du kannst sie ausgeschaltet lassen und später veröffentlichen, ohne sie zu löschen.

Beim Speichern schreibt das Panel den vhost und lädt Apache neu. Die WebSockets laufen, ohne dass du etwas anfasst (das Installationsprogramm lässt proxy_wstunnel eingeschaltet); genau die brauchen die Terminals im Browser, die Logs in Echtzeit, Home Assistant oder code-server, damit sie nicht ewig auf „verbinden“ stehen bleiben. Zwei Bedingungen pro Name:

• Er muss auflösen: Mit DuckDNS laufen die Subdomains von allein; mit einer eigenen Domain legst du für jede einen CNAME- (oder A-)Eintrag an.
• Er muss ein Zertifikat haben: Die Prüfung über HTTP-01 stellt pro konkretem Namen aus, stell also auch das Zertifikat der Subdomain aus (oder häng sie mit einem weiteren -d an das vorhandene). Ein Platzhalter-Zertifikat *.meinedomain verlangt die Prüfung über DNS-01, und die deckt diese Anleitung nicht ab.

Und eine Regel, die es wert ist, wiederholt zu werden: Die Ports der Apps werden im Router nicht geöffnet. Der Proxy erreicht sie über 127.0.0.1. Über den Proxy zu veröffentlichen und den Port zusätzlich direkt zu öffnen heißt, die Hintertür neben der guten offen zu lassen.

6. Sicherheit (lies das, bevor du den Router anfasst)

Solange das NAS nur in deinem Netz stand, bekam einen Fehler in der Konfiguration nur deine Familie zu sehen. Ab dem Moment, in dem du es veröffentlichst, sieht ihn ein automatischer Scanner in wenigen Stunden: Das ist nicht übertrieben, die Bots probieren /login bei jeder IP mit offenem 443. Das ist das Mindeste:

• Schalt jetzt 2FA ein: Systemsteuerung → Sicherheit → Dein Konto und 2FA. Ohne zweiten Faktor steht zwischen dem Internet und all deinen Daten nur ein Passwort.
• Geh den Sicherheitsberater durch (Systemsteuerung → Sicherheit) und beheb seine Hinweise. Er ist die ehrliche Zusammenfassung davon, wie das Gerät dasteht; veröffentliche nicht, solange kritische Hinweise offen sind.
• IPs sperren eingeschaltet (Sicherheit → IPs sperren). Das Panel begrenzt schon auf 10 Versuche pro Minute und sperrt das Konto nach 5 Fehlern, aber das Sperren nach IP ist das, was das Scannen an der Wurzel abschneidet.
• Firewall eingeschaltet, mit nur 80 und 443 nach außen offen.
• Lange Passwörter, die du nirgendwo sonst benutzt, besonders das des Administrators. Für alle, die nur schauen, leg Benutzer mit der Rolle viewer an.
• Aktualisiere: Systemsteuerung → LGM-OS aktualisieren (apt) und die Aktualisierung des Panels. Ein veröffentlichtes NAS ohne Updates ist eine Frage der Zeit, nicht des Glücks.
• Sicherungen, und mindestens eine abgezogen. Veröffentlichen vervielfacht das Risiko durch Ransomware, und eine angeschlossene Kopie wird mit dem Rest verschlüsselt. Siehe disaster-recovery.md.
• Schau ab und zu ins Audit und auf die verbundenen Benutzer: Dort siehst du die Versuche, hineinzukommen, und von welcher IP.
• Veröffentliche nur das Nötige. Wenn du deine Filme von unterwegs sehen willst, veröffentlich Jellyfin und verwalte das Panel von zu Hause. Jeder veröffentlichte Name ist eine Tür mehr.

Und der ehrliche Vergleich: Am sichersten ist weiterhin, nichts zu veröffentlichen. Ein VPN (WireGuard) gibt dir Zugriff auf das ganze NAS, ohne einen einzigen Dienst im Internet offenzulegen, dafür musst du das VPN auf jedem Gerät verbinden. LGM-OS bringt seinen eigenen WireGuard-Server mit (Systemsteuerung → VPN, mit einem QR-Code fürs Handy), und unter „Deine Verbindung“ kann es den Router bitten, den Port von selbst zu öffnen (UPnP). Für den persönlichen Gebrauch ist das die beste Wahl. Mit Proxy und Zertifikat zu veröffentlichen ist die richtige Wahl, wenn du mit Leuten teilen musst, die sich kein VPN installieren werden.

7. Wenn etwas nicht funktioniert

Über das VPN siehst du alles außer dem Panel

Das verwirrt, weil es aussieht, als schütze sich das NAS vor dir: Das Handy sagt „verbunden“, der Ping geht durch, du kommst auf die anderen Geräte zu Hause… und das Panel sagt diese Website ist nicht erreichbar.

Es ist nicht die Firewall und nicht die Lizenz: Es ist die MTU. Ein Tunnel mit WireGuard ohne angegebene MTU nimmt 1420 Bytes, was über Glasfaser reichlich ist, aber über 4G/5G nicht durchpasst (das Mobilfunknetz und das CGNAT behalten einen Teil des Pakets). Die kleinen Pakete kommen durch — deshalb funktionieren der Ping und fast alles —, und die vollen gehen still verloren. Das Panel ist genau das, was in vollen Paketen reist: der Gruß des TLS mit seinem Zertifikat und danach die ganze Oberfläche.

Die Clients, die LGM-OS anlegt, kommen schon mit MTU = 1280, dem Minimum, das das Internet garantiert. Wenn dein Client älter ist als diese Version, musst du ihn nicht neu machen: Bearbeite die Verbindung in der App von WireGuard und füg diese Zeile unter [Interface] ein.

Befehle zur Diagnose:

sudo apachectl configtest              # ist die Konfiguration von Apache gültig?
sudo systemctl status apache2
sudo journalctl -u apache2 -n 50
sudo tail -f /var/log/apache2/error.log
sudo certbot certificates              # ausgestellte Zertifikate und ihr Ablaufdatum

Die Module von Apache, die der Proxy braucht (proxy, proxy_http, proxy_wstunnel, headers, ssl, rewrite), schalten deploy/install.sh und deploy/update.sh ein. Zum Prüfen:

apache2ctl -M | grep -E 'proxy|headers|ssl|rewrite'