DSM7: Sessionmitnahme bei subdomains (CNAME) und reverse proxy?

[bueckerle]

Hallo zusammen,

falls dies schon an anderer Stelle ausdiskutiert wurde bitte eine kurze Info und diesen Thread löschen.

Ich habe keine feste IP und nutze xyz.synology.me, habe eine eigene Domain und verweise via CNAME auf die DDNS mit diversen subdomains. Im App Launcher oder wenn man Links teilt, erscheint die synology.me Adresse mit Port des jeweiligen Dienstes. Dieser kann aber nicht aufgerufen werden, da nur via reverse proxy verfügbar, selbst wenn freigegeben sähe der Link nicht schön aus.

BITTE, ist dies in DSM7 Geschichte? Individuelles Customizing der Links oder des App Launchers würde ja schon helfen.

 

[Fusion]

Einstellungsfehler?

Welche Links wo geteilt?

Je nachdem wo kann man die Domains beeinflussen.
Meine geteilten Links in der File Station lauten z.B. https://file.example.de/sharing/abcdef
Je nach Einstellungen hängt es dann zudem noch davon ab über welche Adressen man sich anmeldet.

 

[blurrrr]

Setz mal den Hostnamen der Kiste auf Deine eigene Domäne, dann sollte das auch entsprechend funktionieren...

domain.tld -> CNAME -> .....synology.me -> reverse-proxy (reagiert auf domain.tld) -> content

 

[bueckerle]

Danke für die Antworten und sorry für die späte Antwort.

Ich habe bspw. contacts.xyz.de auf CNAME zzz.synology.me gesetzt, das sollte alles passen. Login ohne Probleme möglich, Zertifikate stimmen, via reverse proxy von 443 auf die einzelnen Apps. Aber ich würde dann gerne über die App Launcher in den einzelnen Diensten (oben rechts diese Kachel) in andere Apps springen und zwar mit "schönen Links". Hier wird mir dann nicht calendar.xyz.de oder mail.xyz.de angezeigt, sondern immer https://xyz.synology.me:5001/?launchApp=SYNO.SDS.Chat.Application. Hier hätte ich dann gerne chat.xyz.de stehen.

Kriegt man das irgendwie hin ?

 

[Benares]

Ich gehe auch über 443/https und verschiedene CNAMEs auf den Reverse-Proxy meiner DS415 und leitet von dort auf die entsprechende Anwendung per 80/http weiter, damit ich die Zertifikatsverwaltung zentral habe. Das alleine reicht aber nicht, man muss dem Reverse-Proxy auch sagen, unter welchem Namen er antworten soll.

Das geht über Rewrite-Rules. Bei nginx legt man dafür im Verzeichnis /usr/local/etc/nginx/sites-enabled für jeden CNAME eine Datei mit folgendem Inhalt an, z.B. für calendar.xyz.de eine Datei calendar-redirect.conf mit folgendem Inhalt:

server {
        listen 80;
        server_name calendar.xyz.de;

        return 301 https://$host$request_uri;
}

Für die anderen CNAMES entsprechend.

Edit:
Wenn man den DDNS-Server der DS nicht verwendet, muss man m.W. die Domain (xyz.de) auch unter Systemsteuerung, Externer Zugriff, Erweitert als Hostname eintragen.

Probier's mal aus.

 

[bueckerle]

Ich gehe auch über 443/https und verschiedene CNAMEs auf den Reverse-Proxy meiner DS415 und leitet von dort auf die entsprechende Anwendung per 80/http weiter, damit ich die Zertifikatsverwaltung zentral habe. Das alleine reicht aber nicht, man muss dem Reverse-Proxy auch sagen, unter welchem Namen er antworten soll.

Das geht über Rewrite-Rules. Bei nginx legt man dafür im Verzeichnis /usr/local/etc/nginx/sites-enabled für jeden CNAME eine Datei mit folgendem Inhalt an, z.B. für calendar.xyz.de eine Datei calendar-redirect.conf mit folgendem Inhalt:

server {
        listen 80;
        server_name calendar.xyz.de;

        return 301 https://$host$request_uri;
}

Für die anderen CNAMES entsprechend.

Edit:
Wenn man den DDNS-Server der DS nicht verwendet, muss man m.W. die Domain (xyz.de) auch unter Systemsteuerung, Externer Zugriff, Erweitert als Hostname eintragen.

Probier's mal aus.

Update folgt Ich probiere noch etwas rum!

Kriege es nicht hin / funktioniert nicht (Datei in den Ordner kopiert, nginx -s reload), hostname eingetragen, etc. Kann aber ja nicht der einzige mit diesem Wunsch sein?

 

[Benares]

Die Rewrite-Rule hat nichts verändert? Beschreib mal bitte das Fehlerbild etwas genauer.

 

[bueckerle]

Danke, dass du dich meiner annimmst

Das Fehlerbild ist, dass er nach wie vor überall in den Synology Apps auf die synology.me Domain verlinkt mit :5001 am Ende, nicht aber auf meine eigene Domain. Mit der Rewrite Rule habe ich es einmal mit listen 80 und listen 443 probiert. Reverse Proxy hat bei mir im DSM eigentlich als Ziel auch https (Beispiel 20003 bei calendar). Dies hatte ich dann aber auch auf http angepasst.

In dem Sinne wieder was gelernt und war mal mit dem root auf der 720+ unterwegs. Wahrscheinlich habe ich irgendwo ein Häkchen vergessen.

Bin über jeden weiteren Tipp dankbar. Schönes Wochenende!

 

[Fusion]

Also ich brauche keinerlei rewrite rules, keine Reverse Proxy Einträge oder anderes.
Habe zwar auch diverse nginx/apache configs noch angepasst, aber das hat nichts mit dem Thema hier zu tun.

Ich habe unter Systemsteuerung > Anwendungsportal jeweils eine benutzerdefinierte Domain (inklusive HSTS und HTTP/2) angelegt, bsp. dienst.example.com
Diese Sub-Domains beim Hoster per CNAME auf meine-nas.synology.me gesetzt.
Unter Systemsteuerung > Sicherheit > Zertifikat habe ich mir dann noch für die verschiedenen benutzerdefinierten Domains die Zertifikate von Let's Encrypt geholt

Wenn ich mich jetzt via https://dienst.example.com einlogge dann sehe ich oben links im Menü auch die anderen Dienste mit dienst2.example.com, dienst3.example.com etc. stehen.

Ich habe kein QuickConnect, ich habe keinerlei Einträge unter Systemsteuerung > Externer Zugriff (Routerkonfiguration + Erweitert)
Unter Systemsteuerung > Netzwerk > DSM Einstellungen habe ich auch für den DSM eine benutzerdefinierte Domain angelegt, was man aus Sicherheitsgründen vielleicht eher vermeiden sollte (so dass nur die einzelnen Dienste erreichbar sind auf 443. Ob das noch einen großen Unterschied macht im Risiko ist die andere Frage.

An der Session Anmeldung ändert das übrigens nichts, weil alle dienst.example.com vermutlich als eigener Kontext zählen und damit eine Anmeldung erforderlich ist.
Wenn es also nicht nur um die Namen sondern um weiteres geht dürfte es deutlich komplizierter werden bzw. fährt man dann besser, wenn man Aliase benutzt und über sub.example.com/dienst zugreift. Vielleicht behält er dann den Benutzer-Auth Kontext für die verschiedenen Dienste bei.

 

[bueckerle]

Hallo @Benares, @Fusion,

ich habe nun die reverse Einträge rausgeschmissen und es über die individuelle Domain im Anwendungsportal gelöst. Damit werden die Links in den Anwendungen richtig gesetzt. War es dann quasi "doppelt gemoppelt"? Schade ist natürlich, dass der Benutzer-Auth nicht mitgegeben wird und man sich beim Sprung erneut anmelden muss. Werden die Reverse Proxy Einträge dann eigentlich nur für Anwendungen außerhalb der Standarddienste gebraucht?

Ich habe nun aber noch das Problem, dass wenn jemand meinen Link zum ersten Mal aufruft (via http, nur mit dienst.example.de), sagt der Browser "... kann diese Anfrage momentan nicht verarbeiten HTTP ERROR 503". Wenn man via httpS einmal verbunden war, leitet er auch automatisch ohne Warnung von http weiter auf https. Google sagt mir zu 503 so einiges, nur noch nicht die Lösung. Beim allerersten Besuch kapiert er es wahrscheinlich nicht, da nur Port 443 freigegeben, aber kann man es via .htaccess auch auf die Subdomains mit CNAME forcieren? Hier gibt es einige Beiträge zu wie bspw., unten, was bei mir nun auf die Schnelle nciht geklappt hat, Geht er bei CNAME direkt auf xyz.synology.me, ohne auf die .htaccess der Hauptdomain zu achten?

RewriteCond %{HTTPS} on
RewriteCond %{HTTP_HOST} ^(.+)\.mydomain\.com$ [NC]
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Danke & Gute Nacht

 

[Fusion]

Benutzerdefinierte Domains sind praktisch reverse proxies für Syno Anwendungen.
Die Anmeldung bleibt nur erhalten solange du unterhalb von bsp
https://dienst.example.com/?launchApp=SYNO.SDS.Chat.Application unterwegs bist.
Als wenn du z.b. Via Systemsteuerung > Netzwerk > DSM Einstellungen > benutzerdefinierte Domain erst den DSM und dann eine der Anwendungen aufrufst.

HSTS weist den Browser an eine Seite die einmal per https besucht wurde innerhalb einer Zeit X nur noch so zu besuchen, auch wenn sie wieder per http aufgerufen wird.

Wenn du nur 443 offen hast kann man aber auch keine Umleitung http > https veranlassen, da die Anfrage auf 80 ja gar nicht durch kommt.
Den passenden Code Schnipsel für nginx hatte Benares ja schon geposted. Der sorgt dafür, dass auch Anfragen an Port 80 für diese benutzerdefinierten Domains auf https umgesetzt werden bzw der Browser veranlasst wird die Anfrage so zu wiederholen.
htaccess ist nur für apache. Der System Webserver der auch die benutzerdefinierten Domains verarbeitet ist immer nginx.
Oder man lässt 80 zu und schreibt eben das korrekte https vorne an.