Unter den Erklärung zu den Domain Einstellungen bei IPv64 findest du zu den AAA-Records folgende Erläuterungen:
Ein AAAA-Record zeigt auf die IPv6-Adresse des Ziels.
Format: „Target-IP“ (ex. 2a01::5654:a422:12::2431)
Format: „Interface-ID“ (ex. ::6743:12::f9aa::44a1)
Format: „EUI-64 MAC“ (ex. 3C:49:37:12:26:B3)
Für das was du erreichen willst (den Ubuntu-Server per IPv64-DynDNS erreichbar zu machen, über ein Update des IPv6-Prefixes mit der Fritte kannst du nur eine der beiden letzten von mir gel markierten Optionen nehmen. Das machst du aktuell nicht.
Ändere die Verwendete Update-URL in:
https://ipv64.net/nic/update?key=1234567890abcdefgh&ip6lanprefix=<ip6lanprefix>
Das aktualisiert dann nur den Ipv6-Präfix und verwende entweder die Interface-ID oder die EUI-64 MAC bei ipv64 für urausch.ipv64.de
Auch das ist mir klar. Aber ist die Überlegung denn falsch, dass ich mit der „richtigen“ Server-IP über den Browser (bei mir Safari, also Apple) auf den Server gelangen kann? Vor allem im Heimnetz?
Da könnte auch noch die Firewall dicht sein auf dem Ubuntu-Server
Zum Heimnetz steht doch oben schon was du dafür machen musst: Ausnahmeregel erstellen für den DNS-Rebind-Schutz der Fritte. Haste das gemacht?
Greifen diese Regeln auch, wenn man versucht über die reine IPv6-Addresse zuzugreifen? 
Oder nur wenn man es über DNS versucht?
Ich setze mich heute Nachmittag noch mal dran.
Nein, dann nicht. Aber da gibt es vor den Regeln in der ufw noch andere Fallstricke.
- der TS (@urausch) maskiert die IPv6-Adresse nicht oder nicht korrekt
- selbst wenn korrekt maskiert kommt man nicht einfach so auf den Server, wegen fehlender Ipv6-Adresse in der Config des Servers. Die Ipv6-Adresse kann da aber wegen des regelmäßig wechselnden Ipv6-Präfix nicht drin stehen. denn die Adresse ist ja nie fix.
Damit meine ich vor allem mal die trusted_domains in der config.php (hier gehts ja um neinen Server mit Nextcloud und ich vermute der TS will die Nextcloud über https erreichen)
Welche v6-Addresse? Was meinst du mit maskieren?
Inzwischen wurde die Serverdestination wieder ohne mein zutun auf die von der DG erhaltenen IPV6-Adresse geändert.
Damit komme ich im Heimnetz auf die Fritzbox, von außen keine Reaktion.
UFW ist in der Ubuntu-Instanz vorübergehend ausgeschaltet und in der trusted domain der config.php ist meine ipv64-Domain eingetragen - wie auch in allen anderen relevanten Dateien (hosts usw.)
Die Ausnahmen sind im DNS-Rebind-Schutz hinterlegt (wie in meiner Nachricht oben genannt)
Weil du nicht, wie von mir vorgeschlagen, entweder die Interface-ID oder die EUI-64 MAC bei ipv64 verwendest. Du hattest doch schon einmal einen Eintrag unter Verwendung von entweder Interface-ID oder EUI-64 MAC gestern Abend hier gezeigt (der wo die ersten 64 Bit der IPv6-Adresse in Klammern und Fettdruck dargestellt wird). Jedenfalls macht so ein Eintrag nur mit Interface-ID oder EUI-64 MAC Sinn. Da hasst du also den falschen Eintrag gelöscht.
Hier noch eine Anleitung für unerfahrene:
Die MAC-Adresse des Ubuntu Servers findest du im Terminal des Server per
ip a heraus und steht in der Ausgabe dann direkt neben
link/ether des LAN-Interfaces des Servers.
Zudem musst du die von mir oben bereits gezeigte Update URL:
https://ipv64.net/nic/update?key=1234567890abcdefgh&ip6lanprefix=<ip6lanprefix>
in der Fritte verwenden. Dann wird nur der Prefix aktualisiert, keine IP-Adressen
https://2001:9e8:aaaa:bbbb:cccc:ff:fe98:dddd = falsch
https://[2001:9e8:aaaa:bbbb:cccc:ff:fe98:dddd] = richtig
Als nur Linux-User nenne ich das maskieren, wie man ja auch z.B. Dateinamen mit Leerzeichen in der Konsole maskieren muss. Etwa
cp ~/Dokumente/Text Datei.txt ~/Downloads
nicht klappen würde, da nicht maskiert. Richtig wäre
cp ~/Dokumente/Text\ Datei.txt ~/Downloads oder
cp ~/Dokumente/"Text Datei.txt" ~/Downloads.
Bei Ubuntu ist die ufw per default nur installiert aber nicht aktiviert. Ich gehe daher davon aus, dass Personen, die die ufw aktivieren, sich im Vorfeld mit der richtigen Konfiguration der ufw befasst haben sollten, denn ansonsten kann es ganz leicht passieren, das man selbst per ssh nicht mehr auf den Ubuntu-Server kommt und sich selbst ausgesperrt hat.
Ganz blöd, wenn es dann auch noch ein Headless-Server ist, und man auch keine Virtuelle Konsole mehr hat …
Hab mir angesehen, was C.Rieger zur ufw vorschlägt. Das ist:
ufw allow 80/tcp comment "LetsEncrypt (http)"
ufw allow 443/tcp comment "LetsEncrypt (https)"
ufw allow 22/tcp comment "SSH"
Damit sollten (wenn du das so unverändert übernommen hast) sämtlicher eingehender Datenverkehr für IPv4 und IPv6 per tcp 80, 443 und 22 erlaubt sein.
Wirf aber auch noch einen Blick in die /etc/default/ufw dort sollte IPV6=yes stehen. Sollte dort aber IPV6=no stehen, blockt die ufw allen IPv6-Traffic.
Bin grad etwas verwirrt. Momentan wird folgendes aufgelöst:
C:\>nslookup urausch.ipv64.de
Server: fritz.box
Address: fd58:218f:caa5:0:e208:55ff:fe0e:169b
Name: urausch.ipv64.de
Address: 2a00:6020:1000:48::3e
C:\>nslookup irgendwas.urausch.ipv64.de
Server: fritz.box
Address: fd58:218f:caa5:0:e208:55ff:fe0e:169b
Name: irgendwas.urausch.ipv64.de
Address: 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c
Beide sind anpingbar. Was ist denn da nun was?
Wie hast du das denn hinbekommen?
root@DebianServerVM2:~# nslookup urausch.ipv64.de 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: urausch.ipv64.de
Address: 2a00:6020:1000:48::3e
root@DebianServerVM2:~# nslookup urausch.ipv64.de 9.9.9.9
Server: 9.9.9.9
Address: 9.9.9.9#53
Non-authoritative answer:
Name: urausch.ipv64.de
Address: 2a00:6020:1000:48::3e
root@DebianServerVM2:~#
Firefox sagt dazu dann:
Anscheinend gibt es ein Problem mit dieser Website
Firefox kann sich nicht mit dem Server auf [2a00:6020:1000:48::3e] verbinden
Die IP [2a00:6020:1000:48::3e] gehört der Fritte und die sollte bei Zugriff von Außen genau das auch tun, nämlich einfach nicht verbinden.
Für mich bedeutet das einfach:
@urausch benutzt weiterhin eine Update URL die nicht nur den IPv6-Präfix aktualisiert und daher immer noch die IPv6-Adresse der Fritte an die DynDNS-Adresse ausliefert.
Nachtrag: nur für @Benares
Kann es sein, dass du die DNS-Server von ipv64 verwendest? Normal ist das nicht, das DNS-Server ULA’s ausliefern, denn die sollten nur die GUA ausliefern.
Wirst du auch hinbekommen 
Ich frag mich halt nur, wohin diese Wildcard-Namenauflösung führt.
Edit: Dich verwirrt wohl, dass ich meine Fritte befrage
Server: fritz.box
Address: fd58:218f:caa5:0:e208:55ff:fe0e:169b
und keinen externen DNS-Server. aber das Ergebnis ist gleich.
Mit richtigen DNS-Servern schaff ich das nicht, dass mir da eine ULA ausgeliefert wird. Siehe:
root@DebianServerVM2:~# nslookup irgendwas.urausch.ipv64.de 9.9.9.9
Server: 9.9.9.9
Address: 9.9.9.9#53
Non-authoritative answer:
Name: irgendwas.urausch.ipv64.de
Address: 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c
root@DebianServerVM2:~# nslookup irgendwas.urausch.ipv64.de 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: irgendwas.urausch.ipv64.de
Address: 2a00:6020:4900:2e00:6a1d:efff:fe5d:711c
root@DebianServerVM2:~#
Auch nicht mit Wildcard-Namenauflösung
Ja, mich verwirrt immer alles mit den ULA’s. Liegt daran, dass die pfsense (und wohl auch die OPNsense) die gleichzeitige Nutzung von ULA und GUA im LAN gar nicht erst erlauben. Man muss sich (sinnvollerweise) für eins von beidem entscheiden.
Häh? Lies nochmal oben. Egal wen du befragst, urausch.ipv64.de und irgendwas.urausch.ipv64.de liefern unterschiedliche IPv6. Ich wollte nur wissen, welche die richtige, also die des eigentlichen Ziels, ist.
Siehe oben. Hab’s erklärt. tatsächlich mein Interpretations-Fehler.
Was die Frage angeht, welches die richtige und welche die falsche IPv6 ist, keine Ahnung. Das kann doch nur @urausch nachsehen, per ip a oder ifconfig in der Konsole seines Ubuntu-Servers.
Im übrigen kann @urausch (wenn ihm das mit der Fritten URL, dem v6-Präfix und so zu kompliziert ist) auch einfach das APT Debian DDNS IPv64 Package (aus den Anleitungen) auf dem Ubuntu-Server einrichten und verwenden. Der Ubuntu-Server aktualisiert dann ganz sicher nur seine eigene IPv6-Adresse, sonst nix.
LINK: Debian „ipv64-ddns-update“ Package
1 „Gefällt mir“
