Nextcloud Erreichbarkeit über DDNS

[LORDNIKON1]

Hallo liebes Forum,

ich betreibe seit kurzem eine Nexctloud Installation auf meiner Synology DS220+ - funktioniert soweit ganz gut.
Für die Erreichbarkeit der Nextcloud aus dem Internet habe ich eine DDNS eingerichtet. Entsprechende Einträge sind im Router (Fritzbox 7430) hinterlegt, einschl. Portfreigaben. Auf der Synology habe ich die Firewall aktiviert und auch dort entsprechende Ports freigegeben, damit ich auf die Nextcloud zugreifen kann. Zusätzlich habe ich einen Virtuellen Host angelegt, der für die DDNS auf die Nextcloud verlinkt. Ich habe zudem ein Let's Enrypt Zertifikat erstellt, so dass der https: Zugriff auf die Nextcloud auch ohne Probleme funktioniert und der DDNS "vertraut" wird.
Nun zu meinem Problem: Ich habe bei IONOS für meine Domain eine Subdomain eingerichtet: nextcloud.xxxx.de. Für diese habe ich einen CNAME Eintrag erstellt, der auf die DDNS Adresse verweist.
Nach meinem Verständnis müsste doch nun wenn ich die Subdomain eingebe die Weiterleitung an die DDNS greifen, die Verbindung beim Router ankommen, der leitet durch zur Synology und über den virtuellen Host wird direkt das gewünschte Nextcloud Webverzeichnis angesteuert, so dass ich beim Nextcloud Login lande. -- So soll es zumindest sein - ist es aber leider nicht. Denn was ich stattdessen sehe ist das unschöne Webstation Bild "Web Station has been enabled. To finish setting up your website, please see the "Web Service" sectino of DSM Help. Zudem - und das verstehe ich auch nicht - wir die Verbindung als nicht sicher angezeigt. Nach meinem Verständnis sollte doch das Let's Encrypt Zertifikat hier greifen. Das tut es doch auch, wenn ich (denn das funktioniert ja) über die DDNS direkt auf die Nextcloud Installation zugreife.

Zwar lese ich hier und dort, dass es etwas dauern kann bis der CNAME Eintrag greift. Aber ich deute es so, dass der Eintrag durchaus greift, allerdings "falsch ankommt".

Habe ich das einigermaßen verständlich geschildert und kann mir einer von Euch helfen?

Herzlichen Dank und viele Grüße
LORDNIKON1

 

[stulpinger]

Du landest auf der Webstation, weil Du im Normalfall nur eine öffentliche IP hast
Nachdem bei mir Nextcloud unter Docker läuft, hab ich beim Reverse-Proxy einen Port angegeben, damit der "Zugriff" weiß, wohin er muss
Bin leider bzgl. virtuellen Host zu wenig Firm, aber da solltest Du nachhaken
Dokument-Root auf das Verzeichnis setzen von nextcloud zB.: "web/nextcloud" und den HTTP-Backend-Server einstellen auf nginx oder apache + PHP-Version
Von extern solltest Du ja eh über 80/443 kommen
HTTP-Gruppe sollte natürlich noch Zugriff auf das Verzeichnis haben
Anbei Foto bzgl. wiki-Konfig zur Veranschaulichung

 

[blurrrr]

Also erstmal (wenn man Deinen Nick so liest).... HACK THE PLANET!!! (und so....) Aber ganz unterhaltsam der viel, wenn auch völlig überzogen, aber ok ??

leitet durch zur Synology und über den virtuellen Host wird direkt das gewünschte Nextcloud Webverzeichnis angesteuert, so dass ich beim Nextcloud Login land

"Wie" betreibst Du denn die NC auf der Syno? Als "Web"-Ding direkt auf der Syno, als Docker-Container, oder als eigenständige VM?

Grundsätzlich ist der Ablauf als solches schon korrekt:

DNS: domain.tld -> dyndns -> dynamische IP
Route: Client -> öffentliche dynamische IP <- Router -> NAS
Webgedöns: Aufruf von "domain.tld" wird komplett durchgeleitet bis zum NAS, das muss auf "domain.tld" reagieren (vHost)
Zertifikat: Das erstellte LE-Zertifikat muss dann noch dem vHost zugewiesen werden

Zwar lese ich hier und dort, dass es etwas dauern kann bis der CNAME Eintrag greift. Aber ich deute es so, dass der Eintrag durchaus greift, allerdings "falsch ankommt".

Also als großer böser Hacker solltest Du aber schon wissen, was ein "nslookup" so macht und wie man es benutzen kann ? Würde dann ungefähr so aussehen (wenn der DNS-Record durch ist)...:

-> nslookup www.domain.tld

Server: UnKnown
Address: 192.168.x.x

Nicht autorisierende Antwort:
Name: mein-nas.dyndns.net
Address: 123.123.123.123
Aliases: www.domain.tld

Wünsche viel Erfolg!

 

[LORDNIKON1]

Vielen Dank für Eure schnelle und umfangreichen Antworten - und lasst mir doch meine Angelina Jolie in jungen Jahren "Hacker-Träume" (letzteres bin ich ganz sicher nicht, umso mehr aber eine großer Fan dieses Film-Klassikers).

Der Reihe nach, erst mal zu Dir, stulpinger.
Genauso wie Du es beschreibst, habe ich die Einstellungen beim Virtuellen Host vorgenommen. Der Host ist dort meine ddns.Adresse (müsste so eigentlich stimmen), der Dokument Root web/netxcloud, Http Backendserver ist bei mir "Apache 2.4", PHP: mein individualisierter PHP 7.3 Eintrag.
-- Deine Ausführungen zu den Ports stimmen denke ich (80/443)

Was Du für Deine Lösung mit Docker und Reverse Proxy beschreibst (wissen "wohin er mus") ist ja genau mein Ziel und dachte ich mit Virtual Host abzubilden aber das funzt leider nicht.

Damit ist auch Deine Nachfrage beantwortet, blurrr: Umsetzung "Web"-Ding, nicht Docker oder VM. Ja ja, nslookup gemacht und läuft.

Was das Zuweisen des LE Zertifikats zum VHost anbetrifft. Habe ich noch nicht gemacht, dürfte ja aber keine Auswirkung haben, sondern lediglich den Hinweis "unsicher" erzeugen oder nicht? Wobei: Der VHost ist doch die DDNS, dafür besteht das Zertifikat ja. Oder habe ich da einen Denkfehler?

 

[blurrrr]

und lasst mir doch meine Angelina Jolie in jungen Jahren "Hacker-Träume"

?

Habe ich noch nicht gemacht, dürfte ja aber keine Auswirkung haben, sondern lediglich den Hinweis "unsicher" erzeugen oder nicht?

Najo, es sollte so oder so ein Fehler kommen und nicht die Webstation-Seite, womit man sich die Fragen stellen muss:

a) Kommt der Request überhaupt "richtig" bei der Syno an? (Logfiles)
b) Wird der Request vom ReverseProxy überhaupt korrekt verarbeitet? (auch Logfiles)

...ach lol ey... hab grade nochmal gelesen... klar - wie immer - wieder alles ÜBERlesen...

Zusätzlich habe ich einen Virtuellen Host angelegt, der für die DDNS auf die Nextcloud verlinkt.

Das ist falsch. Wenn Du sagst "domain.tld -> via CNAME -> DDNS" willst Du ja "domain.tld" ansprechen, ergo geht der Request auch an "domain.tld" und genau das steht auch in der Anfrage, welche die Syno erreicht. Also muss dort "domain.tld" beim vHost stehen und nicht der DDNS.

Du kommst also - so wie du wolltest - mit domain.tld an, aber der vHost hört nur auf DDNS, deswegen kriegst Du auch die Webstation-Seite

 

[stulpinger]

wie gesagt, bin bei vhost nicht ganz firm,
sollte man eigentlich die nextcloud mit https://nextcloud.xxxx.de/next aufrufen ?

 

[blurrrr]

Nö, je nachdem wie es konfiguriert ist halt...

Der Web-ich-bin-gROOT-Pfad (sorry - is jetzt klar, oder?) ist der Ausgangspunkt für die Installation. Heisst kurzum:

vHost-Pfad: "/web/meine-nextcloudinstallation/" ist für die Website selbst "/" und somit das Rootverzeichnis. Wenn die Installation nun unter:

"/web/meine-nextcloudinstallation/next/"

vorgenommen wurde, wäre es aus Sicht der Website (und des Webservers) eben:

"domain.tld/next/"

Wenn der ganze Krempel allerdings direkt nach "/web/meine-nextcloudinstallation/" geschmissen wurde und die Domain domain.tld eben genau da drauf zeigt, dann kann man die Installation auch einfach unter domain.tld erreichen.

Kriegt man aber alles hin... ansonsten halt eine .htaccess mit rewrite...

 

[LORDNIKON1]

Mega:

Was Du schreibst, blurrr hat zum Ziel geführt: Beim Host muss nicht die DDNS eingetragen sein, sondern die Domain von der aus auf die DDNS verwiesen wird.

Ich komme jetzt auf die Nextcloud Login Seite, allerdings steht dann dort "Zugriff über nicht vertrauenswürdige Domain". Scheinbar muss ich in der Nextcloud in der "trusted_domains"-Einstellungen anpassen. Schaue später mal nach ob ich das hinbekomme.

 

[Andy+]

für meine Domain eine Subdomain eingerichtet: nextcloud.xxxx.de

Vermutlich musst Du "nextcloud.xxxx.de/nextcloud" eingeben.

 

[LORDNIKON1]

Komme mit der nextcloud.xxx.de schon drauf, bekomme nur dann die Fehlermeldung, die ich wohl Nextcloud-seitig regeln muss in den Einstellungen (so verstehe ich es zumindest).

 

[blurrrr]

"Mega"... Man, Du bist wie der Film... einfach nur völlig 90er ? ? (Ich fand die 90er bis auf ein paar Ausnahmen furchtbar, tendiere eher in Richtung 80er - vor allem was die Musik angeht ).

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

 

[LORDNIKON1]

Tja, kann nicht leugnen wann ich Heranwachsender war.

Ich glaube so ganz durchstiegen habe ich es aber immer noch nicht.

Folgeproblem: Wie bewerkstellige ich denn nun, dass eine weitere Subdomain (hier: DS.xxx.de, also der www.Zugang zur DS220+) auf den Port 5001 verweist, also auf den allgemeinen Diskstation Zugang? Weg sonst wie oben, also: CNAME von der Subdomain auf DDNS - Problem/Zwischenfrage: Wenn ich die gleiche DDNS (1) verwende, dann kommt die Anfrage beim Router an, der reicht automatisch weiter an 443, dann greift der VHost, der sagt: Da geht's lang, nämlich zum web/netxcloud Verzeichnis.
Nun will ich ja aber mit der weiteren Subdomain direkt meinen Diskstation Zugang ansprechen und gerade nicht bei der Nextcloud landen.
Ich habe deshalb eine weitere DDNS (2) angelegt, und von der DS.xxx. Subdomain auf diese weitere DDNS verwiesen. Die Anfrage kommt auch richtig an, allerdings muss ich händisch den Port ergänzen, sonst funzt das nicht. Mit Virtual Host kann ich das ja wohl nicht lösen, oder? Wenn ich da auf portbasiert gehe und den betreffenden Port 5001 eingebe, sagt mir die Synology der sei "bereits belegt".

Außerdem bekomme ich bei der angesprochenen Seite (also: DS.xxx.de:5001) eine Sicherheitswarnung. Für diese Seite wird dort als Zertifikat das "falsche" Zertifikat angezeigt, nämlich das für DDNS (1), das ich in der Synology hinterlegt habe. Löse ich das, indem ich ein weiteres Let's Encrypt Zertifikat anlege und zwar für die DDNS (2)?

 

[blurrrr]

Alles was "nicht" definiert ist, da greift die Standard-Regel "*"

Ich habe deshalb eine weitere DDNS (2) angelegt

Wenn ich Dich jetzt Frage, wofür der DDNS "zuständig" ist (also warum man das Ding nutzt) und ich gleichzeitig sage:

"eins.domain.tld" -> NAS (reagiert auf "eins.domain.tld")
"zwei.domain.tld" -> NAS (reagiert auf "zwei.domain.tld")

...ist Dir dann halbwegs klar geworden, warum es keinen Sinn macht, einen zweiten DDNS anzulegen?

EDIT: DNS (die CNAME-Records -> eins.domain.tld und Co) und DDNS (mein-nas.ddns.net) sind 2 völlig unterschiedliche Dinge, bitte nicht vermischen!

 

[LORDNIKON1]

Deshalb schreibe ich ja: Ich habe es nicht recht durchstiegen.

DDNS und CNAME habe ich denke ich schon geblickt. Aber wie ist denn dann die Lösung für Subdomain 2 direkt zu Login-Seite der Diskstation (ohne zusätzlich erforderliche :5001 Ergänzung), idealerweise ohne Sicherheitswarnung?

 

[blurrrr]

Nenene, so leicht kommste mir jetzt nicht weg, Freundchen... ? Du schreibst etwas von 2. DDNS... Welches "Problem" löst der DDNS an sich?

 

[LORDNIKON1]

Recht hast Du:

Ich habe verstanden, dass ich eine zweite dynamische IP Adresse dazu nutzen kann ein weiteres, individuelles Ziel (=Benutzeroberfläche der DS) anzusprechen. MIr ist nicht klar wie ich sonst die Weichenstellung zu dem bestimmten Port (hier nun also 5001) hinbekomme, damit ich bei der Benutzeroberfläche lande. Ist es jetzt verständlicher?

 

[blurrrr]

eine zweite dynamische IP Adresse

Hast Du 2 Internet-Leitungen, oder nur "1"?

P.S.: RED BOOK! ?

 

[LORDNIKON1]

Natürlich nur eine!
Vielleicht sollte ich wirklich mal im roten Buch nach der Lösungung schauen. Da steht ja faktisch alles drin.

 

[Fusion]

next.example.com > CNAME > dynDNS
>> vHost "next.example.com"

dsm.example.com > CNAME > dynDNS (one and only)
>> Systemsteuerung > Netzwerk > DSM Einstellungen > benutzerdefinierte Domain "dsm.example.com"

Fertig.
Alles 443 ohne Portangabe und ohne Warnmeldung, wenn die Zertifikate unter Systemsteuerung > Sicherheit > Zertifikate > Konfigurieren richtig gesetzt sind.

 

[Benares]

@LORDNIKON1
Um das mal etwas abzukürzen. Das Prinzip ist eigentlich recht einfach.
Du hast eine DDNS-Domain (z.B. domain.tld), darauf mehrere CNAMES (z.B. eins.domain.tld, zwei.domain.tld, ...). Das DDNS-Update erfolgt nur auf domain.tld (eins.domain.tld, zwei.domain.tld sind ja nur Aliase und zeigen daher automatisch auf die gleiche IP).
Im Router braucht es nur eine Portweiterleitung, z.B. von Port 443 auf Port 443 der DS.
Im Reverse-Proxy der DS konfigurierst du dann, wohin welcher DNS-Name weitergeleitet wird, z.B. eins.domain.tld auf die lokale nextcloud, zwei.domain.tld auf den lokalen DSM Port 5001, drei.domain.tld remote auf deinen PI, usw. usw.).
An der Stelle könnte man auch von https auf http (intern) umsetzen, damit man das ganze Zertifikats-Geraffel zentral abfackeln kann. Ggf. sind dafür aber auch noch einige rewrite-Rules für nginx notwendig.
Die einzige Krux ist, dass dein Zertifikat für alle Namen gelten muss. Prädestiniert ist deshalb ein Wildcard-Zertifikat für *.domain.tld