Nexcloud nicht erreichbar

Hallo zusammen,

da ich nicht weiß, wo genau das Thema am besten rein passt, habe ich es erst mal unter DynDNS gepostet.
Darf gerne in den richtigen Bereich verschoben werden.

Nun zu meinem Problem (bitte komplett lesen):
Ich habe mir einen Heimserver mit Proxmox aufgesetzt.
Darauf läuft PiHole und Zoraxy als Container, Nextcloud als VM. Rest ist derzeit nicht wichtig.
Angebunden bin ich mit einer FritzBox 7490.
Zoraxy deswegen, da es mir besser gefällt als NGINX.
Proxmox deswegen, da ich mit Unraid keinen anständigen ZFS-Raid bekomme wie ich gelesen habe, zudem stört mich das mit dem USB-Stick.
Proxmox lasse ich einfach auf einer SSD mit 2x4TB-HDD als ZFS-Pool laufen.

Derzeit habe ich noch eine NAS von Synology auf der ebenfalls NC läuft.
Diese Instanz ist aus dem Netz problemlos erreichbar.
In der Fritte habe ich natürlich den DDNS-Eintrag von Synology derzeit drin.
Leider ist es mir nicht möglich über Zoraxy eine DDNS-Verbindung zu meiner neuen NC-Instanz zu erhalten (warum, eine neue NC-Instanz? Dazu gleich noch etwas).

Ich habe die Daten von IPV64 folgendermaßen in die FB eingetragen (Domainane und Key habe ich mit XXX markiert, muss ja keiner wissen :wink: ):
Update-URL: https://ipv64.net/update.php?key=XXX&domain=XXX.home64.de&ip=&ip6=
Domainname: XXX.home64.de
Benutzername: none
Passwort: none

Zoraxy habe ich dann den Port 80 und 443 in der FB freigegeben und den Reverse-Proxy in Zoraxy mit SSL-Zertifikat angelegt.

Leider bekomme ich bei diesen Einstellungen keinen Kontakt zu meiner neuen NC-Instanz, obwohl ich eigentlich alles richtig eingetragen habe, meiner Ansicht nach.
Die FB lasse ich über die DNS des PiHole laufen, damit alle Geräte im Netzwerk darüber laufen.

Zudem habe ich noch eine WireguardVPN in der Fritzbox, mit der ich allerdings nur am Handy und am PC angeschlossen bin.
Aber auch mit ausgeschaltetem Wireguard funktioniert es nicht. Auch habe ich das PiHole mal ausgeschaltet und getestet, aber es gab keine Besserung.

Zwischenzeitlich hatte ich sogar versucht unter IPV64 die IP meiner NC-Instanz direkt anzusprechen.
Das hat zwar mal funktioniert, aber NC hat das fehlende SSL-Zertifikat bemängelt, da ich unter IPV64 direkt kein SSL-Zertifikat hinterlegen kann.

Mittlerweile habe ich in der FB wieder die Daten von Synology unter DDNS eingetragen, damit wenigsten die anderen Container wieder ansprechbar sind von außen.

Nur über VPN mag ich nicht arbeiten, da ich auch an einem fremden Rechner Zugriff auf meine Container haben will.
VPN ist für mich nur ne Absicherung fürs Handy.

Noch kurz für die Interessierte, warum eine neue NC-Instanz.
Das hat zwei Gründe.
Zum Einen funktioniert im Portainer unter Synology der Collabora-Client nicht, selbst als ich ihn als eigenen Container angelegt habe wollte NC nicht mit Collabora zusammen arbeiten.
Mit der neuen NC-Instanz als VM unter Proxmox funktioniert das einwandfrei mit dem eingebauten Collabora.
Zum Anderen will ich auf Dauer weg von Synology und alles auf meinem eigenen Server selbst hosten.
Der hat genug Power und genug RAM im Gegensatz zu meiner kleinen DS220+ mit 10GB-RAM :wink:

Ich komme gerade nicht weiter und benötige Hilfe.

Bitte keine Fragen zu dem Warum der Config. Das bringt mich nicht weiter :wink:

Lieben Gruß,
Dirk

Moin, was genau meinst du damit, dass du in der FB den D(yn)DNS von der Synology eingetragen hast?

Da ich ne NAS von Synology habe, muss ich die DDNS von Synology in die FB eintragen, um die Dienste der NAS zu nutzen.
Meintest du das, oder wo es eingetragen wird?
Für letzteres:

Lieben Gruß,
Dirk

Vorweg: zu konkreten Problemen mit Zoraxy, Proxmox, etc. kann ich nichts schreiben, denn bei mir läuft die NC-Instanz in einer KVM ohne Proxmox-Clickibunti und ich verwende NGINX.

Warum schreibe ich dir dann hier?
Weil ich denke (so liest es sich jedenfalls für mich in deiner Problembeschreibung) dass du deine NC via der Account Update URL oder der Domain Update URL erreichen willst. Besser wäre es meiner Meinung nach aber in ipv64 einen Präfix-Eintrag anzulegen und dann die Präfix Update URL zu verwenden. Genau so mache ich es jedenfalls.
Das SSL-Zertifikat wird dann für diesen konkreten Präfix erstellt und angefordert, Also z.B. für nexctcloud.DeineDomain.ipv64.net statt für DeineDomain.ipv64.net.
Damit das reibungslos funtioniert musst du dann bei ipv64 das voreingestellte Häkchen bei Wildcard (*.) automatisch setzen? entfernen und Präfix-Zeilen (je eine für ipv4 und ipv6) für die Subdomain, also z.B. nexctcloud.DeineDomain.ipv64.net anlegen. Bei Als A-Record ist das natürlich die WAN-IPv4-Adresse der FritzBox. Als AAAA-Record hingegen kann dort ein Eintrag im Format „Interface-ID“ oder „EUI-64 MAC“ stehen, der zur deiner NC-Instanz gehört.
In der FritzBox selbst verwendest du dann einen Eintrag für DynDNS via ipv64, wie er unter Mit AVM Fritzbox IPv6-Prefix Updaten in den Anleitungen beschrieben wird. Wichtig ist dann noch, dass in der FritzBox unter Heimnetz - Netzwerk - Netzwerkeinstellungen - weitere Einstellungen - IPv6-Einstellungen die Router Advertisement im LAN sowie DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen aktiv sind.

Warum halte ich das für besser? Let’s Encrypt bevorzugt bei Zertifikatsanforderungen IPv6 (ich vermute du verwendest auch Let’s Encrypt, obwohl du das nirgends schreibest). Sobald es also einen DNS-Eintrag für IPv6 gibt will Let’s Encrypt das Zertifikat darüber erstellen. So wie du den Eintrag hier für ipv64 abgebildet hast, verwendest du ipv6 und nicht nur ipv4. Jetzt verweist ein IPv6-EIntrag bei ipv64, so wie du ihn wohl per Account Update URL oder der Domain Update URL in deiner Fritte angelegt hast aber auf die IPv6-Adresse der Fritte und eben nicht auf die der Nextcloud-Instanz. Das ist natürlich ein Problem, wenn du dann kein NAT auch für IPv6 angelegt hast. Bei IPv6 braucht es aber kein NAT mehr, denn die Geräte im LAN bekommen (bei richtiger Konfiguration) ja routebare öffentliche IPv6-Adressen von der Fritte zugewiesen. NAT braucht es nur noch bei IPv4.
Bei mir sieht die Lösung somit so aus, dass ich eben an meiner Nextcloud eine IPv6-Adresse wie 2a02:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX anliegen habe, deren zweite Hälfte aus der „Interface-ID“ oder „EUI-64 MAC“ besteht und sich daher nur der IPv6-Prefix nach Zwangstrennung durch den Provider ändert. Diesen IPv6-Prefix kann in deinem Fall aber sogar die Fritte updaten. Bei mir nicht, denn ich habe statt der Fritte Modem und pfsense. Daher verwende ich das APT Debian DDNS IPv64 Package, ebenfalls in den Anleitungen bei ipv64.net beschrieben. So brauche ich in den Regeln der Firewall für IPv6 nur die Ports 80 und 443 für die Nextcloud öffnen und bräuchte nur bei IPv4 auch noch NAT dazu konfigurieren. Praktisch verzichte ich aber auf ipv4 für die Nextcloud geich ganz, denn die ist auch rein über ipv6 zu erreichen, auch mobil und auch aus dem Ausland.
Es ist nämlich eine häufig geteilte aber unzutreffende Annnahme, dass IPv6 in ausländischen Mobilfunknetze nicht funktioniert. Zutreffend ist das bei allen mir bekannten Mobilfunkprovidern in den APN-Voreinstellungen fürs Roaming nur IPv4 aktiv ist. Das kann man aber selbst leicht auf den Mobilgeräten in den Einstellungen ändern und IPv6 im Roaming ebenfalls aktivieren. Mit diesen Einstellungen können meine mobilen Geräte (Tablet, Smartphone) dann auch i Frankreich, Spanien, etc. problemlos das Adressbuch oder den Kalender mit meiner Nextclout Zuhause über IPv6 synchronisieren. Und IPv6 wird sowieso bevorzugt wenn es verfügbar ist und eben die DNS-Server auf korrekte IPv6-Adresse verweisen.

Erst mal vielen Dank für die Antwort und die gute Erklärung.
Ich habe es nun auf Deine Art versucht und zumindest ist meine NC-Instanz nun zu erreichen.
Leider erhalte ich von NC die Antwort, dass ich ohne SSL-Zertifikat darauf zugreifen will, obwohl das Zertifikat in Zoraxy hinterlegt ist.

Hier habe ich also noch eine Aufgabenstellung, die ich lösen muss, aber keine Ahnung habe wie, da ich, wie oben gesagt, das SSL-Zertifikat für die Subdomain angelegt und in Zoraxy eingefügt habe.

Lieben Gruß,
Dirk

Und welche Update-URL wird hier genau verwendet? Ist es die Account Update URL oder die Domain Update URL passen URL und Zertifikat nicht zusammen, wenn du das SSL-Zertifikat für die Subdomain angelegt hast.

Ich glaube, da habe ich das nächste Problem.
Ich brauche mehrere Container (NC, Immich, HomeAssistant, Paperless und so weiter), daher habe ich die Account Update URL angegeben.
Ich weiß auch nicht, ob ich in der Update-URL mit Wildcards arbeiten kann.
Fühlt sich für mich zumindest falsch an, daher habe ich die Account Update URL angegeben.
Die explizite Update-URL für die NC-Instanz wäre wohl zu wenig für alles, was noch kommen soll.

Edit: Ich habe nun die Domain Update URL eingetragen.
Da durch ist zwar IPv6 der FB unbekannt, aber IPv4 ist angemeldet.
Vorher war beides angemeldet.
An dem Verhalten von NC (kein SSL-Zertifikat) hat sich leider nichts geändert.
Ich versucht es nochmal mit NGINX, da ich das Zertifikat dort direkt auswählen kann. Bei Zoraxy zieht er sich automatisch und ich habe keinen Einfluss darauf welches Zertifikat er sich zieht.

Sobald du mehrere Container über ipv4 und identischen Port erreichen willst, Beispiel Nextcloud und HomeAssistant über die TCP-Ports 80/443, dann wird das so sowieso nicht gehen. Du kannst mit ipv4 via NAT nur einmal einen Port an einen Client weiterleiten, nicht an zwei. Let’s Encrypt verlangt für Erstellung und Aktualisierung des/der Zertifikate zwingend die Erreichbarkeit über TCP-Port 80.

Ich dachte, dass LetsEncrypt (ja, das nutze ich) bei einer DNS Challenge auch über Port 443 arbeitet?
So hies es jedenfalls in dem Video von Dennis.

Meiner Erfahrung nach nicht.
In meiner pfsense ist TCP-Port 80 für die Nextcloud dicht, denn die ist auf TCP-Port 443 konfiguriert. Wenn spätestens nach 90 Tagen das SSL-Zertifikat über Let’s Encrypt erneuert werden muss, muss ich vorher immer eigens TCP-Port 80 öffnen, damit das Zertifikat erneuert werden kann.
Ich bin nach dieser Anleitung (Nextcloud auf Ubuntu Server 22.04 LTS mit nginx, PostgreSQL/MariaDB, PHP, Let's Encrypt, Redis und Fail2ban » DecaTec) bei der Installation meiner Nextcloud vorgegangen. Jan schreibt dort auch klar, das TCP-Port 80 verwendet wird bei Erstellung und Aktualisierung des Zertifikats.

Aaaalso,
ich bin schon weiter als vorher.
Immerhin kann ich meine NC-Instanz mittlerweile über cloud.meinedomain.home64.de ansprechen.
Allerdings erhalte ich immer noch die Aussage bei NC, dass ich kein SSL-Zertifikat habe, obwohl es hinterlegt und aktiv ist.
NGINX habe ich kurz getestet, aber ich habe das mit der DNS-Challenge nicht geschafft und auch kein SSL-Zertifikat erhalten, obwohl ich NGINX beide Ports 80/443 freigegeben habe vorher.
Nun bin ich wieder bei Zoraxy, aber da ist das gewohnte Bild…

Ich bin so langsam ratlos

ich glaube wir drehen uns im Kreis. Ich wies ja schon darauf hin, dass Let’s Encrypt bei Zertifikatsanforderungen IPv6 bevorzugt. Deine Update-URL: https://ipv64.net/update.php?key=XXX&domain=XXX.home64.de&ip=&ip6= legt auch Einträge für eine IPv6-Adresse an. Zudem ist bei ipv64.net standardmäßig das Häkchen für Wildcard (*.) automatisch setzen? vorhanden. Jetzt ist die Frage auf welche IPv6-Adresse das nun zeigt. Ich kann es nicht nachvollziehen, denn bei mir ist es nicht gesetzt und ich habe auch keine FritzBox.
So wie ich dich verstehe hast du aber in der FritzBox Freigaben für die Nextcloud für die Ports TCP 80, 443. In diesen Freigaben kannst du auch Ping6 für die Nextcloud erlauben. Mach das mal. Dann ping (ich meine ping6, wegen ipv6 - das ist wichtig weil Let’s Encrypt bevorzugt ipv6 vor ipv4) mal aus einem externen Netz, also Mobilfunknetz die Nextcloud über deren URL bei ipv64 an, unter der du deine Nextcloud erreichen willst, also z.B. nc.DeineDomain.ipv64.net oder nextcloud.DeineDomain.ipv64.net.
Die Frage ist: klappt das und wenn ja mit welcher IPv6-Adresse, also die IPv6-WAN-Adresse der FritzBox oder die des Servers auf dem die Nextclout gehosted wird?

Moment…vielleicht ist das Fehler.
Ich habe in der FB keine Freigaben für NC erstellt, sondern nur für Zoraxy auf den Ports 80/443.
NC hat keine Freigaben in der FB, da ich davon ausgehe, dass die Verbindung über Zoraxy hergestellt wird.
Wenn ich aber für NC die Port-Freigaben erstelle, muss ich Zoraxy dann raus schmeißen aus den Freigaben?
Immerhin können ja nicht beide auf den gleichen Port laufen. Das macht meine FB schon nicht.
Nun habe ich ja unter Proxmox keine speziellen Ports mehr, sondern nur noch die IPs.

reden wir ohnehin aneinander vorbei. Ich nutze ja nginx und mir sagt dieses ganze (Docker) Container-Gedöns eh nichts. Bei mir läuft nginx auf dem gleichen vServer wie nextcloud. Somit haben auch beide identische IP-Adressen (ipv4 und ipv6). Ich hab halt einen physikalischen Server mit ausreichend Speicher und SSD und auf dem laufen mehrere vServer mit Debian 12. Auf einem davon läuft eben nginx, php und Nextcloud, so wie in der von mir verlinkten Anleitung beschrieben.

Ich danke Dir trotzdem für Deine Hilfe.
Auch wenn ich immer noch daran arbeiten muss das zum Laufen zu kriegen.
Es waren für mich auf alle Fälle gute und wichtigen Denkanstöße dabei und nun versuche ich einen eigenen Port auf meiner VM hier für zu erhalten, damit ich direkt darauf verweisen kann.
Ansonsten müsste ich mir einen Docker-Container anlegen und alle Dienste darüber laufen lassen.

Ich sehe, ich habe noch Arbeit vor mir :wink:

Da du die Nextcloud ja auch erreichen kannst, nur eben ohne gültiges Zertifikat, muss dem auch so sein. Sonst würdest du ja nicht die Fehlermeldung erhalten mit dem Hinweis „Zugriff über eine nicht vertrauenswürdige Domain“.
Insofern ist dein Denkansatz auch genau richtig.
Das Problem ist also beim Zertifikat zu suchen, bzw. bei der Domain für das es erstellt wurde und/oder über die du am Ende diese Fehlermeldung angezeigt bekommst.

Nachtrag: das was du beschreibst kenne ich auch. Wenn ich meine Nextcloud über deren private IPv4-Adresse aus dem LAN erreichen will, dann ist das Zertifikat auch nicht gültig. In meinem Fall habe ich da eine Sicherheitsausnahme hinzugefügt. Würde ich diese Entfernen hätte ich die gleiche Fehlermeldung wie du. Siehe Abbildung:


Das passiert immer dann, wenn man die Nexcloud über eine andere URL erreicht, als die für die das Zertifikat erstellt wurde.

Das Problem ist nur, dass das Zertifikat genau für diese Subdomain gemacht wurde.
Ich habe nun die Domain als Ausnahme in die config.php hinzugefügt, dass ich Zugriff über die Domain auf die NC habe.
Glücklich bin ich damit aber nicht…

Also heißt es weiter suchen, wo der Fehler liegt :thinking:

Aber die Domain über die die NC erreicht werden soll MUSS doch immer in der config.php aufgeführt sein. Und zwar so:
‚trusted_domains‘ =>
array (
0 => ‚nc.XXXXXX.YYYYYY.ZZ‘,
1 => ‚192.168.0.2‘,
),

Das vor nc und 192.168. muss jeweils ein Hochkomma sein, wird hier automatisch vom Editor geändert

Kann ich davon ausgehen, dass die XYZ nur als Platzhalter dienen?
Wenn ja wofür?

Ja! das ist ein Platzhalter.

ich kenne das auch nur so, wen eine domain oder ip nicht in der config eingetragen ist bekommt man immer die Meldung

„Zugriff über eine nicht vertrauenswürdige Domain“