Ansammlung von IPv6 Adressen per Interface pro Client

[Azaxs]

Hallo, ich habe einen dynamischen Internetzugang und das Problem das all meine Clients pro Interface täglich eine neue Öffentliche IPv6 Adresse zugewiesen bekommen und diese sich somit ansammeln & der v6 Verkehr dann nichtmehr funktioniert bis ich das Interface neu verbinde.

Code: Alles auswählen

 enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:60:6e:55:43:1e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.123/24 brd 192.168.1.255 scope global dynamic noprefixroute enp3s0
       valid_lft 7132sec preferred_lft 7132sec
    inet6 2a01:c22:d01c:ddff:b03e:6c5e:fbdb:8b05/64 scope global dynamic noprefixroute
       valid_lft 80596sec preferred_lft 8596sec
    inet6 2a01:c22:cc11:faff:19f7:491a:3afd:b87c/64 scope global dynamic noprefixroute
       valid_lft 86394sec preferred_lft 14394sec
    inet6 fe80::da29:9e9f:d9a3:e690/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Ich habe versucht per sysctl.conf mit der option: "net.ipv6.conf.default.max_addresses = 1" dies zu unterbinden aber das hat leider nichts bewirkt.

Weiß jemand wie ich diese ansammlung effektiv unterbinde bzw. das die Linux Clienten die alte v6 abwerfen?

Ich hatte auch schon soein Table hier:

Code: Alles auswählen

 inet6 2a01:c23:804f:adff:ee52:577a:6143:b208/64 scope global deprecated dynamic noprefixroute
       valid_lft 70922sec preferred_lft 0sec
 inet6 2a01:c22:d01c:ddff:1126:607a:596a:f105/64 scope global dynamic noprefixroute
       valid_lft 86400sec preferred_lft 14400sec

Wie zu sehen ist, ist die obere v6 Adresse veraltet, wurde aber nicht abgeworfen.

Vielen dank für eure Hilfe.
Grüße

[mat6937]

Weiß jemand wie ich diese ansammlung effektiv unterbinde bzw. das die Linux Clienten die alte v6 abwerfen?

Versuch mal ohne PEs (privacy extensions). Evtl. musst Du das Interface dann nicht mehr neu verbinden.

EDIT:

Sind deine Linux-Clients 24/7 online? Geht es um den eingehenden (d. h. zu den Clients) oder um den ausgehenden (d. h. von den Clients) v6-Verkehr (Traffic), der mit deinen Linux-Clients nicht mehr funktioniert?

Hast Du in deinem (W)LAN auch noch andere Clients (ohne Linux als OS), die auch IPv6 benutzen und dieses Problem nicht haben?

[TomL]

...und diese sich somit ansammeln & der v6 Verkehr dann nichtmehr funktioniert bis ich das Interface neu verbinde.

Das ist meines Erachtens eigentlich nicht möglich. Bei mir existieren die gleichen Rahmenbedigungen, ich habe ebenfalls täglich eine Zwangstrennung, ebenfalls mit dem Effekt, dass sich mein rund um die Uhr laufender Server einmal täglich 2 neue IPv6 generiert... eine MAC-Basierte und eine temp-Adresse... wobei die aktuelle temp-Adresse grundsätzlich für alle neue Verbindugnen die präferierte ist. Die vorherigen 2 Adressen, die anschließend als deprecated markiert sind, sollten jetzt eigentlich nur noch für alte aktiv verbundene Connects gültig bleiben, was ich mir aber eigentlich nicht vorstellen kann, wenn sich die Site-ID der IPv6 geändert hat. Bei mir sind die wohl tot.

Ich würde Dir folgende Maßnahmen empfehlen, um dem Problem auf die Schliche zu kommen:

1. Im Router eine konstante Uhrzeit vorgeben, wann die Zwangstrennung erfolgen soll. Bei mir passiert das vorhersagbar täglich um eine relativ gleiche Uhrzeit.... so das man einen zeitlichen Ansatzpunkt für zeitnahe Beobachtungen hat.
2. Im Rechner die "Privacy Extensions" aktivieren ... denn so wie es ausschaut ist das bei Dir nicht der Fall. Bei mir sind diese Adressen jedenfalls tatsächlich als "global temporary dynamic" markiert. Wenn es sich um einen im WWW surfenden Rechner handelt, würde ich das sogar dringend empfehlen.
3. Verfolgen, was nach dem Zeitpunkt der Zwangstrennung tatsächlich passiert. Ich würde mir also kurz vorher mit # ip a s dev enp3s0 den Zustand anschauen, dann nach der Trennung, und insbesondere dann auf die preferred und valid lifetime der alten Adressen achten. Wenn der Counter runter ist, sollten diese Adressen automatisch verschwinden.

Wie ist die Ausgabe von:

Code: Alles auswählen

sysctl -a | grep enp3s0 | grep "ipv6" | egrep "autoconf|accept_ra |use_tempaddr|forwarding"

BTW, was mir noch einfällt... gibt es eine persistente Verbindung irgendwohin, die sich an der alten IP über die Zwangstrennung hinaus festhält? In dem Fall würde ich diesen Service nach der Trennung einmal neu starten. Genau das mach ich beispielsweise bei meiner Firewall, die "stateful" die Site-ID beachtet... das ist zwar jetzt keine Verbindung, aber das/ein Problem hätte die gleiche Ursache.

[Azaxs]

Eines der Client Rechner ist ein Debian buster der 24/7 durchrennt & auf dem diverse Server instanzen laufen.

Wie, bzw Wo aktiviere ich denn die Privacy Extensions??
Ich habe im NetworkManager geschaut & dort kann man am Interface bei IPv6 die Privatsphäre Aktivieren das Öffentliche oder Temporäre Adressen bevorzugt werden. Per default ist dies auf Standart gesetzt.
Meint ihr das?

Der Output von:

Code: Alles auswählen

sysctl -a | grep enp3s0 | grep "ipv6" | egrep "autoconf|accept_ra |use_tempaddr|forwarding"
net.ipv6.conf.enp3s0.accept_ra = 1
net.ipv6.conf.enp3s0.autoconf = 1
net.ipv6.conf.enp3s0.forwarding = 0
net.ipv6.conf.enp3s0.mc_forwarding = 0
net.ipv6.conf.enp3s0.use_tempaddr = 0

Eine persitente IPv6 Verbindung die sich durchgehend an dieser festhält gibt es nicht.

[TomL]

Das sieht alles prinzipiell gut aus. Und solange Du forwarding nicht aktivierst, kann das so bleiben...

Wie, bzw Wo aktiviere ich denn die Privacy Extensions??

Code: Alles auswählen

sysctl -a | grep enp3s0 | grep "ipv6" | egrep "autoconf|accept_ra |use_tempaddr|forwarding"
net.ipv6.conf.enp3s0.use_tempaddr = 0

Code: Alles auswählen

# cat /etc/sysctl.d/sysctl_ipv6.conf
net.ipv6.conf.enp3s0.disable_ipv6=0
net.ipv6.conf.enp3s0.forwarding=0
net.ipv6.conf.enp3s0.autoconf=1
net.ipv6.conf.enp3s0.use_tempaddr=2
net.ipv6.conf.enp3s0.accept_ra=1

Solange hier "forwarding" deaktiviert bleibt, funktioniert diese Einstellung prima. Auf Systemen mit forwarding sieht das allerdings anders aus.

...und das Problem das all meine Clients pro Interface täglich eine neue Öffentliche IPv6 Adresse zugewiesen bekommen

Hier sind's gleich 2 Irrtümer. Erstens, das ist kein Problem, sondern völlig normales Verhalten. 2. Es wird keine neue IPv6 (von irgendwoher) zugewiesen, die Client-PCs generieren sich (anders als bei IPv4+DHCP) selber eine IPv6-Adresse, nachdem ihnen über das Router Advertisement eine Site-ID via Prefix-Delegation übermittelt wird. Das passiert ganz automatisch im Kernel des Clients via SLAAC ... also eine zustandslose automatische Adress-Generierung.

[mat6937]

Eines der Client Rechner ist ein Debian buster der 24/7 durchrennt & auf dem diverse Server instanzen laufen.

Was durchtrennt der Debian buster und ist es dieser Server, den Du nach der Zwangstrennung durch deinen Internet-Provider, aus dem Internet nicht mehr erreichen kannst?

[Azaxs]

Was durchtrennt der Debian buster und ist es dieser Server, den Du nach der Zwangstrennung durch deinen Internet-Provider, aus dem Internet nicht mehr erreichen kannst?

Das hast du wohl falsch verstanden, ich meinte das der 24/7 durch läuft & nicht etwas durchtrennt...

Das sieht alles prinzipiell gut aus. Und solange Du forwarding nicht aktivierst, kann das so bleiben...

Also TomL, du sagst die einstellungen sind OK so & alles sei normales verhalten wie es sein soll.

Gut, aber Fakt ist das nach der Zwangstrennung der v6 Verkehr nichtmehr funktioniert hat & ich auch nichtmehr per IPv6 rauspingen konnte.

Ich habe nun wie bereits erwähnt im NetworkManager die Privatsphären einstellung aktiviert sodass die Temporären Adressen bevorzugt werden.
Nun sieht das Adress Table so aus:

Code: Alles auswählen

inet6 2a01:c22:c85c:fff:b9ab:fe30:4942:a5af/64 scope global temporary dynamic
       valid_lft 86400sec preferred_lft 14400sec
    inet6 2a01:c22:c85c:fff:9b1:75e9:6856:de05/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86400sec preferred_lft 14400sec

Ich warte nun ab bis nach der Zwangstrennung ob der v6 Traffic dann noch funktioniert & wie das Adress Table dann aussieht.

Die "/etc/sysctl.d/sysctl_ipv6.conf" ist in meinem Debian Buster nicht vorhanden, sollte ich diese mit den angegebenen einstellungen erstellen TomL?

[TomL]

Die "/etc/sysctl.d/sysctl_ipv6.conf" ist in meinem Debian Buster nicht vorhanden, sollte ich diese mit den angegebenen einstellungen erstellen?

Die Conf hatte ja im wesentlichen nur die Änderung von tempaddr im Sinn. Vergleich einfach mal den Inhalt mit den anderen Daten. Und dann kontrolliere doch jetzt mit dem grep-Beispiel, wie tempaddr nach der Änderung im NWM jetzt aktuell gesetzt ist. Daraus sollte sich eine Antwort ableiten lassen, ob es noch netwendig ist, die Datei anzulegen. Ich kann zum NWM nichts sagen, da ich den hier auf keinem System nutze.

[mat6937]

Das hast du wohl falsch verstanden, ich meinte das der 24/7 durch läuft & nicht etwas durchtrennt...

Ich habe das gelesen was Du geschrieben hast und deshalb nachgefragt. Du hast u. a. geschrieben:

... der 24/7 durchrennt & ...

(siehe oben).

Die "/etc/sysctl.d/sysctl_ipv6.conf" ist in meinem Debian Buster nicht vorhanden, ...

BTW: Mit Eintragungen/Konfigurationen in der sysctl.conf (oder gleichwertig) solltest Du vorsichtig sein, wenn Du den NetworkManager benutzt, denn diverse Konfigurationen im NetworkManager können Eintragungen in der sysctl.conf (oder gleichwertig) unwirksam machen.

[Azaxs]

Also, nach der Zwangstrennung heute Nacht (um 05:20Uhr) durch den Router zum ISP sieht das IPv6 Adress Table des Debian Rechner nun so aus:

Code: Alles auswählen

 
   inet6 2a01:c22:c85c:fff:e806:e60d:3f47:e48b/64 scope global temporary deprecated dynamic
       valid_lft 71653sec preferred_lft 0sec
    inet6 2a01:c22:c85c:fff:9b1:75e9:6856:de05/64 scope global deprecated dynamic mngtmpaddr noprefixroute
       valid_lft 71653sec preferred_lft 0sec
    inet6 2a01:c23:806c:4fff:e806:e60d:3f47:e48b/64 scope global temporary dynamic
       valid_lft 86399sec preferred_lft 14399sec
    inet6 2a01:c23:806c:4fff:5df7:206:3cde:b75e/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86399sec preferred_lft 14399sec
    inet6 2a01:c23:806c:4fff:b9ab:fe30:4942:a5af/64 scope global temporary deprecated dynamic
       valid_lft 71652sec preferred_lft 0sec
    inet6 2a01:c22:c85c:fff:b9ab:fe30:4942:a5af/64 scope global temporary deprecated dynamic
       valid_lft 71652sec preferred_lft 0sec
    inet6 fe80::da29:9e9f:d9a3:e690/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Der IPv6 Traffic funktioniert wieder (gegen ca 11:30Uhr) nachdem die lifetime der nun veralteten Adressen abgelaufen ist, ohne das ich selbst irgendwie eingreifen muss.

Die Einträge im sysctl sind wohl nach wie vor korrekt:

Code: Alles auswählen

net.ipv6.conf.enp3s0.accept_ra = 1
net.ipv6.conf.enp3s0.autoconf = 1
net.ipv6.conf.enp3s0.forwarding = 0
net.ipv6.conf.enp3s0.mc_forwarding = 0
net.ipv6.conf.enp3s0.use_tempaddr = 2

Ich sollte noch dazu sagen das alle meine Rechner NICHT direkt am Router hängen, sondern an einem OPNsense Security Gateway der hinter den Router geschaltet ist.
Der Router (FritzBox 7490) gibt per DHCPv6 den DNS-Server & IPv6-Präfix an nachgelagerte Router weiter. Die OPNsense empfängt diesen und sendet per eigenem DHCPv6-Server einen Präfix Hinweis weiter an alle angeschlossenen Geräte.


Ich denke ich kann das jetzt so lassen & bedanke mich bei euch für eure Hilfe
Viele Grüße.

[mat6937]

Also, nach der Zwangstrennung heute Nacht (um 05:20Uhr) durch den Router zum ISP ....
Der IPv6 Traffic funktioniert wieder (gegen ca 11:30Uhr) nachdem die lifetime der nun veralteten Adressen abgelaufen ist, ohne das ich selbst irgendwie eingreifen muss.
...
Ich denke ich kann das jetzt so lassen ....

Naja, auch wenn Du auf den v6-Traffic zwischen 5:20 Uhr und 11:30 Uhr (ca. 6 Stunden) verzichten kannst, solltest Du m. E. testen, ob es nicht irgendwelche Dienste (Zeit, Namensauflösung, etc.) gibt, die auch in diesem Zeitraum auf einen funktionierenden v6-Traffic zwingend angewiesen sind.
Auch solltest Du schauen, ob in diesem Zeitraum, so manche Logdatei nicht unüblich größer wird.