DSM 6.x und darunter Seit Update ist meine Diskstation extern nicht mehr erreichbar

[Nexxos_Zero]

Guten Tag zusammen

Ich hoffe ich Poste mein Problem hier im Richtigen Unterforum.
Und zwar habe ich folgendes Problem, seit dem DSM Updtae von letzer nach (25.10.2018) auf die Version "DSM 6.2.1-23824 Update 1" habe ich nur noch über die interne IP-zugriff auf meine DS1817+.
Wenn ich versuche die Filstation, Videostation oder Audiostation per externen URL zu erreichen läuft es immer auf eine Timout hinaus.

Die DS ist so Konfiguriert, dass sie bei anfragen auf dem HTTPS Port 443 auf folgende Benutzerdefinierte URL abfragen soll

Filestation = www.meineURL.ch
Audiostatio = audio.meineURL.ch
Videostation = video.meineURL.ch

Bis gestern hat dies auch einwandfrei funktioniert, aber laut Monitoring waren alle drei URLs nach dem Upodate nicht mehr erreichbar.
Die Ansteuereung der Seiten endet immer in einem Timeout und der umleitung auf port 5001 (was eigentlich die Stadartverwaltung ist, welche von extern durch die Firewall blockiert wird).
Sprich nach dem Timeout steht dann zum bespiel https://videostation.meineURL.ch:5001, was aber nicht passieren sollte.

Meine Frage ist daher, warum leitet die DS die anfrage auf Port 5001 um und nicht an die Benutzerdefinierte Domain?
Bis gestern lief alles gut und jetzt mit dem Update fundktionert gar nichts mehr.

Hoffe jemand kann sich dem Problem annehemen oder kennt es bereits.

Gruss und schon mla danke im voraus

NZ

 

[c0smo]

Wie wurde die Umleitung auf die unterschiedlichen Dienste realisiert? Normal ist ja 443 für die Photostation gedacht!

 

[Nexxos_Zero]

der Port 443 ist einfach der Standart HTTPS Port, sprich er hat keine fixe Applikation zugewiesen.

Die DS ist so konfiguriert, dass sie alle URL-Anfragen über Port 443 bekommt (auch durch die zusätzliche Firewall so geregelt), und dann anhand der URL die entsprechende Applikation ansteuert.
Die lässt sich in der Systemsteuerung -> Anwendungsportal -> "Anwendung" -> Einstellung -> unter "Benutzerdefinierte Domain" zusweisen.
Dann benötigt man nicht mehr als einen Port (in meinem Falle der HTTPS Port 443).

 

[c0smo]

der Port 443 ist einfach der Standart HTTPS Port, sprich er hat keine fixe Applikation zugewiesen.

Das stimmt so nicht. 443 ist als Standard in DSM fix für die Photostation reserviert.

Die DS ist so konfiguriert, dass sie alle URL-Anfragen über Port 443 bekommt

Das war meine Frage. Wie wurde diese Konfiguration realisiert?

Die lässt sich in der Systemsteuerung -> Anwendungsportal -> "Anwendung" -> Einstellung -> unter "Benutzerdefinierte Domain" zusweisen.
Dann benötigt man nicht mehr als einen Port (in meinem Falle der HTTPS Port 443).

Korrekt, trotzdem verwendet DSM und viele Dienste weiterhin den Standardport 5000/5001

Ist die Photostation überhaupt aktiviert?
Normalerweise wird dein Vorhaben über den Reverse Proxy erledigt oder du leitest einen geänderten öffentlichen Port im Router auf den internen Port, in deinem Fall die 443.
Einfach so passiert da erstmal gar nichts, mit deiner Konfiguration, dafür musst du etwas geändert haben in DSM oder im Router! Aber was?


Edit:/

Das sind doch Subdomains in deinem ersten Beitrag!
Der Aufruf über einen Alias erfolgt mit h**p://deine_domain.de/file - /audio

 

[Nexxos_Zero]

Nein miene Photostation ist nicht aktiviert.
Und die einzige Funktion die noch einen explizieten Port verwendet (zumindest laut einsehbarer Konfiguration) ist das DSM mit dem Port 5001 bzw. umgeleiteten 5000

Und auch wenn es mit deiner Konfiguration ebenfalls funktionieren würde, hat meine bis gestern nacht auch funktioniert.
Aber ich habe soeben was anderes bemerkt. Die einstellungen im Anwendungsportal lassen sich bei den Anwendungen selber nicht mehr ändern (Fehlermeldung Operation Fehlgeschlagen).
Daher vermute ich eher, das das DSM einen Bug hat, wenn sich die Optionen nicht einmal mehr anpassen lassen.

 

[c0smo]

Du verwendest mehrere Dienste über 443. Dazu brauch es den Reverse Proxy. Ohne RP verstehe ich deine Konfig gerade nicht.
Kannst du mal ein Screenshot machen vom Anwendungsportal.

 

[Nexxos_Zero]

Sorry, war länger nicht verfügbar.
Also hier mal ein Prinscreen:



Wie müsste denn der Reverse Proxy einsgestell sein (am liebsten mit Beispiel)?

 

[Nexxos_Zero]

Ok ich habe wie vorgeschlagen einen Reverse Prox eintrag erstellt.
Dieser funktioniert ebenfalls nicht, denn wenn ich versuche meine Videostation auf Port 9008 anzusteuern steht am ende in der URL immnoch www.meineURL.ch:5001
Und wie bereits erwähnt gibt das DSM bei jeder änderung der einstllungen im Anwendungsportal die Meldun "operation Fehlgeschlagen" aus, obwohl die änderung übernommen wurd.
Denke am besten warte ich bis zum nächsten DSM Update und hoffe dass dabei das Portal gefixt wird, denn scheinbar hat es tatsächlich einen defekt.

 

[c0smo]

Sorry dein Post ist untergegangen. Meld mich heut abend mal.

 

[c0smo]

Also wenn du die VS unter 9008 erreichen willst, muss das natürlich auch angegeben werden im Anwendungsportal. Wenn dort nichts steht ist die VS unter 5000/5001 erreichbar.
Ich verstehe jetzt auch noch nicht ganz was dein Ziel ist. Oben schreibst du, dass alles über 443 erreichbar sein soll. Das geht über den Reverse Proxy. Wenn die VS aber 9008 hat, brauchst du keinen RP.

Das mit den unterschiedlichen Domains ist ja schön und gut, aber im Endeffekt nur Mehrarbeit, da eh alles auf die selbe IP auflöst. Sind diese denn überhaupt bei deinem Dyn Dienst eingerichtet? Wenn ja, verweisen alle 3 Domains auf deine öffentliche IPv4? Das kannst du mit nslookup in cdm überprüfen. (nslookup deine_domain.tld)
Wenn das alles passt, musst du anschließend dafür sorgen, dass die Domains unterschiedlich behandelt werden. Sprich, wenn du domain1 (https 443) für die VS benutzen willst, muss die Anfrage über den RP von 443 auf 9008 geleitet werden. Als zweites die Filstation. Hier muss jetzt erstmal ein benutzerdefinierter Port (zb. https 7007) erstellt werden, da sonst die Anfrage auf 5000/5001 hinausläuft. Das gibt dann vermutlich einen Konflikt mit der DSM Oberfläche.
Im Router leitest du 443 ganz normal auf deine DS.





Das wäre jetzt mal mein erster Versuch für dieses Konstrukt.

 

[Fusion]

@cosmo - nein, man braucht nicht zwangweise einen Eintrag unter "Reverse Proxy". Die benutzerdefinierten Domains unter "Anwendung" machen genau dies, aber Namensbasiert.
Und auch der Port 443 ist nicht fix der Photo Station zugewiesen, er landet nur auf dem Web-Server der auch die Photo Station mit ausliefert (nginx oder Apache, je nach Config).
Nur wenn dyn.domain.de keinem anderen Host auf der DS zugewiesen ist landet auch dyn.domain.de/photo auf der Photo Station. Andernfalls wird der Hostname "vorher abgegriffen" und an den entsprechenden Dienst geleitet.
Eben z.B. eine der benutzerdefinierten Domains unter Systemsteuerung > Netzwerk > DSM Einstellungen für den DSM oder unter Anwendungsportal > Anwendungen.
Setzt man dort irgendwo den Hostnamen dyn.domain.de, dann läuft dyn.domain.de/photo am Ende ins Leere, weil dieser Pfad für diesen Host dann normal nicht definiert ist.

So wie im ersten Post genannt erreicht man die Dienste dann via Subdomains und alle über Port 80/443, ohne anderweitige Portweiterleitungen im Router oder Angaben von Aliasen oder generischen Reverse Proxies im Anwendungsportal.
Edit: Es führen eben nur viele Wege nach Rom. Ob jetzt 443 > benutzerdefinierte Domain > Dienst (wie vom Threadersteller), oder 443 > Reverse Proxy > Dienst : Port (wie von dir vorgeschlagen) sind nur 2 mögliche Wege.

Auch wenn du im Anwendungsportal benutzerdefinierte Ports oder Aliase einträgst sind die Dienste weiterhin auch über den Standard DSM Port unter Systemsteuerung > Netzwerk > DSM Einstellungen erreichbar.
Die Einstellungen laufen alle alternativ bzw als ODER, und nicht exklusiv. Beispiel folgend. Nur Port 443 geöffnet und an die DS weitergeleitet, Hostnamen NUR in der benutzerdefinierten Domain verwendet und Hostnamen von extern als CNAME auf die dyn-Adresse geleitet.
Dienste sind dann via https://dienst.domain.de erreichbar von extern (im Browser). In DS File z.B. muss man leider file.domain.de:443 als Hostname eintragen, weil diese sonst unkontrolliert im Hintergrund immer Port 5001 probiert.


@Nexxos_Zero - hab leider auch keine zündende Idee außer die Kette von innen nach außen oder außen nach innen durch zu testen (Domains, DNS, dyn, Router, Firewall, DS).
Wie du sagst deutet es ja eher auf ein DSM Problem, wenn du Einstellungen nicht ändern kannst. Dabei würde ich auch gleich verschiedene Browser testen (besonders Safari und Chrome mucken meiner Erfahrung nach manchmal rum) und verschieden Zoomstufen (am besten 100%). Da verschwinden manchmal Dialoge, oder Einstellungen lassen sich nicht setzen. Auch explizit abmelden, Cache und Sitzungsdaten etc löschen, mal neu starten.

 

[c0smo]

Dem ist nichts hinzuzufügen
Deine Variante kannte ich nicht, deshalb mein Vorschlag mit dem RP bzw auch deshalb um mögliche Fehler zu umgehen. Die Änderung der Ports im Anwendungsportal halte ich aber für sinnvoll, um eventuelle Ungereimtheiten mit 5000/5001 zu umgehen. Gerade weil diese 2 Ports von unterschiedlichen Diensten verwendet werden.

Das mit Fehlern in den Einstellungen im RP hatte ich auch mal, gerade mit 443. Letztendlich war es aber wieder, wie schon so oft - der Fehler saß vor dem Monitor Bei mir waren es immer kollidierende Eingaben bezüglich der Ports. Am besten alles nochmal löschen und neu anlegen.

Meine erste Anlaufstelle wäre jetzt der dyn. Lösen alle Domains auf deine IPv4 auf? Ich hatte schon dyn Anbieter, die bei über 50 Anfragen an einem Tag, erstmal abschalten.
Danach entscheide dich für eine der genannten Varianten.
Wenn es mit deinen Subdomains nicht funktioniert, dann kannst du auch mal die Variante mit dem Alias versuchen (h**p://domain.tld/alias)

Edit:/
Wenn http2 / hsts aktiviert ist, schalte das mal zum testen ab

 

[Fusion]

Danke. Hatte nur spontan das Anliegen die Variante nochmal etwas ausführlicher zu schreiben, weil ich diese auch seit langem verwende.
Die Definition von *zusätzlichen* Ports im Anwendungsportal schützt jedenfalls nicht vor möglichen Fehlern.
Wenn zu z.B. 7001 für die File Station definierst, wird diese weiterhin auch unter 5001 lauschen und auch unter möglichen eingetragenen Aliasen etc. Die Wege laufen alle Parallel.
Aber zugegeben, manchmal kann man so eventuell anderweitige Fehler aufdecken.
Da auf der Syno ja ALLES irgendwie Web-Anwendungen sind mit 2-3 Web-Servern ist die Konfiguration schon gut komplex und übersichtlich ist anders. Da wünschte ich manchmal ich hätte die interne Entwickler-Doku oder ähnliches, damit man sich nicht alles zusammensuchen muss und dann doch wieder irgendwo was in einer config vergessen hat (wenn man auf der Konsole unterwegs ist).

Neben den Tipps von Cosmo würde ich dann noch ein Ticket bei Syno in Betracht ziehen, wenn du weiterhin Probleme hast Einstellungen zu ändern. Vielleicht läßt es sich dann ohne DSM Reset wieder hinbiegen.

 

[c0smo]

Ich finde es merkwürdig das ein Update alle Konfigs zu Nichte macht. Soll jetzt nicht heißen, das es nicht möglich wäre. Ich errinere mich an zwei Fälle, erst kürzlich passiert, da musste Quickconnect neu gestartet werden bzw es war irgendetwas deaktiviert nach einem Update, um Änderungen an den Nutzungsbestimmungen zu bestätigen. Oder vor 2 Jahren das Drama mit dem Http2 gedöns und einiger Dienste die nicht mehr abrufbar waren. Deshalb auch der Tipp das mal zu deaktivieren.

Und in dem Zusammenhang gleich noch eine Frage. Unter Sicherheit / Erweitert / SSL Profilebene - welche Kompatibilität ist dort aktiviert?

 

[Nexxos_Zero]

Danke für deine Antowrt.
Also, so wie du mir das oben beschrieben hast, habe ich das auch ausprobiert (das erste Foto vom Anwedungsportal ohne Ports war noch vor der änderung).
Ich habe Sowohl den Port im Anwendungsportal, als auch die Einträge im Reverse-Proxy so eingerichtet wie es auf deinem Beispiel zu sehen ist, trotzdem wurden die Anfragen auf Port 5001 umgeleitet, egal ob von intern oder von Extern.
Daher vermute ich wirklich dass ich im Anwendungsportal einen Bug habe, anders ergibt es keinen Sinn.

Nein ich bin nicht bei einem Dyn Dienst angemeldet, sondern Verfüge zuhause über Fixe öffentlich IP-Adressen. Meine Top/Second-Level-Domain ist bei einem Registrar mit eigenen DNS Servern eingetragen, und die drei Third-Level Domains Verweisen alle auf die gleiche Top/Second-Level Domain einfach mit den einträgen Video. / Audio. / www. um jeweils die VS, FS und AS anzusteueren. Die IP Stimmt und wird auch richtig aufgelösst, aber anstelle das der zugehörige Port oder URL angesteuert wird, landen alle automatisch wieder bei Port 5001, auch wenn der Proxy die Anwendung auf einen anderen Port leiten soll (z. B. Port 9008 bei VS).

Die Konstellation sieht in ungefähr so aus:

Eingabe video.meineURL.ch ->
DNS Auflösung ->
Ansteuern der öffentlichen IP über HTTPS-port (443) ->
Externe Firewall weisst anfrag an NAS zu ->
Anfrage geht bei NAS über 443 ein -> (bis hier hin funktioniert auch noch alles)
Reverse Proxy leitet Anfrage auf Port 9008 um -> (vorher über die Third-Level Domain gesteuert)
VS wird angezeigt.

Zumindest SOLLTE es so ablaufen, aber beim letzten punkt landet die Anfrage immer bei www.meineURL.ch:5001 was dan eben zu einem Fehler führt.
Daher gehe ich davon aus dass das Anwendungsportal die Anfrage nicht richtig umleitet.

Und wie gesagt, bis zum Update hate es auch ohne Portumleitung über den Reverse-Proxy funktioniert, sondern die DS hat dierk über die zugweisene URL die richtige Anwendung angesteuert.
Da kamen alle Anfragen über Port 443 und wurden über die Third-Level-Domain der jeweiligen Anwendung zugewiesen (www = FS / video =VS / audio = AS).

 

[Nexxos_Zero]

Zur Frage, in der SSL Profilebene ist die "Moderne Kompatiblität" gewählt.
Habe es Testweise jetzt mal noch auf alte Kompatiblität gestellt. Er bekommt von extern einen Hinweis wegend em Zertifikat, heisst also, dass die Anfrage bis hin zur DS erfolgreich ist und dementsprechend an dem Anwendungsportal scheitert.

 

[Nexxos_Zero]

@Fusion
Danke für deine erläuterung. genau so wie du habe ich es auch über Subdomians angesteuert.
Habe Mittlerweile eben beides ausprobiert und weder das eine noch das andere Funktioniert.
Also gehe ich wirklich davon aus, das das Anwedungsportal nicht richtig arbeitet.

 

[Fusion]

So sollte es ja eigentlich auch laufen.
Von extern kommt eine Anfrage an den nginx. Dann wird per SNI (Server Name Indication Anfrage vom Browser) nachgeschaut, ob der Hostname irgendwo als vHost Reverse Proxy oder benutzerdefinierte Domain eingetragen ist.
Falls ja, dann wird die Anfrage an den Dienst geleitet (also z.B. der Normalfall für eine dienst.domain.de die im Anwendungsportal unter Anwendung als benutzerdefinierte Domain definiert ist)
Falls nein und falls die Web Station nicht installiert ist, wird die Anfrage auf den DSM geleitet.
Falls nein und falls die Web Station installiert ist. wird sie an den nachgelagerten Web Server (nginx oder Apache) weitergereicht (also praktisch der Reste-Verwerter, trifft kein Hostname zu...). Ohne Konfiguration ist das der Inhalt vom Doc-root /web (dummy Seite der Web Station)

Einzige andere Situation, in der zwangsweise auf dem DSM umgeleitet wird (neben dem Fall ohne Web Station), der mir einfällt ist QuickConnect.

Eventuell nochmal den Überblick über die Einstellungen:
- QC deaktiviert
- Externer Zugriff > Erweitert
- Netzwerk > DSM Einstellungen
- Web Station > vHosts
die anderen für Anwendungsportal Anwendungen und Reverse proxy haben wir ja schon gesehen.

Wenn du sonst keine Einstellungen auf der Konsole angepasst hast (nginx server blocks oder ähnliches), keine .htaccess rewrites etc eingerichtet hast (Apache) und wir auch sonst keine Idee mehr haben, dann sehe ich langsam düster.

 

[Nexxos_Zero]

Witz des Jarhunderst. Zwischenzeitlich hat es wieder funktioniert, ohne das ich noch was geändert habe.
Jetzt ist DSM6.2-Version 4 rausgekommen und puff....es geht wieder nichts mehr....

Wird wohl definitiv am DSM liegen, denn die Webstation habe ich nicht installiert und auch meine einstellungen auch nicht mehr geändert.
Das einzige was ich ich mich frage ist ob es möglich ist auf den internen Webserver des DSM zuzugreifen (nicht die Webstation)?

 

[Fusion]

Der DSM läuft auf dem "internen" Webserver wenn du so willst. Ein nginx.
Und der "benutzer" Webserver läuft auf apache oder nginx.

Und LAN-IP:<Port> sollte immer gehen, egal was man für Reverse Proxies oder benutzerdefinierte Domains angelegt hat.