staging.inyokaproject.org

IPv6/Privacy Extensions

Status: Gelöst | Ubuntu-Version: Nicht spezifiziert
Antworten |
Dieses Thema ist die Diskussion des Artikels IPv6/Privacy_Extensions.

mfm

(Themenstarter)
Avatar von mfm

Anmeldungsdatum:
11. August 2006

Beiträge: 3159

aldor schrieb:

Wenn ich bei mir die verschiedenen Verbindungseinstellung im Network Manager ansehe, ist im Reiter IPv6-Einstellungen tatsächlich IPv6 Erweiterungen zum Schutz der Privatsphäre auf Deaktiviert gesetzt – trotz net.ipv6.conf.default.use_tempaddr = 2 und net.ipv6.conf.all.use_tempaddr = 2 in /etc/sysctl.d/10-ipv6-privacy.conf.

Das hört sich nach einem Problem des Network Managers an: Ich konnte das korrekte Verhalten an zwei Geräten nachvollziehen. Die haben zwar eine feste IPv6-Adresse, kommunizieren jedoch mit ihrer Temporären nach draußen, wenn auch auf beiden Geräten der Network Manager die Privacy Extensions als deaktiviert anzeigt.

Der verlinkte Artikel beschreibt jedoch ein Ubuntu-Version vor 12.04. Seit Precise sind die Privacy Extension standardmässig aktiviert.

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 7816

NetworkManager beachtet nicht die per sysctl gesetzten Kernel-Variablen, sondern verwendet seine eigene Strategie zur Konfiguration der Adressen. Hinzu kommt noch, dass spätestens ab Ubuntu 16.04 mit NetworkManager Version 1.2.2 nicht mehr Privacy Extensions gemäß RFC4941, sondern Stable Privacy gemäß RFC7217 als Vorgabe wirkt. Wenn man nicht RFC7217, sondern RFC4941 benutzen will, muss man in der Konfigurationsdatei der Verbindung zwei Optionen setzen:

1
2
3
4
5
6
7
8
9
root@gnome25:~# cat /etc/NetworkManager/system-connections/NET1 
[connection]
id=NET1
…

[ipv6]
addr-gen-mode=eui64
ip6-privacy=2
…

Die erste Option addr-gen-mode=eui64 schaltet RFC7217 ab, die zweite ip6-privacy=2 RFC4941 ein.

In Ubuntu 16.04 wird übrigens kein permanentes stable_secret als Kernel-Variable gesetzt, somit werden trotz RFC7217 nach jedem Neustart neue, somit randomisierte Adressen erzeugt.

harteknut

Anmeldungsdatum:
9. Oktober 2007

Beiträge: Zähle...

Das beschriebene Beispiel ist m.E. nicht korrekt:

Der IP-Adresserstellungsmodus steht scheinbar auf EUI64, was sich an dem FFFE im MAC-Teil fe80::221:beff:feef:dead erkennen lässt.

Die mittlere Adresse (2001:db8:ff00:8cb0:221:beff:feef:dead) ist ohne "privacy" erzeugt worden (besteht aus Präfix + EUI64, vgl. linklocal-Adresse) und sollte im WAN gar nicht verwendet werden.

Für ausgehende Netzwerkanfragen (zum Beispiel Aufruf einer Webseite) kommt sollte automatische eine neue 2001:db8:ff00:8cb0:xxxx:xxxx:xxxx:xxxx""-Adresse erzeugt werden, oder nicht? Das lässt sich im Network-Manager unter "IPv6-Erweiterungen zum Schutz der Privatsphäre" einstellen. Bei mir ist das so, die "globale-EUI64-Adresse" taucht im WAN nicht auf.

mfm

(Themenstarter)
Avatar von mfm

Anmeldungsdatum:
11. August 2006

Beiträge: 3159

Hallo,

harteknut schrieb:

Das beschriebene Beispiel ist m.E. nicht korrekt:

Passt das als Beispiel besser? die fd-Adressen habe ich mal weggelassen.

1
2
3
4
5
6
7
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2003:1ee7:fabi:ff00:75b6:9c5b:1360:cc87/64 scope global temporary dynamic 
       valid_lft 7066sec preferred_lft 1359sec
    inet6 2003:1ee7:fabi:ff00:d46c:fb54:6d2b:c95e/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 7066sec preferred_lft 1359sec
    inet6 fe80::221:dde7:5104:db8a/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

harteknut

Anmeldungsdatum:
9. Oktober 2007

Beiträge: 213

Das Beispiel war nicht verkehrt, nur die "scope global dynamic mngtmpaddr noprefixroute" wird m.E. vom Webbrowser nicht verwendet (oder sollte nicht verwendet werden), denn diese Adresse ist ja "statisch", solange das Präfix sich nicht ändert.

Lt. man-Page wird die mit mngtmpaddr noprefixroute geflaggte Adresse nicht geroutet und ist die Basis, um die temporäre Adresse zu generieren:

mngtmpaddr
              (IPv6 only) make the kernel manage temporary addresses created from this one as template on behalf of
              Privacy Extensions (RFC3041). For this to become active, the use_tempaddr sysctl setting has to be set
              to a value greater than zero.  The given address needs to have a prefix length of 64. This flag allows
              to use privacy extensions in a manually configured network, just like if stateless auto-configuration
              was active.

noprefixroute
              Do not automatically create a route for the network prefix of the added address, and don't search for
              one to delete when removing the address. Changing an address to add this flag will remove the automatiâ€
              cally added prefix route, changing it to remove this flag will create the prefix route automatically.

Ich verstehe das so:

  • Die linklocal-Adresse (FE80) kann sich der Client alleine erzeugen. Entweder auf Basis EUI64 (im Wesentlichen MAC-Adresse mit eingeschobenem FFFE) oder mit der Option "stabile Privatsphäre" bereits an dieser Stelle randomisiert. Die Adresse enthält als Präfix nur FE80 und hinten den 64-bittigen Interface Identifier.

  • Die erste globale Adresse wird per SLAAC erzeugt, sobald der Client ein Router Advertisement mit dem entsprechenden Präfix empfangen hat. Der Interface Identifier ist identisch zur linclocal-Adresse. Diese Adresse ist theoretisch dynamisch, da sich das Präfix ändern kann.

  • Bei aktivierten Privacy-Extensions erhält diese Adresse die flags mngtmpaddr und noprefixroute, außerdem wird aus dieser Adresse eine weitere globale Adresse generiert, die nur temporär verwendet wird. Dabei wird nur der Interface Identifier randomisiert. Während der Gültigkeit der Adresse wird diese temporäre Adresse verwendet und von jedem Dienst, der geroutet werden möchte zugewiesen. Nach Ablauf der Gültigkeit bleibt die Adresse so lange bestehen, wie Dienste aktiv sind. Neue Dienste erhalten aber eine neue Adresse mit einem weiteren randomisierten Interface Identifier.

Heißt:

Bei aktiven Privacy Extensions hat jedes Netzwerkinterface immer mindestens drei IPv6-Adressen. Nur eine davon wird vom Router (ohne NAT) nach draußen geschickt. Im eigenen Netzwerksegment können die FE80-Adressen verwendet werden.

In Deinem neuen Beispiel hast Du EUI64 abgeschaltet (kein FFFE mehr im Interface-Identifier). Nach außen ist nur die 2003:1ee7:fabi:ff00:75b6:9c5b:1360:cc87 zu sehen.

Ach so: Die ULAs (FD00) haben wir noch gar nicht besprochen, sind aber in der Regel (zumindest für mittelgroße Heimnetze) aus meiner Sicht kaum von Relevanz. Ich hatte die bei meinem Einstieg zunächst aktiv, komme aber komplett ohne aus.

DJKUhpisse Team-Icon

Supporter, Wikiteam
Avatar von DJKUhpisse

Anmeldungsdatum:
18. Oktober 2016

Beiträge: 16818

Hier muss unterschieden werden zwischen aktivem und nicht aktivem NetworkManager.

Der kann das nämlich auch kontrollieren.

Meine Erfahrung hier:

Privacy Extensions und stabile Privatsphäre sind im NM standardmäßig aktiv.

Im Router-Advertisement (RA) können ein oder mehrere Präfix samt Flags übertragen werden. Eines dieser Flags ist das Auto-Flag. Nur wenn das gesetzt ist, darf der Rechner sich eine Adresse generieren (Modus egal).

Er wird daher für jedes Präfix (egal ob GUA oder ULA) eine Adresse mit zufällig generiertem, aber festen Identifier (stabile Privatsphäre) generiert und eine mit wechselnden Identifier, die bevorzugt verwendet wird.

Die link-local-Adresse hat damit nichts zu tun, da wird nie eine wechselnde Adresse genutzt, sondern immer modified EUI64 oder stabile Privatsphäre. Ergo gibt es davon auch immer nur eine, völlig unabhängig vom RA.

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 7816

DJKUhpisse schrieb:

Hier muss unterschieden werden zwischen aktivem und nicht aktivem NetworkManager.

Im Grunde: Nein. Das Verhalten der IPv6-Adressen selbst ist unabhängig vom Programm, welches diese konfiguriert.

Man muss nur wissen, was bereits im Artikel steht:

Wichtig: Diese Einstellungen werden von NetworkManager überschrieben, wenn für die IPv6-Konfiguration der Verbindung etwas anderes als "Ignorieren" ausgewählt ist.

Das sollte allerdings deutlicher als Hinweis oder sogar Warnung formatiert werden und auch umfangreicher erläutert werden:

D.h. im Klartext: NetworkManager kümmert sich (hier wie auch an anderen Stellen!) nicht unbedingt um das, was man für den Linux-Kernel über die Kernelvariablen net.ipv6.conf.* vorgegeben hat, sondern macht sein eigenes Ding, indem er seine eigene Konfiguration beachtet und ggf. selbst die Kernelvariablen überschreibt.

Bei Benutzung des NetworkManagers (d.h. beim Desktop) muss man daher das gewünschte Verhalten bei der Adresskonfiguration in die Konfiguration des NetworkManagers schreiben und die Kernelvariablen belässt man am besten auf den Standardwerten.

Bei Verwendung von systemd-networkd (d.h. beim Server) werden dagegen die Kernelvariablen beachtet. Ich bin mir aber nicht sicher, ob es nicht doch gelegentlich davon Abweichungen gibt.

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 7816

Die Aussage im Artikel

Ist der NetworkManager für die Verbindung aktiv, sind die Privacy Extensions standardmäßig aktiviert und über diesen zu konfigurieren.

ist wohl bei aktuellen Ubuntu-Systemen so nicht mehr richtig.

Nach meinen Beobachtungen gilt:

  1. Beim Start werden über die Kernelvariablen die Privacy Extensions aktiviert (net.ipv6.conf.{all,default}.use_tempaddr = 2).

  2. Der NetworkManager schaltet aber spezifisch für die von ihm betreuten Schnittstellen das wieder aus:

    $ sysctl -ar net.ipv6.conf.*tempaddr
    net.ipv6.conf.all.use_tempaddr = 2
    net.ipv6.conf.cable.use_tempaddr = 0
    net.ipv6.conf.default.use_tempaddr = 2
    net.ipv6.conf.lo.use_tempaddr = -1
    net.ipv6.conf.radio.use_tempaddr = 0

    und scheint ein anderes Verfahren (Nachfolger zu RFC4941 ?) zu verwenden.

DJKUhpisse Team-Icon

Supporter, Wikiteam
Avatar von DJKUhpisse

Anmeldungsdatum:
18. Oktober 2016

Beiträge: 16818

Bei einem Xubuntu 23.04 sind die aktiv in den Kernelvariablen. Hast du ggf. ein Serversystem getestet?

Antworten |