Synology Port-Weiterleitung

Hot Dog

Lieutenant
Registriert
Mai 2007
Beiträge
940
Hi,

Ich habe da eine kleine Frage bezüglich meiner Synology Diskstation1821+.
Hab bei meinem Web-Provider Strato DynDNS aktiviert, damit ich mit meiner gemieteten Domain auf mein NAS zuhause zugreifen kann. D.h. Strato leitet DOMAIN-NAME.de an die öffentliche IP meiner Fritzbox weiter. So weit so gut.
Nun habe ich in der Fritzbox eine Weiterleitung auf das NAS eingerichtet. D.h. DOMAIN-NAME.de leitet über Port 443 an die interne IP des NAS weiter. So weit so gut.

Wenn ich nun im Browser DOMAIN-NAME.de eingebe, lande ich bei DOMAIN-NAME.de:5001 (https) und damit im Synology-NAS Anmeldungsportal, also womit man sich einloggen kann und Zugriff auf das NAS erhält. Dies möchte ich allerdings nicht!
DOMAIN-NAME.de soll an die eigens gehostete Website weiter leiten und NUR DOMAIN-NAME.de/nas (5001) soll im NAS-Anmeldeportal landen. Wie stelle ich das an?

Da der Text etwas verwirrend ist, hier nochmal eine Übersicht:
  • STRATO -> DOMAIN-NAME.de -> Fritzbox (öffentliche IP) -> Weiterleitung an interne NAS-IP (443)
  • Ergebnis: Ich lande bei NAS-IP (5001) <- eben der Port, der für die Anmeldung gesetzt wurde. Warum? Ist das so ein Standard-Ding, da 443 ein Standard-Port ist? Laut der Synology-Dienst-Übersicht wird Port 443 für absolut nichts verwendet und die Anfrage sollte eigentlich ins Leere gehen. Tut sie aber nicht.
Mein Ziel ist:
  • DOMAIN-NAME.de (Port weiß ich noch nicht) -> Website in der Zukunft irgendwann (momentan soll es einfach ins Leere laufen)
  • DOMAIN-NAME.de/nas (5001) -> NAS-Anmeldung
  • DOMAIN-NAME.de/cloud (5002) -> NAS-Cloud-Anmeldung
  • usw.
Bitte nicht falsch verstehen, es läuft bereits alles (Cloud, NAS-Anmeldung, usw). Es geht lediglich um die merkwürdige Weiterleitung nach 5001, welche so eigentlich nicht stattfinden sollte.

Danke euch schonmal!
HD
 
Zuletzt bearbeitet:
Hot Dog schrieb:
  • DOMAIN-NAME/nas.de (5001) -> NAS Anmeldung
  • DOMAIN-NAME/cloud.de (5002) -> NAS
Alternativ:

storage.example.com
cloud.example.com
Ne Option?


Hot Dog schrieb:
Ich lande bei NAS-IP (5001) <- eben der Port, der für
Auf welchem Port läuft der Webserver denn auf der synology?

Wonach du suchst nennt sich reverse proxy
Hier ist die synology Doku dazu
 
  • Gefällt mir
Reaktionen: Hot Dog
madmax2010 schrieb:
Alternativ:
storage.example.com
cloud.example.com
Ne Option?
Ja, wenn es das einfacher macht, wieso nicht. Hat das denn Vorteile im Vergleich zur Vergabe von Aliassen (example.com/nas bzw. example.com/cloud...usw)?
Wenn ich das richtig verstehe wird:
  • BLABLABLA.example.com mittels Subdomains beim Provider (Strato) bewerkstelligt und
  • example.com/BLABLABLA wird mittels NAS-Aliassen mit dem NAS selbst bewerkstelligt.
    Was ist hier allgemein besser bzw. zu empfehlen?
madmax2010 schrieb:
Auf welchem Port läuft der Webserver denn auf der synology?
Momentan läuft noch kein Webserver, darum ist auch noch kein Port dafür vergeben. Das ist für die Zukunft irgendwann mal geplant, wenn ich eine Verwendung für eine eigene Website habe.
madmax2010 schrieb:
Wonach du suchst nennt sich reverse proxy
Hier ist die synology Doku dazu
Super danke dir. Gut zu wissen. Aber nur damit ich dich richtig verstehe, das geht nur mit Subdomains und nicht mit Aliassen richtig?
 
Zuletzt bearbeitet:
Ich würde quickconnect.to (synology) nutzen für externen Zugriff
 
Giggity schrieb:
Ich würde quickconnect.to (synology) nutzen für externen Zugriff
Das setzt soweit ich weiß einen Synology-Account voraus.
Aber wozu sollte man das nutzen? Hab doch bereits DynDNS und einen Reverse Proxy kann man ja auch einrichten. Was sollte da Quick Connect noch bringen? Soweit ich weiß, dient das nur zur Verbindung zum NAS-Login. Ich möchte aber auch eine Verbindung zur NAS-Cloud und weiteren Diensten haben.
 
Hot Dog schrieb:
Momentan läuft noch kein Webserver, darum ist auch noch kein Port dafür vergeben.
das webinterface, welches du unter 5001 erreichst, ist ziemlich sicher durch einen Webserver ausgeliefert.

Hot Dog schrieb:
  • BLABLABLA.example.com mittels Subdomains beim Provider (Strato) bewerkstelligt und
  • example.com/BLABLABLA wird mittels NAS-Aliassen mit dem NAS selbst bewerkstelligt.
    Was ist hier allgemein besser bzw. zu empfehlen?
yep.
ist geschmackssache, ich finde es viel komfortabler einfach eine Subdomain fuer alles zu setzen und eigene Zerfifikate abzuholen
 
  • Gefällt mir
Reaktionen: Hot Dog
madmax2010 schrieb:
das webinterface, welches du unter 5001 erreichst, ist ziemlich sicher durch einen Webserver ausgeliefert.
Stimmt 😂
Na dann hast du deine Antwort: 5000 (http) und 5001 (https), wobei http automatisch an https weiter geleitet wird, http lasse ich als Verbindung nicht zu. Ich sehe ansonsten unter der Dienst-Übersicht keine vergebenen Ports für irgendwelche web-related Dienste.
Aber wenn ich diese Ports auf z.B. 8000 und 8001 ändere, lande ich am Ende eben bei 8001, macht also keinen Unterschied. Dafür wird wohl tatsächlich ein Reverse Proxy nötig sein.
madmax2010 schrieb:
ist geschmackssache, ich finde es viel komfortabler einfach eine Subdomain fuer alles zu setzen und eigene Zerfifikate abzuholen
okay, danke dir für den Rat. Dann werde ich in Zukunft wohl auch besser mit Subdomains arbeiten. Und bitte erinnere mich nicht an CA, das steht bei mir auch noch an 😅
Das offizielle Synology-Zertifikat ist leider kein offiziell zugelassenes und der Browser warnt bei der Verbindung vor einem eventuell unsicheren Zertifikat, was ich irgendwann auch noch lösen muss. Vermutlich mit eigener CA auf dem NAS? Ach keine Ahnung, das wird hier irgendwann wohl ein neues CB-Thema geben 😂
Wie hast du das bei dir gelöst, wenn man fragen darf?

Dann versuche ich es morgen mal mit Reverse Proxy und melde mich dann nochmal. Danke dir schonmal!

Noch eine kleine Frage:
Eine Verbindung von extern zum NAS kommt nur zustande, wenn man in der Fritzbox "exposed host" aktiviert. Ist dies nicht aktiviert, gibt es auch keine Verbindung (siehe Anhang).
Jetzt eine doofe Frage: Ist das ok, wenn der Host dauerhaft exposed bleibt? Falls nicht, was gibt es hier für eine Lösung? Aktuell schalte ich diese Option jedes mal manuell an und ab, je nachdem ob ich gerade eine Verbindung benötige. Aber das kann auf Dauer ja auch nicht die Lösung sein.
 

Anhänge

  • Fritzbox_Exposed_Host.jpg
    Fritzbox_Exposed_Host.jpg
    29,6 KB · Aufrufe: 231
Zuletzt bearbeitet:
Giggity schrieb:
Ja schon, das wäre auch meine 1.Wahl gewesen. Aber wie genau man das für das Synology-NAS einrichtet (als zentrale Vergabe für Zertifikate) bzw. bei Strato selbst für jede Subdomain, weiß ich leider noch nicht.
 
madmax2010 schrieb:
Giggity schrieb:
Omg, danke euch. Beste Hilfe hier. Das sieht ja nach einem Kinderspiel aus 😊👍
Ersetzt ihr dann alle eure Synology-Zertifikate durch Lets Encrypt Zertifikate oder verwendet ihr die von Synology auch weiterhin für bestimmte Sachen? Also gibt ja für alle Dienste Zertifikate (Active Backup, MailPlus, DriveServer, usw)

Aber mich würde eine Antwort zum oberen Post ja auch dringlichst interessieren. Weiß dazu jemand was von euch?
 
Hot Dog schrieb:
Eine Verbindung von extern zum NAS kommt nur zustande, wenn man in der Fritzbox "exposed host" aktiviert.
Nicht machen. Dein NAS ist damit komplett von aussen zu erreichen.

Leite nur die Ports an das NAS weiter, die Du auch benötigst, alles andere vor allem Zugriff auf das Admininterface nur aus dem LAN oder per VPN.

CU
redjack
 
  • Gefällt mir
Reaktionen: WingX und Hot Dog
redjack1000 schrieb:
Nicht machen. Dein NAS ist damit komplett von aussen zu erreichen.
Leite nur die Ports an das NAS weiter, die Du auch benötigst, alles andere vor allem Zugriff auf das Admininterface nur aus dem LAN oder per VPN.
Viiiieelen Dank! Das erklärt vielleicht auch, warum ich immer bei 5001 rausgekommen bin, da durch setzen der Exposed Host Option vermutlich die Port-Weiterleitung einfach ignoriert wurde. Hab mich schon gewundert, warum er ohne diese Option zu Port 443 nicht weiter leiten konnte, aber das würde alles erklären 😊.

EDIT:
Und siehe da, es läuft. Hab jetzt neben TCP auch noch UDP für die Port-Range 5000-5002 freigegeben und es läuft, auch ohne den Host zu exposen.
Jetzt müssen allerdings die Ports explizit im Link enthalten sein, damit es funktioniert, also:
  • DOMAIN.de:5001 für Anmeldung NAS
  • DOMAIN.de:5002 für Anmeldung Synology Drive
  • mit DOMAIN.de lande ich im nirgendwo

Das mit den Aliassen (DOMAIN.de/cloud) geht nun nicht mehr, warum auch immer.
Aber ich wollte ja sowieso auf Subdomains umsteigen, da ist das halb so wild.
Danke euch nochmal.
 
Zuletzt bearbeitet:
redjack1000 schrieb:
Leite nur die Ports an das NAS weiter, die Du auch benötigst, alles andere vor allem Zugriff auf das Admininterface nur aus dem LAN oder per VPN.
An der Stelle sieht man es wieder: Das Liken eines Beitrags zeigt nicht an, ob der Inhalt verstanden wurde.

Port 5001 TCP/UDP wird nun ungeschützt nach außen freigegeben und ich würde fast wetten, dass der normale Admin-Account noch aktiv ist - ohne 2FA.

Im Logfile dürften sich demnächst div. Loginversuche zeigen, die dort besser nie zu sehen wären.
 
Joe Dalton schrieb:
An der Stelle sieht man es wieder: Das Liken eines Beitrags zeigt nicht an, ob der Inhalt verstanden wurde.

Port 5001 TCP/UDP wird nun ungeschützt nach außen freigegeben und ich würde fast wetten, dass der normale Admin-Account noch aktiv ist - ohne 2FA.

Im Logfile dürften sich demnächst div. Loginversuche zeigen, die dort besser nie zu sehen wären.
Das war ja auch nur zum Test.
1. Port 5000-5001 sind bereits wieder geschlossen.
2. Port 5002 is der einzig offene und der dient jetzt dazu, meine neue Subdomain https://cloud.DOMAIN.de weiterzuleiten und das klappt einwandfrei und verweist direkt auf das Synology Drive Webinterface.
3. Das Adminkonto ist gut geschützt, wer das Passwort knackt, darf gerne zugreifen 😉
4. Das Adminkonto wird früher oder später deaktiviert, da ich dann für jeden einzelnen Dienst einen designierten User eingerichtet habe, der jeweils nur für seinen Aufgabenbereich Rechte erhält.
 
hmm, ziemlich durcheinander hier.

Wie man den reverse Proxy für 443 einrichtet hatte ich schonmal hier erklärt:
https://imaginado.de/2019/07/synology-filestation-und-co-besser-bereitstellen/
Für das neue Photos entfällt das mit /photos, das geht mittlerweile direkt per Subdomain.

Synology Drive kann zumindest auf den mobilen Apps per Reverse proxy 443 genutzt werden, jedoch hat der Windows Client stumpf seien Port in Quellcode gegossen. Das ist zumindest mein bisheriger Wissensstand - heißt der Drive Port muss leider 1:1 im Router an das NAS durchgereicht werden.

Lets Encrypt mit Zertifikaten und alternativen Namen bedeutet bei Synology, dass der Port 80 durchgereicht werden muss. Ist auch mein bisheriger Wissensstand und deckt sich in etwa mit dem kb Artikel.
  1. Synology DDNS supports DNS-01 (starting with DSM 6.0) and HTTP-01 validation with Let's Encrypt. Customized domain only supports HTTP-01 validation with Let's Encrypt. Refer to this article for more information about validation methods.
Um das zu umgehen kann bzw muss mal sich zB das POSH-ACME für die Windows Powershell installieren. Damit kann man die DNS-Validierung nutzen. Und vor allem, damit gehen Wildcard Zertifikate. POSH-ACME erzeugt dabei alle notwendigen Dateien für Linux oder Windows Systeme. Auf der NAS muss man das dann importieren. Bedeutet halt alle ~90 Tage 5min Handarbeit.
 
  • Gefällt mir
Reaktionen: Hot Dog
morcego schrieb:
Wie man den reverse Proxy für 443 einrichtet hatte ich schonmal hier erklärt:
https://imaginado.de/2019/07/synology-filestation-und-co-besser-bereitstellen/
Für das neue Photos entfällt das mit /photos, das geht mittlerweile direkt per Subdomain.
Danke dir, war aber gar nicht notwendig. Ich muss nicht alle Anwendungen über einen Port schleusen. Ich vergebe jetzt für jede Anwendung einen eigenen Port. Synology Drive läuft bei mir jetzt momentan auf Port 5002 (TCP/UDP). Hab das mit einer Subdomain gekoppelt, welche von extern direkt an meine Fritzbox weiter geleitet wird (A-Name, IP der Fritzbox). Wenn andere Dienste dazu kommen sollten, bekommen die eben einen anderen Port und ihre jeweilige Subdomain.
Der Nachteil ist halt, dass im Link der Port angeben werden muss, also example.com:5002 aber das ist ja halb so schlimm.
morcego schrieb:
Lets Encrypt mit Zertifikaten und alternativen Namen bedeutet bei Synology, dass der Port 80 durchgereicht werden muss. Ist auch mein bisheriger Wissensstand und deckt sich in etwa mit dem kb Artikel.
Um das zu umgehen...
Schau ich mir bei Gelegenheit mal an, danke.
 
Zuletzt bearbeitet:
Hot Dog schrieb:
Hab das mit einer Subdomain gekoppelt, welche von extern direkt an meine Fritzbox weiter geleitet wird (A-Name, IP der Fritzbox). Wenn andere Dienste dazu kommen sollten, bekommen die eben einen anderen Port und ihre jeweilige Subdomain.
Das ist Quatsch bzw doppelt gemoppelt. Der Reverse Proxy zerlegt anhand der subdomain die Anfrage und schickt sie an einen anderen Port. Gerade deshalb benötigt man ja nur eine einzige Portfreigabe.
Wenn du jeden Dienst mit eigenem Port ansprichst, dann brauchst du keine Subdomain. Dann reicht genau die, auf der dein DDNS aktualisiert ist.
Hot Dog schrieb:
Der Nachteil ist halt, dass im Link der Port angeben werden muss, also example.com:5002 aber das ist ja halb so schlimm.
So lange du auf den Port kommst, korrekt. Ist halt nicht gesagt, dass dich jeder Admin aus seinem Netz dorthin lässt. 80 und 443 sind hingegen immer zulässig. Das wäre ja wiederum der Grund wieso man den Reverse Proxy statt der expliziten Portfreigabe verwendet. Aber das kannst du ja ändern wenn es mal soweit ist. 😉
 
  • Gefällt mir
Reaktionen: Hot Dog und NPow
morcego schrieb:
Das ist Quatsch bzw doppelt gemoppelt. Der Reverse Proxy zerlegt anhand der subdomain die Anfrage und schickt sie an einen anderen Port. Gerade deshalb benötigt man ja nur eine einzige Portfreigabe.
Stimmt, da hast du recht. Dann werde ich am Wochenende wohl einen Reverse Proxy einrichten und alles über einen Port schleusen. Danke für die Tipps.

Noch eine Frage zu den Zertifikaten:

Wenn ich auf dem NAS unter Zertifikate ein neues Lets Encrypt Zertifikat einrichte, geht das ja nur für offiziell angemeldete Domains (also z.B. example.de).
Kann ich auch ein Zertifikat für meine selbst eingerichtete (nicht offizielle) TLD (example.home) runterladen? Denn alle meine Mail-Sachen laufen über diese TLD und auch hierfür wären Zertifikate nice to have.
Oder brauch ich genau hierfür das von dir angesprochene POSH-ACME für die Windows Powershell und damit Wildcard-Zertifikate?
Momentan gehe ich über den Weg mit einem geöffneten Port 80 für Lets Encrypt für meine offizielle Domain.
Sorry für die doofe Frage, möchte nur 100% sicher gehen und nicht an der falschen Stellschraube drehen.
 
Zurück
Oben