WebDAV unter verschiedenen Domains

[Splash_er]

Hallo,

ich habe folgendes Vorliegen:

1. WebDAV mit externen Zugriff via Let´s Encrypt Zertifikat (wo der WebDAV Server darauf ausgestellt ist)
   https://synology.extern:1234/was auch so im externen WebDAV Zugriff alles in Ordnung ist und tadellos funktioniert
2. SubDomain die ebenfalls mit einem Let´s Encrypt Zertifikat in der Synology hinterlegt ist (allerdings ohne, weil nur einmal machbar/pro Zertifikat, WebDAV Server-Dienst-Zuweisung)
   daten.domain
   welche beim Hoster mit dem CNAME Eintrag "https://synology.extern" eingetragen ist und auf die NAS verweist

Nun zum Problem:

• da wohl die SubDomain "daten.domain" nicht auf der Synology auf dem WebDAV Server ausgestellt werden kann, da ja schon die "synology.extern" dafür eingetragen ist und ich diese eben auch als Hauptdomainzugriff benötige, funktioniert der WebDAV Zugriff nicht unter Windows 10 Pro
• es kommt zwar die Abfrage der Nutzerdaten, aber nach OK kommt
  Das Netzlaufwerk konnte nicht verbunden werden, da der folgende Fehler aufgetreten ist: Ein an das System angeschlossenes Gerät funktioniert nicht.
• Wenn ich in den Sicherheitseinstellungen/Zertifikat den WebDAV Server auf die SubDomain "daten.domain" eintrage passt alles, aber eben dann nicht mehr mit der "synology.extern"

Meine Frage an die Profis: ist ein zwei-/mehrgleisiges fahren, mit verschiedenen SubDomains, überhaupt möglich, und wenn ja, wie wäre die Lösung?

1000 Dank
Tilo

 

[Fusion]

Natürlich ist das möglich, wenn man sich gedanklich von eine Adresse eine Möglichkeit löst.

Bitte abstrahieren, ich verwende offizielle Bespieldomains.

dav.example.com verweist per CNAME auf dynDNS.synology.me.
Damit zeigen beide auf deinen Anschluss und je nach Portweiterleitung auf deine DS.

Für dav.example.com holst dir ein LetsEncrypt Zertifikat und weißt es dem webdav Sererdienst unter Systemsteuerung > Sicherheit > Zertifikate > Konfigurieren zu.

Danach ist https://dav.example.com:1234 erreichbar, wenn entweder 1234 > 5006 umgeleitet wurde oder du 1234 im webdav Server als https Port eingestellt hast und 1234 > 1234 umgeleitet wurde.

Will man es komfortabler haben setzt man unter Systemsteuerung > Anwendungsportal > Reverse Proxy noch einen solchen auf für dav.example.com und Port 443 auf localhost und 5006.
Das Zertifikat muss man dann dem Reverse Proxy und nicht dem webdav Server zuordnen. Man redet dann nur noch mit dem proxy nicht mehr direkt mit dem Server.

Erreichbarkeit dann via https://dav.example.com
Portweiterleitung ist dann nur noch 80/443 nötig.

Für dynDNS.synology.me kannst du dir ebenfalls ein Zertifikat ausstellen lassen und es für 'Systemvoreinstellung' oder einen anderen gewünschten Dienst benutzen der entweder auch auf 80/443 lauscht oder mit Portangabe und Weiterleitung auch auf einem anderen Port.

Man kann also mit X beliebigen Domains fahren, solange diese im DNS System auf deinen Anschluß zeigen (also A record, CNAME, oder dynDNS, etc). Einzig es muss sich dann am Ziel auch jemand (ein Host, vHost, Benutzerdefinierte Domain, reverse proxy oder sonst wer) dafür zuständig fühlen und antworten.

 

[Splash_er]

Hallo Fusion,

vielen Dank für deine Antwort und Hilfeversuch.
Wie geschrieben funktioniert alles und ich habe auch alles so eingerichtet, aber eben nicht mit WebDav.
Ich denke ich habe mich evtl. etwas unklar ausgedrückt, deswegen erkläre ich mein Anliegen/Problem noch einmal anders.
Ich möchte von beiden Adressen:

• extern die Synology via https://dynDNS.synology.me:1234/
• extern die Subdomain via https://dav.example.com:1234/

auf das WebDAV zugreifen. Es soll keine "Umleitung" sein, also zwei externe Zugriffspunkte. Momentan, weil eben der WebDAVServer auf der dynDNS.synology.me eingestellt ist und nicht auf der Subdomain dav.example.com, funktioniert dies nur bei der dynDNS.synology.me. Die Anmeldemaske kommt zwar, aber eben mit einem Fehler, siehe erste Nachricht von mir. Wenn ich es umstelle, dann ist es anders herum.
Leider kann man ja keine Ports in den CNAME Eintrag einschreiben, was die Sache evtl. machbar machen würde.

Was mir aufgefallen ist, warum auch immer, das dieses Problem nur bei Windows 10 auftritt. Beim Mac war der Zugriff auf die Subdomain dav.example.com ohne Probleme möglich.

Evtl. geht dies mit einem Reverse Proxy Einstellung, nur weiß ich nicht recht wie?

Vielen Dank
Tilo

 

[Fusion]

OK, ist verstanden. Bevor ich inhaltlich antworte kurz die Sinnfrage vorweg: was ist der Hintergedanken / was versprichst du dir davon, dass du den webdav über zwei verschiedene Adressen ansprechen kannst?

Windows legt Wert darauf, dass die Zertifikate bzw die Namen darin und die Vertrauensketten eingehalten sind.
Entweder tut OS X das nicht in dem Maße oder es ist eine Ausnahme zugelassen, oder du hast einfach nur ein Caching Problem auf deinem Windows. Deshalb nach Möglichkeit immer von mehr als einem System aus testen.

Inhaltliche Antwort ergänze ich nachher vom Rechner aus noch.

 

[Splash_er]

"versprechen" tue ich mir nichts davon. Das eine ist der private Zugang, das andere soll der Businesszugang (nicht nur für mich) sein. Und da eben im Business nicht jeder die private Domainauflösung sehen soll und etwas angeht, dieser Weg.
Klar, ich könnte die private auf Business umstellen, aber wenn es einen Weg gibt würde ich mehrere SubDomains anlegen, um auf verschiedenen Bereichen auf die NAS zugreifen zu können. Dies ist die sauberere (CI) Lösung nach außen hin.
Ich hoffe ich habe es verständlich ausgedrückt?

Danke dir für deine Mühen...ich hoffe, es gibt einen Weg.
Tilo

 

[Fusion]

Dir ist aber klar, dass das nur eine optische Trennung auf dem Papier ist, mehr nicht.
Alle Namen zeigen immer auf die aktuelle IP deines Routers (ipv4) oder NAS (ipv6) direkt.
Also nur eine organisatorische Trennung.
Sicherheitstechnisch oder anderweitig hat dies keinerlei Einfluss.

Der webdav Server lauscht schon mal für sich unter keinem spezifischen Namen, sondern einfach auf seinem konfigurierten Port 5006 (oder geändert). Von extern eben der Port der dorthin weitergeleitet ist.
Deshalb landen auch alle Anfragen an sub.example.com:1234 auf dem webdav Server. Je nachdem welches Zertifikat dem webdav Dienst unter Systemsteuerung > Sicherheit > Zertifikate > Konfigurieren zugewiesen ist eben einmal mit Zertifikatsfehler und einmal nicht.

Jetzt sehe ich zwei Möglichkeiten, die erste hebt deine organisatorische Trennung wieder auf, wenn man sich die Zertifikats Details ansehen würde.
Der besteht darin sich ein Zertifikat auf 2 Namen ausstellen zu lassen (alternate name hinzufügen beim Beantragen) und dieses dem webdav Dienst zuweisen.
Dann sollte der Zugriff über beide Namen funktionieren aber würde wie gesagt, wenn man sich die Zertifikats Details ansieht den anderen Namen preisgeben.
Und zwei unterschiedliche Zertifikate lassen sie EINEM Dienst hier eben nicht zuweisen.
Daran scheitert auch die verworfen Idee es über zwei Portweiterleitungen 1234 > 1234 und 1235 > 1234 zu machen, da der webdav Dienst entweder über das Zertifikat den zweiten Namen preisgibt, oder beim zweiten Namen eine Zertifikats Warnung produziert.

Die zweite Möglichkeit ist via reverse proxy (Systemsteuerung > Anwendungsportal). Diese
Dazu stellst du den webdav für eine adresse korrekt ein (LE Zertifikat mit diesem Namen und dem webdav Dienst zugeordnet).
Für den zweiten Namen legst du einen Reverse Proxy an. Der lauscht dann halt nicht auf 1234 sondern auf 443.
Als Ziel hat dieser dann localhost:5006 oder passend.
Dem Reverse Proxy Namen ordnet man dann ebenfalls unter Systemsteuerung > Sicherheit > Zertifikate > Konfigurieren das namentlich passende Zertifikat zu.

Dann wäre z.b. Der Zugriff
https://dyndns.synology.me:1234/ und
https://dav.example.com/

Hier hat man sich sozusagen einen zweiten Dienst erstellt dem man ein anderes Zertifikat zuweisen kann und am Ende trotzdem auf den webdav Server landet.

Trennung ist wie gesagt nur organisatorisch, wenn du dir das verbildlichst:
Alle Domainnamen >> deine IP >> viele Dienste die sich je nach Hostnamen (sub.example.comport)) angesprochen fühlen.
Und wenn sich keiner angesprochen fühlt antwortet immer noch der Standard-Webserver der Syno oder der DSM, oder es kommt ein Timeout (404 error).

 

[Splash_er]

Hallo Fusion,

danke für deine Geduld...ich habe es mal getestet, komme aber nicht weiter. Evtl. habe ich noch einen Denkfehler.
Es wäre schön, wenn du mir da evtl. weiterhelfen könntest.

Die erste Möglichkeit kommt nicht in Betracht...und ja, es ist nur "kosmetischer" Natur. Möchte nur nicht das im Business mein privater DNS-Name ausgegeben wird, sondern eben die SubDomain. Schaut einfach besser aus. Und klar, kann ein etwas besser Bescheid Wissender die IP herausfinden...was ja aber unrelevant ist, da Firewall und Schutzmaßnahmen.

Ich habe mit der zweiten Möglichkeit begonnen, welche aber nicht recht klappt. Hier noch einmal meine Config in Kurzform, damit du evtl. den Fehler entdeckst:

• Paket-Zentrum/WebDAV Server
  HTTP aktivieren = aus
  HTTPS aktivieren = an -> Port = 1234 (nur Beispiel)
• Systemsteuerung/Sicherheit/Zertifikate
  dyndns.synology.me = Let`s Encrypt Standdartzertifikat mit WebDAV
  dav.example.com = eingebundenes Let`s Encrypt Zertifikat
• Windows 10 Pro Zugriff über Netzlaufwerk verbinden (IST-Stand)
  https://dyndns.synology.me:1234/ -> funktioniert
  https://dav.example.com:1234/ -> Nutzerdatenabfrage kommt, aber dann Abbruch -> am Mac aber funktionierend (warum auch immer)
• Systemsteuerung/Anwendungsportal/Reverse Proxy
  Allgemein:
  Quelle: Protokoll = HTTPS | hostname = dav.example.com | Port = 4321 (HSTS,HTTP/2,Zugangskontrolle alles nicht aktiviert)
  Ziel: Protokoll = HTTPS | hostname = localhost | Port = 1234
  Benutzerdefinierter Header = ist nichts eingetragen (das ist doch evtl. auch eine/die "kosmetische" Lösung...einfach den Header anders ausgeben, oder?!)
  Erweiterte Einstellungen = alles im Standart belassen (60,60,60,HTTP 1.1)

Für mein Verständnis sollte jetzt via https://dav.example.com:4321/ das ganze funktionieren, da er auf local:1234 umleitet. Es dauert auch etwas länger...und es kommt die Anmeldemaske, welche aber mit dem Fehler "Der Netzwerkpfad https://dav.example.com:4321/ wurde nicht gefunden" abbricht.

Danke für deine Geduld!

 

[synfor]

oder es kommt ein Timeout (404 error).

Beim 404er bekommt man eine Antwort, beim Timeout nicht.

 

[Splash_er]

ja, kann sein, aber die 60 Sekunden sind noch nicht um...das ist etwas kurios. Könnte es zum Test mal hochsetzen...

 

[Splash_er]

habe es mal hochgesetzt, aber ohne Erfolg. Die Anmeldemaske kommt ja...und er macht gefühlt ewig rum, aber bricht am Ende ab.

 

[Fusion]

Und Port 4321 wird auch an die DS weitergeleitet?
Wieso nimmst nicht 1:1 mein Beispiel mit 443, dann hättest kein weiteren Port aufmachen müssen?
Hintergrund: die Dienste alle auf 443 lauschen lassen, nur unterschieden nach dem Namen, nicht nach Ports.

Hast du Mal ein Bild von der Zertifikatsliste und der Konfigurationsliste? Kannst mir auch privat schicken wenn du willst.

 

[Penthys]

Windows hat sich zickig mit den Zertifikaten. Es wird für jede Domain das passende Zertifikat benötigt.

 

[Splash_er]

@Fusion
Danke für deine hervorragende Hilfe! MEGA

@Penthys & @synfor
ebenfalls Danke...

...am Schluss war es ein Denkfehler von mir in der Sophos Firewall. Ich muss ja den neuen Port an den gleichen Port weiterleiten, da der Reverse Proxy in der Synology das macht und nicht die Sophos Firewall. Ich hatte es auf den anderen, schon existierenden, gelegt.

Nun passt alles.

Vielen Dank für eure Hilfe
Tilo

 

[Splash_er]

Und Port 4321 wird auch an die DS weitergeleitet?
Wieso nimmst nicht 1:1 mein Beispiel mit 443, dann hättest kein weiteren Port aufmachen müssen?
Hintergrund: die Dienste alle auf 443 lauschen lassen, nur unterschieden nach dem Namen, nicht nach Ports.

Hast du Mal ein Bild von der Zertifikatsliste und der Konfigurationsliste? Kannst mir auch privat schicken wenn du willst.

...ich mag für so etwas lieber extra Ports, weit ab vom Standard. Die Portsscans und Bots sind mit auf dem HTTPS Port einfach zu viele.