Hallo allen!
Ich versuche gerade, einen Spielserver auf einer ubuntu-Maschine (ubuntu 20.04) über meine Fritzbox (7520) vom Internet aus erreichbar zu machen.
Die Fritzbox ist gut mit dynv6 verbunden, und der IPv6 Präfix(die ersten 64bits) wird richtig aktualisiert. In der Fritzbox habe ich meine aktuellste Interface ID (die letzen 64bits) eingetragen, sodass, wenn ich die mysite.dynv6.net Adresse im Browser eingebe, der Server auf meiner Maschine antworten kann.
Das Problem stellt sich in dem Moment, wo der Internetanbieter den Präfix von der Fritzbox ändert( jeder 1-2 Tag), denn da wird meinem ubuntu-Server eine völlig neue IPv6 Adresse zugewiesen. Dynv6 kann weiterhin den Präfix erraten, kennt aber die interface ID nicht und die Verbindung gelingt nicht. Ich muss dann auf die fritzbox zugreifen, die neueste Interface-ID lesen und dementsprechend die Adresse änderne.
Kennt jemand einen Weg, wie man die letzen 64bit der IPv6 Adresse des Serves festlegen kann (von ubuntu oder von der Fritzbox aus), sodass sie immer wieder an die neuen Präfixe angeschlossen werden? Würde es etwa einen Unterschied machen, wenn ich den “Server” über Ethernet statt ober WiFiverbinden würde?
Folgende netplan Konfiguration habe ich ausprobiert:
Versuche mit Befehle wie
ip token set
sind fehlgeschlagen(Invalid Argument)
Hi,
ich habe vor Kurzem auch versucht einen RaspberryPi mit Ubuntu Server 20.04 und IPv6 aus dem Internet erreichbar zu machen. Hatte dann das gleiche Problem, dass sich der Client Identifier (=letzten 64 bit der IP-Adresse) des LAN-Interface des Pis regelmäßig geändert haben. Das Feature nennt sich IPv6 Privacy Extension und soll Tracking verhindern.
Ich habe es mithilfe dieses Artikels (Raspberry Pi VPN – Teil 5: Vorarbeiten für ein VPN unter IPv6 – Helmut Karger) hinbekommen, dass der Pi nur den Client-Identifier basierend auf der MAC-Adresse seines Netzwerk-Interfaces verwendet und keine zusätzlichen zufälligen generierten.
Dazu auf dem Pi:
sudo vi /etc/dhcpcd.conf
und die Option slaac private auskommentieren:
#slaac private
dann mit sudo shutdown -r now neustarten.
Das ipv6-address-token und dhcp6: false in netplan würde ich dann rausnehmen, weil der Identifier ja via SLAAC mithilfe der MAC-Adresse generiert werden soll. Meine netplan config musste dafür nicht vom Standard in Ubuntu Server abgeändert werden.
Danach kannnst du mit dem Befehl ip address prüfen, ob die letzten 64-bit der globalen IPv6-Adresse des Servers eine starke Ähnlichkeit mit der MAC-Adresse des zugehörigen Netzwerk-Interface haben und es nur eine globale IPv6-Adresse gibt. Falls ja, sollte es funktioniert haben.
Danke für die Antwort!
Die Datei, aud die du verweist, ist auf meinem Rechner nicht vorhanden, und die Option slaac private ist auch nirgends benutzt (habe ich im /etc Ordner mit grep gesucht). Kommt diese config mit ifupdown? Sollte ich dann ifupdown installieren?
Ich hatte tatsächlich mit der netplanm-Option versucht
ipv6-address-generation: eui64
Was genau das machen sollte, was du meinst, aber ohne Erfolg.
Verstehe, dhcpcd kam bei mir im Rahmen der pihole Installation mit dazu. Für dein Setup ist es dann vermutlich besser es mit den bereits vorhandenen Mitteln (netplan und NetworkManager(?)) zu versuchen, wie du es bereits gemacht hast.
Du nutzt vermutlich netplan und den NetworkManager? Hast du wie hier (Netplan › Wiki › ubuntuusers.de) beschrieben nach deiner Konfigurationsänderung netplan apply ausgeführt?
Ggf. überschreiben die Einstellungen des NetworkManager die netplan Konfigurationsdatei, wie hier erwähnt (Netplan › Wiki › ubuntuusers.de).
Du kannst mal mit nmcli connection show <NameDerWifiVerbidnung> die Eigenschaften der Verbindung anzeigen lassen. Interessant sind vermutlich die Parameter ipv6.ip6-privacy, ipv6.addr-gen-mode und ipv6.token. Wenn die Parameter nicht den Werten aus deiner netplan Konfiguration entsprechen, ist vermutlich das der Grund.
Nochmal danke für die Geduld und die Bereitschaft zum Helfen!
Zu deinem ersten Punkt: Ja, die Konfigurationsänderung habe ich auch mit netplan try bzw. netplan apply implementiert.
Ich schätze dass deine Vermutung, NetworkManager und netplan kommen sich irgendwie in die Quere, richtig ist. Das ist für mich ein bisschen verwirrend, denn netplan selbst NetworkManager als renderer aufruft; Ich habe ehrlich gesagt keine Ahnung wie es läuft.
Ich werde Deine Anweisungen ausprobieren, sobald ich wieder am Rechner sitzen kann 
Hatte ein ähnliches Problem mit FritzBox6490 Cable und Debian Host. Folgendes funktioniert bei mir.
Debian:
/etc/network/interfaces
…
auto enp8s0
allow-hotplug enp8s0
iface enp8s0 inet dhcp
dns-nameservers 192.168.1.254 8.8.8.8 8.8.4.4
iface enp8s0 inet6 dhcp
dns-nameservers 2001:4860:4860::8888 2001:4860:4860::8844
Fritzbox / Heimnetz / Netzwerk / Netzwerkeinstellungen / IPv6-Konfiguration
DHCPv6-Server in der FRITZ!Box für das Heimnetz aktivieren:
DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen
Die IPv6 Interface-ID wird aus der Mac-Adresse abgeleitet, kann aber überschrieben werden.
Die Adresse des Debian-Hosts wird aus dem aktuelle Prefix und dieser IPv6 Interface-ID gebildet.
Firewall für einen oder mehrere Ports öffnen:
Fritzbox / Internet / Freigaben / Portfreigabe
für obige IPv6 Interface-ID Portfreigabe(n) einrichten
Fritzbox / Internet / Freigaben / DynDNS / Update-Url
https://dynv6.com/api/update?hostname=yourname.dynv6.net&token=yourtoken&ipv6prefix=
Ganz wichtig: Im URL darf die IPv6-Adresse nicht gesetzt werden!!!
Die IPV6-Adresse ist hier die Adresse des Routers und nicht des Debian-Hosts. Sie hat i.d.R. einen abweichenden Prefix und dieser würde den Prefix des Subnetzes überschreiben.
In DynV6.net einen AAAA-Record anlegen.
type: AAAA, Name: leave empty Data: 2 Doppelpunkte gefolgt von der IPV6-Interface-ID (z.B. ::aabb:ccff:fedd:eeff)
Seltsames Verhalten meiner FritzBox:
Wenn kein DynDNS aktiviert ist, sind die IPv6-Freigaben auch nicht aktiv. Ursprünglich habe ich DynDNS mittels eines cron-Jobs aktualisiert ohne DynDNS in der Fritzbox. Ging nicht.
Danke an alle für die Antworten! Ich bin tatsächlich viel näher zu einer Lösung gekommen.
Der Hinweis, dass NetworkManager und netplan sich gegenseitig stören, ist richtig. Durch den Befehl nmcli connection wlp3s0 modify konnte ich diesen Fehler beheben, indem ich die Einstellungen von netplan und nmcli in Einklang gebracht habe.
Das Problem hat sich aber dann gezeigt, was heinz.burkert erwähnt hat: Nämlich, dass dynv6 sich die Adresse des Routers holt, statt die vom Host.
Ich habe dann die Update-URL
http://dynv6.com/api/update?hostname=<domain>&token=<username>&ipv4=<ipaddr> http://dynv6.com/api/update?hostname=<domain>&token=<username>&ipv6=<ip6addr>&ipv6prefix=<ip6lanprefix>
durch
http://dynv6.com/api/update?hostname=<domain>&token=<username>&ipv4=<ipaddr> http://dynv6.com/api/update?hostname=<domain>&token=<username>&ipv6prefix=<ip6lanprefix>
ersetzt, wobei bei der neuen URL die Query für die Adresse entfernt worden ist. Ich warte jetzt zu sehen, ob das denn richtig funktioniert!
Heinz, war das was du meintest mit deinem Hinweis?
Hey, freut mich, dass du weiter gekommen bist
Mit welchem Geräte rufst du den die dynv6.com Update-URLs auf? Wenn du es mit der Fritz!Box machst, dann wird auch die Fritz!Box-Adresse aktualisiert.
Ich habe den ddclient (DDNS-Clients › Wiki › ubuntuusers.de) auf meinem Pi installiert, der aktualisiert momentan die gesamte IPv6-Adresse des Pi zuverlässig, jedoch leider nicht das IPv6-Prefix, hat aber bisher nicht zu Problemen geführt. Die öffentliche IPv4-Adresse der Fritz!Box wird bei mir von der Fritz!Box mithilfe der Update-URL aktualisiert.
Die config des ddlients (etc/ddclient.conf) sieht bei mir folgendermaßen aus:
ssl=yes
protocol=dyndns2
usev6=if, if=<networkInterface>
server=dynv6.com
login=none
password='<token>'
<hostname>.<myzone>.dynv6.net
ssl=yes war bei mir zwingend notwendig
<networkInterface> müsstest du durch das verwendete Interface ersetzen, bei dir offensichtich wlp3s0
<token> ist die Zeichenfolge, die bei Dynv6.com unter “Instructions” als “Benutzername” angezeigt wird
<hostname>.<myzone>.dynv6.net ist der Hostname, der dann auf die IPv6-Adresse meines Pis aufgelöst wird und als AAAA-Record unter Dynv6.com unter “Record” eingesehen werden kann.
Wenn der Ansatz von heinz.burkert bei dir auch funktioniert, umso besser, dann sparst du dir die ddclient Installation und Konfiguration.