gestern war deine Aussage ja noch, dass auch ssh per IPv6 nicht gehen würde.
Dann nimm das Gerät mit dem du per IPv6 und ssh auf den Server kommst und rufe von dort aus nun https://[2a00:6020:4900:2e00:6a1d:efff:fe5d:711c] auf. Lass tcpdump dabei tcp 443 überwachen. also:
tcpdump -nn -i enp1s0 ip6 and tcp port 443 auf dem Tablet oder in einem zweiten Terminal auf dem angeknabberten Apfel Notebook laufen
Steht so drin in der Datei
Ja, jetzt, nachdem ssh per ipv6 doch geht, war das automatisch klar.
root@ncmini:/home/ur# tcpdump -nn -i enp1s0 ip6 and tcp port 443
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:40:02.325993 IP6 2a00:6020:4900:2e00:88a4:3d65:e1e9:f4a3.49989 > 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c.443: Flags [SEW], seq 428364914, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 3973397365 ecr 0,sackOK,eol], length 0
10:40:02.326048 IP6 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c.443 > 2a00:6020:4900:2e00:88a4:3d65:e1e9:f4a3.49989: Flags [R.], seq 0, ack 428364915, win 0, length 0
10:40:02.380488 IP6 2a00:6020:4900:2e00:88a4:3d65:e1e9:f4a3.49990 > 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c.443: Flags [SEW], seq 1973215909, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 2109894663 ecr 0,sackOK,eol], length 0
10:40:02.380534 IP6 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c.443 > 2a00:6020:4900:2e00:88a4:3d65:e1e9:f4a3.49990: Flags [R.], seq 0, ack 1973215910, win 0, length 0
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
root@ncmini:/home/ur#
Rückmeldung des Browsers: Kann keine Verbindung zum Server aufbauen
Der Browser läuft doch aber auf dem Client mit der IPv6-Adresse: 2a00:6020:4900:2e00:88a4:3d65:e1e9:f4a3?
Da wird ja etwas zurück geschickt von a00:6020:4900:2e00:6a1d:efff:fe5d:711c.443 Ubuntu-Server an den Client. Sieht also so aus als fände eine Kommunikation per IPv6 in beide Richtungen statt. Nur das was da kommuniziert wird ist nicht das was es sein sollte.
Klappt es mit der IPv4-Adresse des Ubuntu Servers über ipv4 (also z.B. https://192.168.178.100 (keine Ahnung welche interne IPv4 dein Server hat)?
Das habe ich gelesen. Das ist nun aber erst einmal vollkommen irrelevant, denn bevor dein Webserver nicht auf https über ipv6 erwartungsgemäß reagiert, ist das alles unwichtig, denn du kommst eh so lange nicht auf den Server per ipv6. Egal ob da deine Fritte etwas falsch macht oder nicht.
Der Client mit der IPv6-Adresse ist der Mac, mit dem ich über SSH IPv6 auf den Server gegangen bin.
Der Zugang über IPv4 führt auch zur Meldung: Kann keine Verbindung zum Server aufbauen
Aber dann ist doch bereits bei der Installation des Webserver (nginx) oder php etwas schief gegangen. Das hat alles dann weder mit deiner Fritte noch mit ipv64-DynDNS etwas zu tun.
Was geht denn überhaupt? Geht wenigstens http (also tcp 80) oder kommst du damit auch nicht auf deine NC?
Und warum bitte sagst du dass https gar nicht geht, weder per ipv4 noch per ipv6 nicht gleich ganz am Anfang? Da hätten wir uns doch glatt 2 Tage sinnloses suchen an der falschen Stelle ersparen können!
Sorry, dass das etwas untergegangen ist - aber inzwischen bin ich so weit, dass ich alles in die Ecke schmeißen will.
Ist schon klar, dass ich mit eurem Fachwissen und euren Erfahrungen nicht mithalten kann, sonst hätte ich ja keine Hilfe losgeschickt?!
Euer Einsatz wird von mir respektvoll anerkannt. Danke dafür!!
Nach dem Hinweis auf nginx habe ich den Webserver aus der Terminalinstanz noch einmal gestartet.
root@ncmini:/home/ur# systemctl restart nginx
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.
root@ncmini:/home/ur# systemctl status nginx.service
× nginx.service - nginx - high performance web server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Fri 2026-04-10 11:33:40 CEST; 8min ago
Docs: https://nginx.org/en/docs/
Process: 5852 ExecStart=/usr/sbin/nginx -c ${CONFFILE} (code=exited, status=1/FAILURE)
CPU: 6ms
Apr 10 11:33:40 ncmini systemd[1]: Starting nginx.service - nginx - high performance web server...
Apr 10 11:33:40 ncmini nginx[5852]: nginx: [emerg] cannot load certificate "/etc/letsencrypt/rsa-certs/fullcha>
Apr 10 11:33:40 ncmini systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Apr 10 11:33:40 ncmini systemd[1]: nginx.service: Failed with result 'exit-code'.
Apr 10 11:33:40 ncmini systemd[1]: Failed to start nginx.service - nginx - high performance web server.
lines 1-12/12 (END)
Ich denke jetzt, wenn der Mini-PC bzw. der Server aus dem Netz nicht gefunden wird, kann auch die Installation von NC nicht funktionieren. Wo jedoch der Fehler liegt, ist mir immer noch nicht klar. Und wenn ich den NC-Server platt mache und ihn noch einmal neu installiere werde ich die gleichen Probleme bekommen, weil der PC ja nicht erreichbar ist.
Die Situation macht mich recht unglücklich - hoffentlich kann ich heute Nacht gut schlafen 
Der Mini-PC / Server ist ja erreichbar, nur der Webserver funktioniert nicht.
Und in der Fehlermeldung steht auch ganz genau drin, warum. „Cannot load certificate…“
Also kann er eine Zertifikatsdatei nicht laden
Darum geht es auch nicht, aber einfach alles erzählen, wäre hilfreich
Dann muss man mal Pause machen
Als ich (das liegt, das muss ich zugeben, schon fast 15 Jahre zurück und war damals auf einem Raspberry Pi Model 2B) meine ersten Cloud (damals noch die OwnCloud) installiert habe, lief auch nicht beim ersten Versuch alles glatt. Den musste ich auch ein zweites Mal installieren, weil ich den Fehler einfach nicht lokalisieren konnte.
Will dir damit sagen: Rückschläge gehören nun einmal dazu und sind Teil des Erkenntnisgewinns.
Ich kenne jetzt die C.Rieger-Anleitung nicht im Detail. Eine gute Anleitung hat aber so etwas wie Meilensteine, Punkte, an den man nach einzelnen Schritten der Installation prüft ob bis dahin alles geklappt hat. Und vor allem sollte in einer guten Anleitung bereits vor dem Versuch z.B. Let’s Encrypt Zertifikate zu erstellen, überprüft werden, ob die Voraussetzungen dafür alle gegeben sind.
Meine persönliche Empfehlung ist daher eine neuen Versuch mit einer anderen Anleitung zu starten, die diese Voraussetzungen erfüllt. Aus meiner persönlichen Sicht ist so eine Anleitung die von Jan Rehr.
Die kommt auch mit IPv6 und CGNAT klar, auch wen Jan immer beharrlich Dual-Stack empfiehlt. Ein großer Vorteil in seiner Anleitung ist nämlich, dass dort mit FQDN gearbeiet wird, also mit einem Domain-Präfix. Dabei ist deine Nextcloud dann nicht direkt per Domain (bei dir: urausch.ipv64.de) erreichbar, sondern z.B. per nextcloud.urausch.ipv64.de oder nc.urausch.ipv64.de.
Das hat aus meiner Erfahrung heraus gleich mehrere Vorteile:
Aber mach dir vielleicht erst einmal ein schönes WE und geht dann nächste Woche mit neuer Kraft wieder ans Werk.
Oder halt die offizielle Anleitung von Nextcloud…
Ja, auch, wobei die aber statt auf nginx (wie Rehr und Rieger) auf den apache setzt. @urausch kennt nun bereits den nginx.
Seitdem mir „eingeredet“ wurde, dass NGINX ein Loadbalancer und kein Webserver sei, nutze ich auch nur noch den Apache (zumindest als Webserver). Der kann aber halt auch vieles komfortabler als der NGINX z.B. PHP
Du weißt ja wie das ist. Die einen sagen so, die anderen so. Ich persönlich bin an den nginx gewöhnt. Da kann ich mich schwer von trennen. Ist vermutlich nicht anders als beim Webbrowser. Die einen nutzen Chrome, andere Firefox und so bleibt man meist lieber beim gewohnten, weil man bei Problem eben weiß wo man gucken muss.
Ich hab den auch lange benutzt als Webserver, aber immer mehr betreibe ich in Docker-Containern. Da hat man die Wahl meist sowieso nicht. Aber als Reverse-Proxy macht NGINX echt einen super-job
Bei Nextcloud AIO und den Docker Containern müsste @urausch dann sehr früh daran denken IPv6 in den Containern zu aktivieren. Per default ist das wohl nicht so. Da kommunizieren die nur per v4 und das klappt dann wegen CGNAT bei @urausch nicht.
Eure aufmunternden Worte tuen richtig gut und machen mir Mut. Danke dafür und für euren Einsatz.
Am Wochenende werde ich viel zu lesen haben aufgrund eurer Vorschläge.
ICH WILL ES HINKRIEGEN MIT DEM NEXTCLOUDSERVER!!