Zu UFW: die Freigaben waren alle, wie von dir beschrieben, richtg gesetzt. Habe sie trotzdem erst einmal komplett deaktiviert - damit dies als Fehlerquelle ausgeschlossen werden kann.
Die Update-URL in der FB beinhaltet nur &ip6lanprefix= nach dem Key.
Von den zuerst von Benares aufgelösten Adressen ist die letzte die des Servers. Sie wird in der FB im Heimnetz als IPv6-GUA angezeigt. Auch der Server selbst gibt diese Adresse aus.
[2a00:6020:4900:2e00:6a1d:efff:fe5d:711c]
Wenn ich den Record mit dieser IP erstelle, wird er beim Start der FB in die zuletzt gezeigte, also die .. 48::3e ausgetauscht.
Aber was doch verrückt ist: ich kann die Serveradresse anpingen, SSH funktioniert (über die IPv4), aber der Server reagiert nicht, wenn ich die Adresse aufrufe.
Dann solltest du mal einen tcpump auf dem Ubuntu mitlaufen lassen, ob da überhaupt Datenpakete für die Nextcloud (also TCP 80 / 443) ankommen…
Geht SSH auch über die IPv6?
Nein, geht nicht. Habe die LLA, die GUA und den Domainnamen probiert - mit -6 und mit Klammern. Keine Übereinstimmung gefunden und der Domainname kann nicht aufgelöst werden.
Was ist denn nun der Name/die IPv6 des letztendlich zu erreichenden Hosts? 
Wie ich schon geschrieben habe:
[2a00:6020:494e:ce00:6a1d:efff:fe5d:711c]
Erstmal ein -n mit rein und hast du während der lief den Zugriff versucht? Weil hier sehe ich nur SSH-Traffic
Dann stimmt intern schon irgendwas nicht. kannst du denn den Host per IPv6 pingen intern?
Und du hast auch, wie von mir gestern Nachmittag vorgeschlagen, einen Blick in die /etc/default/ufw geworfen, denn dort sollte IPV6=yes stehen?
Warum sehen wir hier nur die Hälfte? Warum machst du nicht das was ich dir in dem Zusammenhang sagte? Ausgabe als Vorformatierter Text !!! Ich wies ausdrücklich darauf hin, dass andernfalls Informationen fehlen werden. Was zur Hölle ist o schwer daran den texteditor hier vollumfänglich zu Nutzen und eben auch die Funktion Vorformatierter Text?
Die Ausgaben von tcpdump, um die @m-electronics dich bat gehören auch in den Vorformatierter Text und nicht als Bildchen (gif, jpg, png, etc.) hier hochgeladen. Bilddateien kann man nicht nach Schlüsselbegriffen durchsuchen !!!
Was genau willst du damit sagen? ping -6 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c (die IPv6 des Ubuntu-Servers) geht, aber kein ssh username@2a00:6020:4900:2e00:6a1d:efff:fe5d:711c?
Weil ich mich gefragt habe, wie du bei CGNAT aber ohne funkrionierendes http per IPv6 (du hast ganz sicher CGNAT, denn du hast eine IPv4-Adress aus dem für CGNAT reservierten Bereich (100.64.0.0./10) deine Let’s Encrypt zertifikate erstellen konntest, hab ich nochmals die Anleitung vom C.Rieger, der du gefolgt sein willst durchsucht. Der Rieger verweist in der Anleitung für die Nextcloud auf Let’s Encrypt Zertifikate (RSA 4096 oder EC 384) ohne offene TCP-Ports 80 und 443 beantragen und erstellen zur Installation von Let’s Encrypt Zertifikaten.
Jetzt stell ich mir natürlich die Frage, warum ohne offene TCP-Ports 80 und 443? Ich habe jetzt weder die Zeit noch die Lust mir die ganze Rieger-Anleitung durchzulesen, aber Rieger hat ja dafür einen Grund, warum die Zertifikate ohne offene TCP-Ports erstellt werden müssen.
Offenbar sieht Rieger’s Anleitung keine offenen TCP-Ports 80 und 443 vor und womöglich hängen damit auch deine gegenwärtigen Probleme zusammen. Relevant könnte da u.a. das Kapitel:
6. Systemhärtung (crowdsec IPS und ufw)
sein. Ich lese mir das aber nicht durch. Das ist dein Job, bzw. du solltest eh wissen, was da gemacht wurde und was das bewirken soll. Denn wenn man einer Anleitung von Dritten folgt, dann sollte man verstanden haben, was da warum gemacht wird und was die Folgen davon sind.
Mach mal folgendes (als root) per ssh (IPv4) auf deinem Ubuntu-Server:
tcpdump -nn -i enp1s0 ip6 and tcp port 22 (wobei du enp1s0 natürlich passend zu deiner Config anpassen musst)
Dann öffnen einen weiteren Terminal (Eingabeaufforderung wenn du Windows nutzt) und versuche eine SSH-Verbindung per IPv6 zum Ubuntu Server aufzubauen. Selbst wenn die ufw das nicht erlaubt sollten es da in der Ausgabe des Terminals mit dem tcpdump etwas passieren.
Auf meinem NC-Server erlaubt ufw kein ssh per ipv6 und per ipv4 nur aus dem LAN oder per Wireguard. Dennoch kommen da Pakete per ipv6 an. Siehe:
root@DebianServerVM2:~# tcpdump -nn -i enp1s0 ip6 and tcp port 22
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:02:42.212641 IP6 2001:aaaa:bbbb:cccc:1111:2222:3333:8f1d.47198 > 2001:aaaa:bbbb:cccc:1111:2222:3333:aa56.22: Flags [S], seq 2131059048, win 64800, options [mss 1440,sackOK,TS val 635580073 ecr 0,nop,wscale 7], length 0
08:02:43.252674 IP6 2001:aaaa:bbbb:cccc:1111:2222:3333:8f1d.47198 > 2001:aaaa:bbbb:cccc:1111:2222:3333:aa56.22: Flags [S], seq 2131059048, win 64800, options [mss 1440,sackOK,TS val 635581113 ecr 0,nop,wscale 7], length 0
08:02:44.277549 IP6 2001:aaaa:bbbb:cccc:1111:2222:3333:8f1d.47198 > 2001:aaaa:bbbb:cccc:1111:2222:3333:aa56.22: Flags [S], seq 2131059048, win 64800, options [mss 1440,sackOK,TS val 635582138 ecr 0,nop,wscale 7], length 0
08:02:45.300438 IP6 2001:aaaa:bbbb:cccc:1111:2222:3333:8f1d.47198 > 2001:aaaa:bbbb:cccc:1111:2222:3333:aa56.22: Flags [S], seq 2131059048, win 64800, options [mss 1440,sackOK,TS val 635583161 ecr 0,nop,wscale 7], length 0
08:02:46.324876 IP6 2001:aaaa:bbbb:cccc:1111:2222:3333:8f1d.47198 > 2001:aaaa:bbbb:cccc:1111:2222:3333:aa56.22: Flags [S], seq 2131059048, win 64800, options [mss 1440,sackOK,TS val 635584185 ecr 0,nop,wscale 7], length 0
08:02:47.348305 IP6 2001:aaaa:bbbb:cccc:1111:2222:3333:8f1d.47198 > 2001:aaaa:bbbb:cccc:1111:2222:3333:aa56.22: Flags [S], seq 2131059048, win 64800, options [mss 1440,sackOK,TS val 635585209 ecr 0,nop,wscale 7], length 0
08:02:49.396491 IP6 2001:aaaa:bbbb:cccc:1111:2222:3333:8f1d.47198 > 2001:aaaa:bbbb:cccc:1111:2222:3333:aa56.22: Flags [S], seq 2131059048, win 64800, options [mss 1440,sackOK,TS val 635587257 ecr 0,nop,wscale 7], length 0
08:02:53.428541 IP6 2001:aaaa:bbbb:cccc:1111:2222:3333:8f1d.47198 > 2001:aaaa:bbbb:cccc:1111:2222:3333:aa56.22: Flags [S], seq 2131059048, win 64800, options [mss 1440,sackOK,TS val 635591289 ecr 0,nop,wscale 7], length 0
08:03:01.940124 IP6 2001:aaaa:bbbb:cccc:1111:2222:3333:8f1d.47198 > 2001:aaaa:bbbb:cccc:1111:2222:3333:aa56.22: Flags [S], seq 2131059048, win 64800, options [mss 1440,sackOK,TS val 635599801 ecr 0,nop,wscale 7], length 0
08:03:18.322621 IP6 2001:aaaa:bbbb:cccc:1111:2222:3333:8f1d.47198 > 2001:aaaa:bbbb:cccc:1111:2222:3333:aa56.22: Flags [S], seq 2131059048, win 64800, options [mss 1440,sackOK,TS val 635616185 ecr 0,nop,wscale 7], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
root@DebianServerVM2:~#
Das kannste natürlich auch für die Ports tcp 80 und 443 machen und mit der Eingrenzung auf ip6 wird die Ausgabe auf das hier Wesentliche, also IPv6-Datenverkehr begrenzt. Mit IPv4 scheinst du ja keine Probleme zu haben.
09:56:09.179503 IP6 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c.22 > 2a00:6020:4900:2e00:88a4:3d65:e1e9:f4a3.491
93: Flags [P.], seq 33196:33232, ack 30923, win 500, options [nop,nop,TS val 1863007610 ecr 2887363658], len
gth 36
09:56:09.180395 IP6 2a00:6020:4900:2e00:88a4:3d65:e1e9:f4a3.49193 > 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c.
22: Flags [.], ack 33232, win 2048, options [nop,nop,TS val 2887363659 ecr 1863007610], length 0
09:56:09.203475 IP6 2a00:6020:4900:2e00:88a4:3d65:e1e9:f4a3.49193 > 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c.
22: Flags [P.], seq 30923:30959, ack 33232, win 2048, options [nop,nop,TS val 2887363682 ecr 1863007610], le
ngth 36
09:56:09.203730 IP6 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c.22 > 2a00:6020:4900:2e00:88a4:3d65:e1e9:f4a3.491
93: Flags [P.], seq 33232:33268, ack 30959, win 500, options [nop,nop,TS val 1863007634 ecr 2887363682], len
gth 36
09:56:09.204617 IP6 2a00:6020:4900:2e00:88a4:3d65:e1e9:f4a3.49193 > 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c.
22: Flags [.], ack 33268, win 2048, options [nop,nop,TS val 2887363683 ecr 1863007634], length 0
09:56:09.226985 IP6 2a00:6020:4900:2e00:88a4:3d65:e1e9:f4a3.49193 > 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c.
22: Flags [P.], seq 30959:30995, ack 33268, win 2048, options [nop,nop,TS val 2887363706 ecr 1863007634], le
ngth 36
09:56:09.227239 IP6 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c.22 > 2a00:6020:4900:2e00:88a4:3d65:e1e9:f4a3.491
93: Flags [P.], seq 33268:33304, ack 30995, win 500, options [nop,nop,TS val 1863007658 ecr 2887363706], len
gth 36
09:56:09.228052 IP6 2a00:6020:4900:2e00:88a4:3d65:e1e9:f4a3.49193 > 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c.
22: Flags [.], ack 33304, win 2048, options [nop,nop,TS val 2887363707 ecr 1863007658], length 0
^C
2326 packets captured
2326 packets received by filter
0 packets dropped by kernel
Bin auf dem iPad (Terminal) mit ssh IPv4 auf den Server gegangen, habe den von dir angegeben Befehl ausgeführt (enp1s0 auch bei mir) und habe dann auf dem Mac (Terminal) mit ssh IPv6 ausgeführt. Der Zugang hat funktioniert. Das ist dabei rausgekommen (Ausschnitt als vorformatierter Text :-))
Also konntest du dich per terminal und ipv6 mit dem Ubuntu-Server verbinden oder was bedeutet der Zugang hat funktioniert?
Übrigens ändert ipv64.net den von mir erstellten Record 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c (die IPv6 des Ubuntu-Servers) immer wieder auf 2a00:6020:1000:48::3e.
Update-URL
https://ipv64.net/nic/update?key=xxxxxxxxxxxxFmkXc&ip6lanprefix=
Die Update-URL als Vorformatierter Text bitte !!!
Der Zugang hat funktioniert heißt, dass ich mich mit IPv6 mit dem Server verbinden konnte
ok
https://ipv64.net/nic/update?key=xxxxxxxxxxxxx&ip6lanprefix=<ip6lanprefix>