Mit SLAAC könnte das auch schwierig werden, wegen der IPv6 Privacy Extensions
Zitat:
Privacy Extensions in Servern und Routern
Privacy Extensions haben sich als Standardeinstellung bei allen Betriebssystemen etabliert. Aber, es gibt Situationen, in denen sie besser abgeschaltet werden. Denn die Adressverschleierung erschwert das System- und Netzmanagement. Beispielsweise bei zentralen Servern und Routern. Hier sind wechselnde IPv6-Adressen nicht gewünscht.
Warum sagst du das immer? Meines Erachtens ist die Privacy Extension doch nur eine zusätzliche IPv6, mit der ein Host nach außen geht, um seine MAC zu verschleiern.
Eingehend muss man natürlich die “richtige” IPv6 verwenden, GUA heißt die meines Wissens, beginnt meist mit 2001:: und hat ein ff:fe im Interface-Identifier drinnen.
Ich bin jetzt auch nicht soooo der IPv6-Spezialist, aber das ist mein zugegeben rudimentärer Wissenstand.
Ich sage das immer, weil zumindest bei Fritten freigaben nicht klappen, wenn SLAAC und IPv6 Privacy Extensions im Spiel sind.
Und wie du siehst sage ja nicht nur ich das, sondern auch das Elektronik-Kompendium. Im übrigen macht es wenig Sinn, die Privacy Extensions für einen Server zu nutzen, der über dessen FQDN sowieso eindeutig jederzeit wiedererkennbar ist.
In der ursprünglichen Fassung von SLAAC erzeugt der IPv6-Host seine IPv6-Adresse aus einem Präfix und seinem eigenen Interface Identifier, der seine MAC-Adresse (Hardware-Adresse des Netzwerkadapters) enthält. In der Mitte der Hardware-Adresse werden zwei feste Bytes bzw. 16 Bit (ff:fe) eingefügt. Das siebte Bit im ersten Byte der MAC-Adresse wird umgekehrt.
00:0C:F1:8E:C1:D8 (MAC-Adresse, 48 Bit)
020c:f1ff:fe8e:c1d8 (Interface Identifier der IPv6-Adresse, 64 Bit)
Zum Vergleich nun ein Linux Notebook mit IPv6 Privacy Extensions und per SLAAC ausgehandelten IPv6-Adressen
Fallen dir die Übereinstimmungen, bzw. Nichtübereinstimmungen auf? Mit IPv6 Privacy Extensions hat die MAC-Adressen keinen Bezug zum Interface Identifier der vergebenen IPv6-Adressen.
Und zum Vergleich nun ein Server mit per DHCPv6 zugewiesenerIPv6-Adresse ohne Privacy Extensions:
inet6 fe80::1111:ff:fe22:aa56 prefixlen 64 scopeid 0x20
inet6 2001:XXX:YYYY:ZZZZ:1111:ff:fe22:aa56 prefixlen 128 scopeid 0x0
ether XX:XX:XX:XX:aa:56 txqueuelen 1000 (Ethernet)
Danke für deine Infos. Mich wundert halt nur, dass alle meiner Geräte auch eine IPv6-ULA haben, egal ob SLAAC oder DHCPv6. Aber egal, Hauptsache es funktioniert alles.
Könnte es sein, dass du ULA und LLA verwechselst bzw gleichsetzt?
die LLA hat immer den Präfix fe80 und entspricht bei v4 dem Adressbereich 169.254.0.0/16
die ULA befinden sich im Adressbereich fc00… bis fdff… und entspricht den privaten Adressen von IPv4 (10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16). Mit diesen ULA hat man dann allerdings auch die selben Probleme wie bei IPv4. Um mit diesen Adressen global kommunizieren zu können benötigt man NAT66
deswegen nimmt man bei v6 eben die Global Unique Addresses (GUA). Dafür gibt es die beiden Verfahren Stateless Address Autoconfiguration (SLAAC) und Stateful Address Autoconfiguration (DHCPv6).
Hi The_eagle,
mit den Begrifflichkeiten bin ich noch nicht ganz so fit. Meine Fritte zeigt mir die “richtige” IPv6 als IPv6-GUA an (s. Beispiel).
Und wenn ich die bei ipv64.net benutze, klappt es auch
Deine Config sieht gut aus. Die GUA passt zur MAC-Adresse und ist die, die für v6-Freigaben verwendet wird. Bei dir sind in der Fritte vermutlich aber auch (IA_PD) und (IA_NA) aktiviert.
Überdenke den Netzwerk-Design grundlegend. Android-Geräte haben nichts in dem Segment eines LAN’s zu suchen, in dem du einen Server betreibst, der aus dem Internet erreichbar sein soll.
Gut, bei Fritten geht das nicht anders, aber du hast eine (Alb)Traummaschine, die sich in einem Preisrahmen bewegt, in dem sich auch eine pfsense bewegt. Da sollte es mehr geben als nur WAN und LAN.
Bei mir (pfsense) wird das streng getrennt:
WAN
LAN
WiFi
IoT (z.B. Steuereung der Heizung)
DMZ (Server, wie meine Nextcloud)
Logisch, dass da die Androiden im WiFi-Segment sind (SLAAC), während die Server im DMZ-Segment per DHCPv6 die IP-Adrerssen bekommen.
Weiterer Vorteil:
die Rules der Firewall sind für alle Segmente separat definierbar.
Mir geht es gerade darum, dass ich die Dream Machine nicht über IPv6 erreichen kann. Ich sehe weder einen Logeintrag, dass da was auf der WAN Schnittstelle reingekommen ist, noch sehe ich eine Reaktion auf meinem Browser, dass der z.B. das Webinterface meiner DreamMachine anzeigt.
Die Zusammenhänge (SLAAC / IPv6 Privacy Extensions) habe ich bereits gestern ausreichend erklärt. Ziehe deine Schlussfolgerungen daraus.
Sieh dir deine Router Advertisements an. Neben
Unmanaged = SLAAC und
Managed = DCHPv6 gibt es auch
Assisted = DHCPv6 & SLAAC
Dann musst du nur noch dafür sorgen, dass deine Synology auch DHCPv6 nutzt und den Interface Identifier per DHCPv6 bezieht. Dann bleibt der basieren auf der MAC-Adresse immer gleich und die Weiterleitung klappt.
Dann musst du nur noch dafür sorgen, dass deine Synology auch DHCPv6 nutzt und den Interface Identifier per DHCPv6 bezieht.
Habe ich gemacht (siehe Bild). Aber irgendwie weicht die Adresse von dem meiner DreamMachine ab (siehe Bild 2). Ich würde da jetzt erwarten, dass der Network-Identifier gleich ist.
Wenn ich nun hergehe, und die IPv6 Adresse in meinen Browser eintippe, dann bekomme ich keine Rückmeldung. Weder von der DreamMachine, noch von dem Synology.
Und ist das eigentliche, warum ich diesen Thread aufgemacht habe.
Das Problem habe ich aber gerade gelöst. Der hatte noch eine IPv6 Adresse von der Fritzbox gespeichert. Die Fritzbox habe ich aber gerade deaktiviert. Jetzt passt die IPv6 Adresse auch.
Aha. Also Automatisch im Network Manager (Linux) bedeutet es wird SLAAC mit Privay Extensions verwendet. Deswegen gibt es neben Automatisch auch noch Automatisch, nur DHCP dann wird DHCPv6 verwendet und keine Privay Extensions. Prüfe das, sonst könnte das Problem wieder auftauchen sobald die Privay Extensions eine neue IPv6-Adresse auswürfeln.
