Nextcloud Erreichbarkeit über DDNS

[blurrrr]

Ja ne, komm, ich will mal nicht so sein - wäre aber schon wirklich gut, wenn Du verstehst, warum die Dinge so funktionieren, wie sie funktionieren, damit Du nicht ständig vor den gleichen Problemen stehst

Der DDNS ist nur eine Möglichkeit, Deine - sich ständig ändernde - IP mit einem festen Ansprechpunkt zu versehen.

"domain.tld -> A -> dynamische IP"

....mag eine Zeit funktionieren, danach ändert sich die IP und es geht wieder NIX, daher auch....

"domain.tld -> CNAME -> DDNS -> dynamische IP" bzw. in Deinem konkreten Fall machen wir es mal so:

"EINS.domain.tld -> CNAME -> DDNS1 -> dynamische IP"

Was jetzt wichtig wäre zu wissen: Das "Routing" (also wo welche Pakete entlang wandern (via "IP")) interessiert einen Webserver nicht die Bohne, der reagiert nur auf das, was "angefragt" wurde (via "http"). Ist eine andere Protokollschicht (IP vs http).

Kurzum bedeutet das jetzt in erster Instanz, dass Du 2 Dinge hast:

1) Das Paket muss von A nach B
2) Du gibst was in den Browser ein (domain.tld) und es muss auf dem NAS im richtigen Verzeichnis (vHost) landen

"Fast" alles was oben steht, bezieht sich "nur" auf Punkt "1" (A -> B - Routing/IP). Hierbei muss der Client irgendwie den Server erreichen und diesem seine Anfrage übermitteln (was er halt möchte). Es wird also im DNS geschaut, an wen der Client seine Anfrage schicken muss:

eins.domain.tld wird aufgelöst auf -> DDNS, wird wiederum aufgelöst auf -> aktuelle dynamische IP - damit steht das Ziel fest, wir schicken unser Paket mit der Anfrage nach "eins.domain.tld" an? Genau, die dynamische IP.

Damit ist das (hoffentlich?) einigermaßen klar. Somit ist der DDNS nur als Bindeglied zwischen den richtigen DNS-Einträgen und der dynamischen IP anzusehen und auch - so wie Du es machst - nur für das Routing bzw. die Informatioen daraus (aktuelle IP) wichtig. Ergo erstmal alles nur "IP".

Nun kannst Du aber genauso gut hingehen und sagen:

"ZWEI.domain.tld -> CNAME -> DDNS1 -> dynamische IP"

Das "Ziel" bleibt das gleiche, nur das was "angefordert" wurde (ZWEI.domain.tld) ändert sich. und das ist Teil des http-Protokolls.

Ist ein bisschen so, als würden wir beide in Mehrfamilienhäusern wohnen und würden uns ständig Briefchen schicken, ziehen dabei aber ständig um ??

Das aus dem Browser ist also das angefragte (eins.domain.tld) und der vHost-Record auf dem NAS reagiert entsprechend darauf.

Soll also bedeuten:

Ich habe verstanden, dass ich eine zweite dynamische IP Adresse dazu nutzen kann ein weiteres, individuelles Ziel (=Benutzeroberfläche der DS) anzusprechen.

Ist nicht so ganz richtig... hoffe es ist klar geworden, warum nicht

Davon ab kannst Du halt für die Erreichbarkeit des DSM auch noch einen entsprechenden FQDN (irgendwo in der Systemsteuerung bei den DSM-Einstellungen) anlegen, darauf sollte die Syno dann sowieso entsprechend reagieren - habe ich auch bei einigen Systemen laufen. Die Lets-Encrypt-Zertifikate kanst Du dann bei den einzelnen vHosts noch zuweisen (kannste auch pro vHost einfach ein eigenes nehmen, Limit ist hoch genug).

 

[blurrrr]

Die einzige Krux ist, dass dein Zertifikat für alle Namen gelten muss. Prädestiniert ist deshalb ein Wildcard-Zertifikat für *.domain.tld

Beste Idee ever... von wieviel hunderten FQDNs sprachen wir hier noch gleich? Achja, hab ich ganz vergessen... 2(!).... Wildcard-Zertifikat... Ja ne, is klar ??

 

[Benares]

Egal ob 2 oder n. Trotzdem nervt es, wenn man bei jeder neuen Idee, jedem neuen Dienst, wieder an seinem Zertifikat rumfummeln muss.

 

[blurrrr]

Wenn Dein Sohn schon studiet hat, kannst Du doch garnicht mehr so jung sein, dass Du zu der Fraktion gehörst, wo "arbeiten" ein Schimpfwort ist und doch bitte alles von alleine funktionieren soll (so ganz ohne Aufwand)? ? Aber hast schon recht, sofern es denn mehr werden "sollte" (was ich jetzt erstmal so nicht gelesen habe), ist das irgendwann nicht mehr so lustig. Auf der anderen Seite - Kenntnisstand des TO - heisst ja nicht umsonst "learning by doing" ? Oder wie mein (*****)-BWL-Dozent zu sagen pflege: "Was man schreibt, das bleibt!" (Also nix mit Handouts, alles von bekloppten selbstbeschriebenen Folien abschreiben...)

 

[Benares]

Ich hab mich vor einem knappen Jahr ins Privatiers-Leben zurückgezogen und berate nur noch. In meinen 35 Berufsjahren in der IT habe ich aber gelernt, dass man über sein Tun nachdenken sollte, spätestens, wenn man etwas zum zweiten Mal tut . Wer macht sich schon gerne unnötige Arbeit - dann lieber einmal richtig ?

 

[blurrrr]

Schon richtig, aber erstmal sollte man die Klamotte generell laufen, also schön einen Schritt nach dem nächsten (grade wenn man keine Ahnung hat) ??

 

[LORDNIKON1]

Vielen Dank erstmal für Eure ausführlichen Beschreibungen.

Ich habe jetzt leider einige Knoten in meiner Denke und komme überhaupt nicht mehr weiter. Versuche trotzdem mal zusammen zu fassen wo ich gerade stehe:

1. wenn ich https://xxx.ddns.net eingebe, ist die aufgerufene Seite zwar verschlüsselt, allerdings die eingangs erwähnte "Begrüßungsseite" (Web Station has been enabled".
2. wenn ich den Port 5001 (also :5001) dranhänge, komme ich zum Begrüßungsscreen der DS
3. wenn ich nun aber Port 443 angebe, springt der Browser automatisch auf xxx.ddns.net und zeigt die geliebte "Begrüßungsseite" an.
4. wenn ich die Domain DS.xxx.de eingebe, komme ich zur Begrüßungsseite der DS, allerdings ist die Seite leider nicht vertrauenswürdig.
5. (hatte ich zuvor schon beschrieben): wenn ich die Domain Nextcloud.xxx.de eingebe, lande ich auf einem Nextcloud Welcome Screen, der mich darüber informiert, dass leider ein Zugriff über eine nicht vertrauenswürdige Domain erfolgt.

Ich halte weiter fest: Ich habe bei meinem Domainanbieter (dort ist für die Domain, also nach meinem Verständnis auch für die angelegten Subdomains, eine SSL Wildcard hinterlegt)
Ich habe für die Subdomain Diskstation einen CNAME zu xxx.ddns.net und für die Subdomain Nextcloud einen CNAME ebenfalls zu xxx.ddns.net (also gleiche DDNS) angelegt.

Den VHost sollte ich richtig eingerichtet haben

 

[blurrrr]

1. wenn ich https://xxx.ddns.net eingebe, ist die aufgerufene Seite zwar verschlüsselt, allerdings die eingangs erwähnte "Begrüßungsseite" (Web Station has been enabled".

Die vHosts reagieren alle unterschiedlich. Es wird aber etwas geben, was "*" abfängt (also alles, was nicht extra aufgeführt ist) und das wird zur WebStation-Standardseite geleitet

2. wenn ich den Port 5001 (also :5001) dranhänge, komme ich zum Begrüßungsscreen der DS

Korrekt, weil auf diesem Port das DSM lauscht (ausser, Du definierst etwas anderes)

3. wenn ich nun aber Port 443 angebe, springt der Browser automatisch auf xxx.ddns.net und zeigt die geliebte "Begrüßungsseite" an.

Sagtest Du nicht @1) "1. wenn ich https://xxx.ddns.net eingebe"?

4. wenn ich die Domain DS.xxx.de eingebe, komme ich zur Begrüßungsseite der DS, allerdings ist die Seite leider nicht vertrauenswürdig.

Dann stimmt das Zertifikat mit dem FQDN nicht überein. Näheres dazu findest Du in den Zertifikatsdetails.

5. (hatte ich zuvor schon beschrieben): wenn ich die Domain Nextcloud.xxx.de eingebe, lande ich auf einem Nextcloud Welcome Screen, der mich darüber informiert, dass leider ein Zugriff über eine nicht vertrauenswürdige Domain erfolgt.

Korrekt, da gibt es in der nextcloud-config einen Parameter namens "trusted_domains"...:

Was die Fehlermeldung angeht... "trusted_domains -> nextcloud.domain.tld" könnte helfen

Ich würde mal sagen: Bekomm erstmal das eine zum laufen, danach dann das andere... Nicht alles gleichzeitig...

 

[LORDNIKON1]

Die oben genannte Variante von "Fusion" hörte sich für mich noch am nachvollziehbarsten an. Leider ließ sie sich so nicht umsetzen. Ich befürchte mein Unwissen setzt sich beim Thema Zertifikate fort.

Jedenfalls habe ich ein Let's Encrypt Zertifikat für die DDNS erstellt. Dort wird in der Konfiguration unter "Dienste" auf die Subdomains verwiesen, also DS.xxx.de sowie Nextcloud.xxx.de.

 

[blurrrr]

Das ist nicht richtig, weil Du nichts via DDNS ansprichst (das ist ja nur die reine Brücke zwischen statischem Ansprechpunkt und dynamischer IP), hat mit der http-Kommunikation so rein garnichts zu tun.

Ansprechpunkt ist z.B. nextcloud.domain.tld, ebenso reagiert der vHost darauf, also muss das Zertifikat auf nextcloud.domain.tld ausgestellt sein (damit es zum angesprochenen Namen passt).

 

[LORDNIKON1]

Ich würde mal sagen: Bekomm erstmal das eine zum laufen, danach dann das andere... Nicht alles gleichzeitig...

Das ist sehr wahr. Aber wirklich abschichten lässt sich das leider für mich nicht.

 

[blurrrr]

Halt Dich erstmal an nextcloud.domain.tld und krieg das erstmal zum laufen. Änderung in der Nextcloud-Config bzgl. trusted_domains ...

 

[LORDNIKON1]

Danke Dir, blurrrr. So mache ich das mal.

 

[LORDNIKON1]

So, die Nextcloud ist wieder erreichbar und der Aufruf über nextcloud.xxx.de klappt auch. Gleiches gilt für den Aufruf über DS.xxx.de. Komme an beim Home Bildschirm der DS. Nun muss ich "nur noch" das Zertifikatsthema in den Griff bekommen.

 

[blurrrr]

Und das verhält sich derweil wie? Zertifikate sind ja "nur" noch "on top", da musste jetzt eigentlich jedem vHost nur noch das richtige zuweisen

 

[LORDNIKON1]

Aaaaaalso: Danke für's Mitfiebern. Ich habe es doch tatsächlich geschafft. Eigentlich war die Lösung ganz einfach, habe ein LE Zertifikat angelegt, das die nextcloud.xxx.de betrifft und eines, das die SD.xxx.de betrifft - läuft einwandfrei. Das Nextcloud ist das Standard-Zertifikat, das andere habe ich in der Konfiguration entsprechend eingestellt, dort wird dann interessanterweise auch "nextcloud" als Dienst angezeigt, man kann dann aber einfach das andere Zertifikat dafür wählen. Diese "Verbindung" der beiden Zertifikate war mir in der Logik so nicht klar.

Und nochmal extra für Dich, blurrr:
"This is our world now... the world of the electron and the switch [...] We exist without skin color, without nationality, without religious bias... and you call us criminals. [...] Yes, I am a criminal. My crime is that of curiosity."

Schaue ich mir zur Feier des Tages heute direkt nochmal an. Geht eigentlich immer!

 

[blurrrr]

Schön, dass Du es hinbekommen hast ?? Falls mal was dazu kommt, einfach ebenso verfahren. Alternativ gibt es noch die Möglichkeit von "Wildcard"-Zertifikaten (*.domain.tld - gilt dann für alle Subdomains - also eines für alle), allerdings sind die Verfahren dafür ein wenig anders (vgl. DNS-Challenge) und der DNS-Anbieter muss entsprechendes unterstützen (via DNS-API), ansonsten ist alle 3 Monate Handarbeit angesagt und darauf hat man nicht wirklich Lust... ??