Posted

in

,

Updated

Reverse Proxy der Synology DiskStation: Web-Apps sicher per HTTPS aus dem Internet zugänglich machen

Viele Nutzer*innen lassen auf ihrer Synology Diskstation auch Webanwendungen laufen, wie z. B. Portainer, Wekan oder Nextcloud. Diese per Docker-Container installierten Anwendungen möchte man meistens auch über eine sichere Verbindung per HTTPS aus dem Internet erreichen. Um Anfragen von Außerhalb in das lokale Heimnetzwerk zu leiten, kann man den Reverse Proxy-Server von Synology verwenden.

Was macht ein Reverse Proxy?

Der Reverse Proxy auf der Synology Diskstation kann mehrere Funktionen übernehmen:

  • SSL/TLS-Verschlüsselung: Greift man im lokalen Heimnetz auf Dienste oder Webapps zu, die man selbst auf der Diskstation installiert hat, passiert das meist unverschlüsselt per HTTP. Außerhalb des Heimnetzwerks sollte man nie per HTTP zugreifen, da die Daten sonst unverschlüsselst über das Internet übertragen werden. Der Reverse Proxy kann den Datenverkehr vom Internet bis zum Reverse Proxy sichern, indem er eine SSL/TLS-Verschlüsselung bereitstellt. Die interne Weiterleitung des Traffics an den Dienst/Webservice erfolgt dann unverschlüsselt. Insgesamt ist es so nicht unbedingt nötig, dass die Webanwendung selbst eine SSL/TLS-Verschlüsselung bereitstellt.
  • URL-Umschreibung: Im Heimnetzwerk öffnest du einzelne Webanwendungen, indem du die lokale IP-Adresse der Diskstation gefolgt von der Portnummer des Docker-Containers in die Browser-Adresszeile eingibst, z. B. http://192.168.0.10:18431. Beim Zugriff über das Internet müssen wir uns dank der URL-Umschreibung des Reverse Proxy diese Portnummern nicht merken und können stattdessen mit einer Subdomain auf den Dienst zugreifen, z. B. https://wekan.name.synology.me
  • Zentralisierung/Port-Weiterleitung: Der externe Zugriff auf die verschiedenen Dienste und Anwendungen auf der Diskstation kann mithilfe eines Reverse Proxy-Servers über eine einzige IP-Adresse und einenen einzigen Port erfolgen. Im Router des Heimnetzes muss für den Zugriff von Außen daher auch nur eine einzige Portweiterleitung eingerichtet werden, z. B. der HTTPS-Port 443 auf die lokale IP-Adresse der Diskstation. Installiert man weitere Webanwendungen und legt dafür zusätzliche Reverse Proxy-Regeln an (siehe unten), ist es nicht nötig, entsprechende Portfreigaben einzurichten, da die allgemeine Portfreigabe für den Reverse Proxy reicht. Das macht die Konfiguration einfacher und eventuell auch sicherer, da weniger Ports nach außen geöffnet werden müssen. Weitere Hintergrundinfos zur Zentralisierungs-Funktion mit entsprechenden Beispielen findest du im Abschnitt weiter unten.

Reverse Proxy anlegen

Erstellen einer Reverse Proxy-Regel

Öffne in DSM die Systemsteuerung.

  • Klick auf Anmeldeportal (1) -> Erweitert (2) -> Reverse Proxy (3)
  • Dann legen wir mit Klick auf „Erstellen“ eine neue Reverse Proxy-Regel an. Hier zeigen wir die Schritte beispielhaft für die Webapp des Kanban-Boards „Wekan“ – trage entspreched für deinen Fall passende Namen/Werte ein:
  1. Reverse-Proxy-Name (1): Der Name „Wekan“ wird als Bezeichner für die Regel verwendet.
  2. Quelle:
    • Protokoll (2): HTTPS wird als Protokoll gewählt, da die Kommunikation mit der Anwendung über eine verschlüsselte Verbindung erfolgen soll.
    • Hostname (3): wekan.name.synology.me ist der Domainname, der als externe Adresse dient.
    • Port (4): Der HTTPS-Port 443 wird verwendet.
    • HSTS aktivieren (5): Hier wird HSTS aktiviert, um sicherzustellen, dass der Browser nur verschlüsselte Verbindungen akzeptiert.
  3. Ziel:
    • Protokoll (6): Die interne Kommunikation erfolgt über HTTP.
    • Hostname (7): localhost zeigt, dass die Anfrage an den Server selbst (die DiskStation) weitergeleitet wird.
    • Port (8): Die Anwendung „Wekan“ läuft auf dem internen Port 18431.
  4. Nach der Eingabe der Einstellungen wird die Konfiguration durch Klicken auf „Speichern“ (9) abgeschlossen.

Die neue Regel ist erfolgreich angelegt worden.

Benutzerdefinierte Kopfzeilen hinzufügen

Manche Docker-Container nutzen sogenannte WebSockets zur Client-Server-Kommunikation. Damit das funktioniert, müssen wir der Reverse Proxy-Regel entsprechende Header/Kopfzeilen hinzufügen. Bist du dir unsicher, ob der dahinterliegende Docker-Container WebSockets nutzt? Dann kannst du sie zur Sicherheit einfach hinzufügen, denn grundsätzlich sollte der Docker-Container diese ignorieren, wenn sie nicht benötigt werden. Bist du dir sicher bist, dass der konkrete Docker-Container keine WebSockets nutzt, kannst du diesen Schritt überspringen.

Klicke mit einem Rechtsklick auf die neu angelegte Regel (1) und wähle „Bearbeiten“ (2).

Klicke im Tab „Benutzerdefinierte Kopfzeile“ (1) auf „Erstellen“ (2) und anschließend auf „WebSocket“ (3).

Dadurch werden automatisch die zwei Header „Upgrade“ und „Connection“ hinzugefügt. Anschließend klickst du auf „Speichern“ (1) und hast damit die Reverse Proxy-Regel fertig angelegt.

Wenn dich interessiert, wie der Reverse Proxy die eingehenden Anfragen bearbeitet, findest du im folgenden Abschnitt eine grundlegende Erklärung inklusive Beispielen.

Hintergrundinfo zu Zentralisierung

Wir nutzen die von Synology bereitgestellte Subdomain „name.synology.me“ (dabei ist „name“ dein selbst gewählter Subdomain-Name) für den Zugriff auf die Diskstation. Zusätzlich haben wir ein Wildcard-Zertifikat angelegt, sodass wir auch jede beliebige Sub-Subdomain per HTTPS nutzen können, z. B. „portainer.name.synology.me“, „pdf.name.synology.me“ oder „wekan.name.synology.me“.

Immer wenn sich die über das Internet erreichbaren dynamischen IP-Adressen (IPv4 und IPv6) der Diskstation (bzw. des Routers) ändern, werden diese per DDNS aktualisiert und auf dem Synology-Server für „name.synology.me“ hinterlegt.

Ruft man die Adresse „name.synology.me“ auf, wird der Aufruf also auf die zuletzt übermittelte IP-Adresse (z. B. in die IPv6-Adresse 2a02:f1c2:0fcf:792a:acaf:6290:6b28:8cee) aufgelöst. Das können wir in der Windows PowerShell mit einem einfachen ping name.synology.me prüfen:

Aber auch alle Sub-Subdomains, wie z. B. „portainer.name.synology.me“, „pdf.name.synology.me“ oder „wekan.name.synology.me“, werden zu genau dieser IP-Adresse (hier z. B. 2a02:f1c2:0fcf:792a:acaf:6290:6b28:8cee) aufgelöst.

Sind die passenden Reverse Proxy-Regeln angelegt und greift man dann per HTTPS auf eine der Sub-Subdomains zu, landet man immer bei dieser einen IP-Adresse, nämlich die IP-Adresse der Diskstation. Der Zugriff auf den Port 443 (HTTPS-Protokoll) wird auf der Diskstation dann vom Reverse Proxy-Server bearbeitet und beantwortet.

Alle solche Anfragen an den Reverse Proxy wurden also an die selbe IP-Adresse und die selbe Portnummer gestellt. Aber woher „weiß“ der Reverse Proxy dann, welche der Webapps bzw. Dienste (also z. B. Portainer, das PDF-Tool ‚Stirling‘ oder das Kanban-Board ‚Wekan‘) aufgerufen wurde?

Rufst du z. B. die Sub-Subdomain portainer.name.synology.me im Browser auf, dann sendet dieser einen GET-Request an die dahinter liegende IP-Adresse (hier z. B. 2a02:f1c2:0fcf:792a:acaf:6290:6b28:8cee) und sendet dabei den Anfrage-Header „Host: portainer.name.synology.me“ mit. Der Reverse Proxy erhält diese Anfrage und wertet den übermittelten Anfrage-Header aus. Anhand dieser Angabe und der hinterlegten Reverse Proxy-Regeln weiß der Reverse Proxy dann, an welche URL er diese Anfrage im lokalen Heimnetz „weiterleiten“ muss, nämlich z. B. an den ebenfalls auf der Diskstation laufenden Dienst unter http://192.168.0.10:18431.

Dass der Host-Header die entscheidende Angabe ist, kann man folgendermaßen sehen: Wir machen zwei GET-Requests, jeweils an die Adresse „https://portainer.name.synology.me“ (roter Rahmen). Im ersten Request senden wir den („passenden“) Host-Header „portainer.name.synology.me“ (grüner Rahmen) mit und erhalten die Startseite von Portainer (lila Rahmen):

Im zweiten Request senden wir wieder an die Adresse „https://portainer.name.synology.me“ (roter Rahmen), diesmal aber den („unpassenden“) Host-Header „pdf.name.synology.me“ (grüner Rahmen) mit und erhalten die Startseite von Stirling-PDF (lila Rahmen):

Es ist also theoretisch völlig egal, an welche der Sub-Subdomains wir unseren Request senden, so lange der Host-Header die gewünschte Domain enthält. Rufen wir eine der Sub-Subdomains mit einem Browser auf, setzt dieser den Host-Header automatisch auf die angefragte Adresse, sodass wir auch den erwarteten Webservice als Antwort erhalten.


Titelbild erstellt mit Unterstützung von Microsoft Copilot

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert