English
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.
Werbung
Werbung
Erstellen einer Reverse Proxy-Regel
Reverse Proxy aufrufen
Öffne in der DSM-Oberfläche die Systemsteuerung.
- Klick auf
Anmeldeportal(1) ->Erweitert(2) ->Reverse Proxy(3)
Neue Reverse-Proxy-Regel erstellen
- Lege dann mit Klick auf „Erstellen“ (1) eine neue Reverse Proxy-Regel an.
Quelle und Ziel festlegen
Hier zeigen wir die Schritte beispielhaft für die Webapp „Wekan“ (ein selbst-gehostetes Kanban-Board) – trage entsprechend für deinen Fall passende Namen/Werte ein:
- Reverse-Proxy-Name (1): Trage einen Namen ein, anhand dessen du die Regel wiedererkennen kannst; in diesem Fall z. B.
Wekan. - Quelle:
- Protokoll (2): Da die Verbindung zum Reverse Proxy, der die Anfrage an die Ziel-Anwendung weiter gibt, verschlüsselt erfolgen soll, wählen wir als Protokoll
HTTPSaus. - Hostname (3): Trage hier den (Sub-)Domainnamen ein, über den du die Webapp im Browser aufrufen möchtest, beispielsweise
wekan.name.synology.me. - Port (4): Damit wir beim Aufrufen der gerade angegebenen Domain nicht noch zusätzlich eine Portnummer angeben müssen, nehmen wir den Standard-HTTPS-Port
443. - HSTS aktivieren (5): Mit dem Haken wird HSTS aktiviert, um sicherzustellen, dass der Browser nur verschlüsselte Verbindungen akzeptiert.
- Protokoll (2): Da die Verbindung zum Reverse Proxy, der die Anfrage an die Ziel-Anwendung weiter gibt, verschlüsselt erfolgen soll, wählen wir als Protokoll
- Ziel:
- Protokoll (6): Die interne Kommunikation auf der Diskstation (zwischen dem Docker-Container und dem Reverse Proxy) erfolgt oft über
HTTP, was du entsprechend hier auswählst.
Manche Docker-Container öffnen für den Aufruf des Webinterfaces aber auch einen HTTPS-Port – in dem Fall sollte man hierHTTPSwählen. - Hostname (7): Betreibst du den Docker-Container auf der selben DiskStation (was der Normalfall sein sollte), dann gibst du hier mit
localhostan, dass die von außen kommende Anfrage an die DiskStation selbst weitergeleitet werden soll. - Port (8): Hier trägst du die interne Portnummer ein, unter der deine Web-Anwendung (in diesem Fall Wekan) erreichbar ist. Diesen Port des Docker-Containers legst du in der Regel in Portainer in der Docker-compose-Datei fest. Im Beispiel wurde für Wekan in Portainer der interne Port
18431festgelegt und daher hier entsprechend eingetragen.
- Protokoll (6): Die interne Kommunikation auf der Diskstation (zwischen dem Docker-Container und dem Reverse Proxy) erfolgt oft über
- Nach der Eingabe der Einstellungen wird die Konfiguration durch Klick auf „Speichern“ (9) abgeschlossen.
Reverse-Proxy-Regel erfolgreich angelegt
In der Liste der Reverse-Proxy-Regeln sehen wir, dass die neue Regel erfolgreich angelegt wurde und nun aktiv ist.
Reverse Proxy: 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, dass der konkrete Docker-Container keine WebSockets nutzt, kannst du diesen Abschnitt überspringen.
Vorhandene Regel bearbeiten
Klicke mit einem Rechtsklick auf die neu angelegte Regel (1) und wähle „Bearbeiten“ (2).
WebSocket Kopfzeilen hinzufügen
Klicke im Tab „Benutzerdefinierte Kopfzeile“ (1) auf „Erstellen“ (2) und anschließend auf „WebSocket“ (3).
Regel mit angelegten WebSocket Headern
Dadurch werden automatisch die zwei Header „Upgrade“ und „Connection“ hinzugefügt.
Änderung speichern
Anschließend klickst du auf „Speichern“ (1) und hast damit die Reverse Proxy-Regel um die benötigten Websocket-Kopfzeilen ergänzt.
Wenn dich interessiert, wie der Reverse Proxy die eingehenden Anfragen bearbeitet, findest du im folgenden Abschnitt eine grundlegende Erklärung des Funktionsprinzips eines Reverse Proxy inklusive konkreter Beispiele.
Hintergrundinfo zu Zentralisierung
DDNS
Synology bietet über deren Server für Nutzer*innen einer Diskstation einen kostenlosen DDNS-Dienst. Richtet man diesen ein, erhält man eine Subdomain in der Form „name.synology.me“ (dabei ist „name“ dein selbst gewählter Subdomain-Name).
- Die entsprechende Einstellung findet man in der DSM-Oberfläche unter
Systemsteuerung->Externer Zugriff(1) ->DDNS(2). - 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 den externen Synology-Servern für „name.synology.me“ hinterlegt (siehe (3) im linken Screenshot).
- Über die von Synology bereitgestellte Subdomain „name.synology.me“ können wir dann – trotz wechselnder IP-Adressen – auf die Diskstation zugreifen.
Wildcard-Zertifikat für Subdomain
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“. Wie man ein Wildcard-Zertifikat für die Nutzung von Subdomains anlegt, erklären wir übrigens in diesem Artikel: Subdomains über HTTPS auf der Diskstation verwenden: Wildcard-Zertifikat anlegen (*.name.synology.me)
- 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 folgendem Befehl (1) ganz einfach nachprüfen:
ping name.synology.me
- 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.
ping name.synology.me
ping portainer.name.synology.me
ping pdf.name.synology.me
ping wekan.name.synology.meDas Wildcard-Zertifikat sorgt also dafür, dass wir beim Aufruf jeder beliebigen Sub-Subdomain auf der IP-Adresse der Diskstation landen.
Portnummern
Hast du mehrere Reverse Proxy-Regeln gemäß der obigen Anleitung angelegt, dann kannst du auf die einzelnen Sub-Subdomains mit der Portnummer 443 zugreifen, z. B. indem du im der Browser-Adresszeile https://portainer.name.synology.me:443 eingibst. Da es sich beim Port 443 um den Standard-HTTPS-Port handelt, reicht es, das https:// am Anfang anzugeben; die Portnummer hinten kann dann weggelassen werden. Du kannst also beispielsweise genauso gut die Adresse https://portainer.name.synology.me nutzen.
Zwischenfazit
Bisher können wir also zusammenfassen:
- Egal welche Sub-Subdomain wir aufrufen, wir landen immer auf der selben IP-Adresse, nämlich auf der von der Diskstation.
- Die unterschiedlichen Anfragen an die Diskstation bzw. den Reverse Proxy gehen alle an den Port 443 (Default-HTTPS-Port).
Wenn bei unterschiedlichen Anfragen (z. B. portainer.name.synology.me und pdf.name.synology.me) sowohl die IP-Adresse, als auch die Portnummer gleich sind, woher „weiß“ der Reverse Proxy dann, welche der Webapps bzw. Dienste (also z. B. Portainer oder das PDF-Tool ‚Stirling‘) aufgerufen wurde?
Host Anfrage-Header
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
Schreibe einen Kommentar