Drive-Link auf domain.de/drive/.... anstatt domain.de:port/drive/....

[schor]

Hallo an alle,

mein synology-drive server läuft auf einem custom port, auf den ich einlangenden http/https Traffic (Port 80/443) weiterleite. Somit kommen alle, die auf meine domain.de klicken, direkt auf die Cloud-Console und können sich dort einloggen.

Die DSM-Settings habe ich ebenso auf einen custom port gesetzt, somit gebe ich domain.de:customport ein, damit ich auf die DSM-/Admin-Console komme.

Nun meine Frage: Wenn ich in Drive (aber auch aus dem File Manager bzw. aus DSM) einen Link teile, wird dieser nicht z.B. als domain.de/drive/.... geteilt, sondern als domain.de:customport/drive...

Wie kann ich Drive (aber auch den File-Manger) dazu 'bewegen' geteilte Links ohne den DSM-Port zu teilen?

Vielen Dank schonmal.

 

[Benares]

Die Links werden normalerweise immer mit der URL erstellt/angezeigt, mit der du gerade selbst verbunden bist. Es sei denn, du hast im Anmeldeportal bei der jeweiligen App bei "Domain" was festes eingetragen. Eine weitere Stelle, die das beeinflusst, ist die Domain unter Externer Zugriff/Erweitert.

 

[schor]

@Benares: Danke für die Info. Ja, ich habe unter 'Application Portal' einen custom alias 'drive' eingetragen, die Links werden jedoch nicht wie dort angezeigt mit domain.de/drive erzeugt, sondern mit domain.de:customport/drive.
DSM habe ich ja auf einen custom-port gelegt (unter netzwerk/dsm-settings) und die ports 80/443 im reverse proxy auf die ports von drive weitergeleitet: somit sehen meine Kunden nicht das DSM-Portal, sondern die drive-Anmeldekonsole wenn sie domain.de eingeben

Gibt es sonst eine andere Möglichkeit, DSM auf den Standard-Ports 80/443 laufen zu lassen, und drive ebenso ohne einen /slash im Domainnamen erreichbar zu haben?

 

[Benares]

Also ich hab mir im DNS mehrere CNAMEs (Aliase) für meine Domain angelegt (drive.example.com, file.example.com, photo.example.com, ...) und diese als Domain im Anmeldeportal bei den Apps eingetragen. Dies generiert (unsichtbar) ein Reverse-Proxy für jede App, so dass man von außen über 80/443 direkt auf der jeweiligen App landet. Einziger Nachteil, man braucht bei https-Zugriff auch ein Zertifikat, dass all diese Namen als "Alternate Names" enthält.

Edit: Was steht denn in der URL oben im Browser, nachdem du dich über domain.de/drive angemeldet hast? Mit oder ohne Port?

 

[schor]

Aha ich verstehe, dann würde ich keine NAS-Interne Portweiterleitung mittels Reverse-Proxy benötigen, sehrwohl jedoch für jede subdomain ein ssl-Zertifikat
Was hast du dann 'auf der rechten Seite' von CNAME-stehen?
Ich habe cloud.domain.de als A-Record auf die (fixe) IP-Adresse der NAS gesetzt
Und müsste jetzt drive.domain.de als CNAME auf cloud.domain.de/drive setzen, wenn ich das richtig verstehe?
Und gleichzeitig auch cloud.domain.de/drive in der jeweiligen App als 'alias' (erste Zeile ganz oben) eintragen?

PS: dies hätte auch den Vorteil dass gesharte Links nicht mehr mit cloud.domain.deORT/drive/... anfangen, und von vielen (Hosting) Providern ausgefiltert werden...

 

[Benares]

Bitte verwende example.com bei solchen Beiträgen als Platzhalter, domain.de gibt es wirklich.

Also ich habe eine Domain example.com, deren IP per DDNS aktualisiert wird. www.example.com, drive.example.com, ... sind alles CNAMEs, die auf "example.com." (der Punkt am Ende ist wichtig) zeigen. Ob du bei fester IP A-Records oder CNAMEs verwendest, dürfte egal sein, aber CNAMEs sind irgendwie logischer.

Du brauchst auch nicht für jeden Namen ein eigenes Zertifikat. Es reicht auch eins für example.com mit all den Namen als Alternate Names. Oder eben ein Wildcard-Zertifikat für *.example.com, aber das lässt sich mit Syno-Bordmitteln nur für synology.me erstellen.

 

[schor]

ok danke für die Info, was soll das 'example.com.' bewirken? Gibst du dann auch in DMS unter Apps bei den jeweiligen Aliases ein?

 

[Benares]

ok danke für die Info, was soll das 'example.com.' bewirken?

Ein Punkt am Ende bewirkt immer, dass keine DNS-Suffix-Suchliste durchlaufen wird. Die braucht man auch nicht, da es sich ja schon um einen kompletten Namen handelt. Bei CNAMEs macht man das so.

Gibst du dann auch in DMS unter Apps bei den jeweiligen Aliases ein?

Der Alias ist optional stört aber auch nicht, für den Reverse-Proxy aber eher unüblich. Wenn du Domain, Alias und die Ports setzt und nur 80/443 im Router weiterleitest, kannst du über
http(s)://drive.example.com
http(s)://diskstation/drive oder
http(s)://diskstation:<Port>
zugreifen. Dementsprechend werden auch die Freigabe-Links angezeigt.

 

[schor]

Alles klar vielen Dank

 

[schor]

Hallo nochmal,
der Forward funktioniert jetzt, auch beim Let's Encrypt/R3 Zertifikat werden die entsprechenden Subdomains unter 'gültig für' angezeigt. Jedoch bekomme ich im Browser für die jeweiligen subdomains (file.example.com, drive.example.com etc.) die Sicherheitswarnung nicht weg, obwohl ich 'enabls HSTS' bei den jeweiligen Applikationen angeklickt habe. Any ideas? Danke!
PS ich hab' auch schon versucht ein zusätzliches Zertifikat für die jeweilige Subdomain hinzuzufügen, ohne Erfolg.
Das 'Default Zerfifikat' scheint unbeeindruckt zu sein und zeigt weiterhin die jeweiligen Subdomains unter 'Configure' an, kann es also nicht auf das separat ausgestellte Zertifikat der Subdomain ändern...

PS2: Problem gelöst: Im 'default Zertifikat' unter 'Configure' kann man doch das andere Zertifikat für die jeweilige Subdomain eingeben. Es war nur ein Dartsellungsproblem des drop-down Menüs! Problem gelöst!