UGREEN NAS: Nginx Proxy Manager mit Docker einrichten

Laufen auf Ihrer UGREEN NAS mehrere Dienste in Docker, hat jeder seinen eigenen Port: 8097, 3001, 8080. Ein Reverse Proxy ordnet stattdessen jedem Dienst einen Namen zu, etwa fotos.example.de oder kuma.example.de, und erledigt HTTPS für alle an einer Stelle. Der Nginx Proxy Manager, hier in Version 2.16.0, macht das über eine Weboberfläche, ohne dass Sie nginx-Dateien von Hand schreiben. Diese Anleitung richtet ihn mit Docker ein, legt einen Proxy Host mit Zertifikat an und beschränkt den Zugriff auf Ihr Heimnetz.

Voraussetzungen

• Eine UGREEN NAS mit der App Docker und fester IP-Adresse, siehe Teil 63 und Teil 9
• SSH-Zugang, siehe Teil 52
• Namen, die auf die NAS zeigen: im Heimnetz über einen DNS-Server wie Pi-hole, siehe Teil 71, oder über die DNS-Einträge Ihrer Domain
• Etwa 40 Minuten

Schritt 1: Ports prüfen und den Ordner anlegen

Der Proxy braucht die Ports 80 und 443 der NAS, sonst müssten Sie an jede Adresse einen Port anhängen. UGOS selbst nutzt für seine Oberfläche die Ports 9999 und 9443. Prüfen Sie, ob 80, 443 und 81 frei sind:

sudo ss -tlnp | grep -E ':(80|443|81) '

Gibt der Befehl nichts aus, sind die Ports frei. Belegt sie ein anderer Container, etwa ein älterer Webserver, müssen Sie ihn zuerst umziehen. In der Systemsteuerung unter Geräteverbindung, Portaleinstellungen gibt es außerdem den Haken Port 80 auf den HTTP-Port umleiten. Er stand bei uns auf aus. Lassen Sie ihn aus, denn laut Beschriftung leitet UGOS damit Port 80 auf seine eigene Oberfläche um.

sudo mkdir -p /volume2/docker/npm/data /volume2/docker/npm/letsencrypt
cd /volume2/docker/npm
sudo chmod 700 data letsencrypt
sudo ugacltool getace data

It's Linux mode

In data liegen die Datenbank, alle privaten Schlüssel und gegebenenfalls Zugangsdaten für Ihren DNS-Anbieter. Neue Ordner unter docker erben in UGOS Rechte, die auch der Gruppe admin Zugriff geben. Mit chmod 700 darf nur noch root hinein, und der Container läuft als root. Der Nginx Proxy Manager lief bei uns damit auch nach einem Neustart weiter. Liegt Ihr Docker-Ordner auf einem anderen Volume, passen Sie /volume2 an. Mehr zu den Rechten in Teil 65.

Verifizieren: ls -ld data letsencrypt zeigt bei beiden drwx------ und root.

Schritt 2: Die Compose-Datei schreiben und starten

sudo nano compose.yaml

services:
  npm:
    image: jc21/nginx-proxy-manager:2.16.0
    container_name: npm
    environment:
      - TZ=Europe/Berlin
    ports:
      - "192.168.1.10:80:80"
      - "192.168.1.10:443:443"
      - "192.168.1.10:81:81"
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    restart: unless-stopped
  whoami:
    image: traefik/whoami:v1.12.0
    container_name: whoami
    restart: unless-stopped

Ersetzen Sie 192.168.1.10 durch die Adresse Ihrer NAS. Port 81 ist die Verwaltungsoberfläche, 80 und 443 nehmen die Anfragen für Ihre Dienste an. Der zweite Dienst whoami ist ein winziger Testserver, der jede Anfrage mit ihren Kopfzeilen beantwortet. Damit prüfen Sie den ersten Proxy Host, bevor Sie echte Dienste anschließen, und entfernen ihn danach wieder. Die feste Versionsnummer verhindert ungeplante Updates, siehe Teil 69.

sudo docker compose up -d
sleep 30
sudo docker logs npm 2>&1 | tail -3

[IP Ranges] › ℹ  info      IP Ranges Renewal Timer initialized
[SSL      ] › ℹ  info      Completed SSL cert renew process
[Global   ] › ℹ  info      Backend PID 228 listening on port 3000 ...

Der erste Start dauert etwa eine halbe Minute. Vor jeder Zeile steht noch Datum und Uhrzeit, hier weggelassen.

Verifizieren: curl -s -o /dev/null -w "%{http_code}\n" http://192.168.1.10:81/ liefert 200.

Schritt 3: Das Administratorkonto anlegen

Öffnen Sie http://192.168.1.10:81 und legen Sie das Konto sofort an. Bis dahin kann jeder im Netz, der Port 81 erreicht, das Administratorkonto selbst anlegen. Ältere Anleitungen nennen ein Standardkonto mit fester E-Mail-Adresse und festem Passwort. Bei einer neuen Installation der Version 2.16.0 gab es keins mehr, sie fragte beim ersten Aufruf direkt nach einem neuen Konto:

Steht die Oberfläche auf Englisch, stellen Sie über die Flagge oben rechts Deutsch ein. Vergeben Sie ein langes Passwort, dieses Konto kann alle Weiterleitungen und Zertifikate ändern. Nach der Anmeldung sehen Sie das Dashboard:

Verifizieren: Das Dashboard zeigt 0 Proxy Hosts, und oben rechts steht Ihr Name mit der Rolle Administrator.

Schritt 4: Den ersten Proxy Host anlegen

Klicken Sie auf Hosts, Proxy Hosts und dann auf Proxy Host hinzufügen:

• Domain Names: der Name, unter dem der Dienst erreichbar sein soll. Tippen Sie ihn ein und bestätigen Sie mit Enter.
• Schema: http, auch wenn Sie später HTTPS nutzen. Gemeint ist die Verbindung vom Proxy zum Dienst auf der NAS.
• Forward Hostname / IP: das Ziel. Für Container im selben Compose-Projekt genügt der Containername, hier whoami.
• Forward Port: der Port im Container, bei whoami 80. Das ist nicht unbedingt der Port, den der Container nach außen freigibt.
• Gängige Exploits blockieren: filtert offensichtliche Angriffe. Eine Anfrage mit <script> in der Adresse beantwortete der Proxy bei uns danach mit 403.

Nach Speichern steht der Host in der Liste mit dem Status Online. Das Bild zeigt ihn schon mit Zertifikat und Zugriffsliste aus Schritt 6 und 7:

Testen Sie ihn von Ihrem Rechner aus, auch bevor der Name im DNS existiert. curl ist unter Windows, macOS und Linux vorhanden und schickt den Namen dabei als Kopfzeile mit:

curl -s -H "Host: app.example.de" http://192.168.1.10/ | grep -E "^(Hostname|Host|X-)"

Hostname: c74df20c0509
Host: app.example.de
X-Forwarded-For: 192.168.1.20
X-Forwarded-Proto: http
X-Forwarded-Scheme: http
X-Real-Ip: 192.168.1.20

whoami zeigt, was beim Dienst ankommt. Die Kopfzeilen X-Forwarded-For und X-Real-Ip enthalten die Adresse des anfragenden Rechners, nicht die des Proxys. Dienste, die Anmeldungen protokollieren oder Adressen sperren, sehen so die echte Quelle. Ein Name ohne Proxy Host landet auf der Standardseite des Nginx Proxy Manager mit dem Titel Congratulations.

Verifizieren: Die Ausgabe enthält Host: app.example.de und die Adresse Ihres Rechners bei X-Real-Ip.

Schritt 5: Andere Container und Dienste anbinden

Den Containernamen kennt der Proxy nur für Container im selben Docker-Netz. Für alle anderen Dienste tragen Sie als Ziel die IP-Adresse der NAS und den freigegebenen Port ein, etwa 192.168.1.10 und 3001 für Uptime Kuma. Aus dem Container heraus erreichte der Proxy bei uns Dienste über die IP-Adresse der NAS ohne weitere Einstellungen. Stimmt das Ziel nicht, antwortet der Proxy mit 502 Bad Gateway. Den Grund schreibt er ins Fehlerprotokoll des Proxy Hosts. In der Oberfläche finden Sie es unter Hosts, Proxy Hosts, Menü mit den drei Punkten, Logs, Reiter Error, auf der NAS unter data/logs. Bei uns stand dort nach dem Stoppen von whoami:

whoami could not be resolved (3: Host not found)

Läuft Ihr erster echter Dienst, löschen Sie den Abschnitt whoami aus der Datei compose.yaml und entfernen den Container mit sudo docker compose up -d --remove-orphans.

Verifizieren: Für jeden Dienst liefert der curl-Test aus Schritt 4 mit dessen Namen eine Seite des Dienstes, keine 502.

Schritt 6: Ein Zertifikat hinterlegen

Unter Zertifikate, Zertifikat hinzufügen bietet der Nginx Proxy Manager drei Wege an:

• Let's Encrypt via HTTP: Laut Let's Encrypt ruft der Dienst dafür Ihren Namen über Port 80 aus dem Internet auf. Das setzt einen öffentlichen DNS-Eintrag auf Ihre Internetadresse und eine Portfreigabe für Port 80 voraus, siehe Teil 45 und Teil 51.
• Let's Encrypt via DNS: Der Nachweis läuft über einen Eintrag beim DNS-Anbieter. Das klappt laut Let's Encrypt ohne offene Ports und auch für Platzhalter wie *.example.de, mehr dazu bei den häufigen Fragen.
• Benutzerdefiniertes Zertifikat: ein Zertifikat, das Sie selbst erzeugt haben, etwa mit einer eigenen Zertifizierungsstelle wie in Teil 46.

Für ein Netz ohne Zugang von außen nehmen wir den dritten Weg:

Den Schlüssel darf kein Passwort schützen, darauf weist der Dialog selbst hin. Das Zertifikat muss den Namen als alternativen Namen enthalten, und für den curl-Test unten brauchen Sie die Datei heim-ca.crt Ihrer Zertifizierungsstelle auf dem Rechner. Nach Speichern steht das Zertifikat mit Ablaufdatum und dem Status Nicht in Benutzung in der Liste. Öffnen Sie den Proxy Host über das Menü mit den drei Punkten und Bearbeiten, Reiter SSL:

Mit Erzwinge SSL antwortet der Proxy auf HTTP mit einer Weiterleitung, Code 301, auf dieselbe Adresse mit https. HSTS lassen Sie zunächst aus. Browser merken sich HSTS für die angegebene Zeit und rufen den Namen so lange nur noch per HTTPS auf, ein Fehler lässt sich deshalb nicht schnell zurücknehmen. Prüfen Sie das Ergebnis:

curl -s --cacert heim-ca.crt --resolve app.example.de:443:192.168.1.10 https://app.example.de/ | grep X-Forwarded-Proto

X-Forwarded-Proto: https

Verifizieren: curl -sI -H "Host: app.example.de" http://192.168.1.10/ zeigt HTTP/1.1 301 und eine Location mit https.

Schritt 7: Den Zugriff auf das Heimnetz beschränken

Ist ein Dienst nur für zu Hause gedacht, sperren Sie alles andere aus. Unter Zugriffslisten legen Sie eine Liste an, Reiter Details mit einem Namen wie Nur Heimnetz, dann Reiter Regeln:

Tragen Sie Ihr Heimnetz in der Schreibweise mit Schrägstrich ein, etwa 192.168.1.0/24 für alle Adressen von 192.168.1.0 bis 192.168.1.255. Sobald eine Regel existiert, hängt der Nginx Proxy Manager selbst Verweigern all an. Wählen Sie die Liste danach im Proxy Host im Feld Zugriffsliste aus, Reiter Details. Bei uns kamen Anfragen vom Rechner im Heimnetz weiter durch. Eine Anfrage aus einem Docker-Container bekam dagegen 403, im Fehlerprotokoll stand:

access forbidden by rule, client: 172.16.11.1, server: app.example.de

Die Absenderadresse war hier das Gateway des Docker-Netzes, nicht eine Adresse aus dem Heimnetz. Die genaue Adresse hängt vom Docker-Netz ab. Kommen Anfragen über einen anderen Container auf der NAS, etwa ein VPN im Container, prüfen Sie im Fehlerprotokoll, mit welcher Adresse sie ankommen, und nehmen Sie genau diese als weitere Erlauben-Regel auf. Erlauben Sie das Docker-Gateway, kommen damit allerdings alle Container der NAS durch.

Verifizieren: Vom Rechner im Heimnetz liefert der Dienst weiter seine Seite. Eine Anfrage aus einem Container auf der NAS bekommt 403 Forbidden, und im Fehlerprotokoll steht access forbidden by rule.

Typische Fehler

• 502 Bad Gateway: Ziel oder Port falsch, oder der Container läuft nicht. Der Grund steht im Protokoll des Proxy Hosts, siehe Schritt 5.
• Der Container startet nicht, Port belegt: Ein anderer Dienst nutzt 80 oder 443, siehe Schritt 1.
• Standardseite Congratulations statt des Dienstes: Der aufgerufene Name steht in keinem Proxy Host, oder Sie rufen die IP-Adresse statt des Namens auf.
• 403 Forbidden: Die Zugriffsliste blockiert die Absenderadresse. Prüfen Sie im Protokoll, mit welcher Adresse die Anfrage ankam, und ergänzen Sie die Regel.
• Weiterleitung auf HTTPS verliert den Port: Erzwinge SSL leitet auf https ohne Portnummer um. Läuft der Proxy nicht auf 443, landet der Browser auf Port 443, wo ein anderer Dienst oder gar nichts antwortet. Nutzen Sie deshalb die Ports 80 und 443 wie in Schritt 2.
• HTTPS über die IP-Adresse scheitert mit unrecognized name: Der Proxy kennt nur Namen. Rufen Sie den Dienst über seinen Namen auf.

Häufige Fragen

Wie bekomme ich ein Zertifikat von Let's Encrypt ohne offene Ports?

Über Let's Encrypt via DNS. Sie wählen Ihren DNS-Anbieter, und der Nginx Proxy Manager legt den Nachweis laut Dialog über ein Plugin von Certbot selbst als DNS-Eintrag an. Dafür hinterlegen Sie Zugangsdaten des Anbieters:

Der Dialog warnt selbst, dass diese Daten im Klartext in der Datenbank und in einer Datei landen. Das ist ein Grund für chmod 700 in Schritt 1. Wählen Sie beim Anbieter, wenn möglich, Zugangsdaten mit Rechten nur für DNS. Achten Sie auch darauf, für welche Schnittstelle das Plugin gebaut ist. Die Vorlage für netcup fragte bei uns nach Kundennummer, API-Schlüssel und API-Passwort, also nach den Zugangsdaten der älteren netcup-Schnittstelle, nicht nach einem Schlüssel für die neue REST-API aus Teil 45.

Ersetzt der Nginx Proxy Manager das Zertifikat von UGOS?

Nein. Er gilt nur für die Dienste, die Sie über ihn aufrufen. Die Oberfläche von UGOS auf 9999 und 9443 behält ihr eigenes Zertifikat, siehe Teil 46.

Wie sichere ich den Nginx Proxy Manager?

Stoppen Sie den Container und packen Sie die Ordner data und letsencrypt mit der Compose-Datei ein:

cd /volume2/docker/npm
sudo docker compose stop npm
sudo tar -czf /volume1/Sicherung/npm.tar.gz data letsencrypt compose.yaml
sudo docker compose start npm

Beim Zurückspielen mit tar -xzf legt tar die Ordner neu an, und UGOS gibt ihnen wieder seine geerbten Rechte. Bei uns stand danach drwxrwxrwx+ statt drwx------. Führen Sie deshalb nach jeder Wiederherstellung sudo chmod 700 data letsencrypt aus. Danach waren bei uns Konto, Proxy Hosts, Zertifikat und Zugriffsliste vollständig zurück.

Soll ich Port 443 im Router freigeben?

Nur wenn Dienste wirklich öffentlich erreichbar sein müssen. Dann ist der Nginx Proxy Manager das Einzige, was von außen antwortet, und die Zugriffslisten werden wichtig. Port 81 mit der Verwaltungsoberfläche geben Sie nie frei. Für den Zugriff nur von Ihnen selbst ist ein VPN der sicherere Weg, siehe Teil 48.

Fazit

Der Nginx Proxy Manager bringt Ordnung in viele Docker-Dienste auf der UGREEN NAS: ein Name je Dienst, HTTPS an einer Stelle und auf Wunsch nur aus dem Heimnetz erreichbar. Mit dem Testserver whoami sehen Sie sofort, was beim Dienst ankommt. Schützen Sie den Datenordner mit chmod 700, denn dort liegen alle Schlüssel und Zugangsdaten.

Weiterführende Anleitungen und Quellen

• Teil 64: Erstes Docker-Compose-Projekt anlegen
• Teil 65: Ordner und Rechte für Container
• Teil 71: Pi-hole einrichten
• Nginx Proxy Manager auf dem Synology NAS
• Nginx Proxy Manager: Anleitung
• traefik/whoami auf GitHub