IPV6, pi-hole, mehrere statische fd00 Adressen der Clients

Hallo,
ich versuche im Pi-hole Gruppen zu konfigurieren und teile in der Fritzbox eine feste fd00 IpV6 zu. Ich bin kein Experte, denke aber ich habe mich ein klein wenig eingelesen. die fe80 Adresse und die fd00 sollte es soweit ich weiss immer nur einmal geben. Also kann ich einen Client hierüber eindeutig zuweisen. Einige Geräte legen allerdinge mehrere fd00 Adressen an. Warum das? Wie funktioniert das Client Management im Pi-hole? Die neuen fd00 tauchen als neue Clients auf. Die versuche ich dann in die Gruppen einzuordnen.....aber kommen jetzt dauerhaft neue fd00 die ich immer wieder neu eintragen muss? Die sollten doch statisch sein und es sollte auch nur EINE pro Gerät geben.....wo liegt hier mein Denkfehler?

Gruß und Danke für Kommentare.
TJ

Schau direkt mal hier rein:

https://discourse.pi-hole.net/t/fritz-box-und-mehrere-ipv6-adressen/19341/12

Danke für den Tip.
Aber ich glaube dort steht keine Antwort auf mein Proble, (oder hab ich das überlesen?) bzw. dachte ich diese Privacies wirken nur auf die globalen Adressen. ULA und die local link Adressen sind doch theoretisch statisch?! Die sollen den IPV4 Standard im heimischen Netz erhalten. Aber ich bin wie gesagt ein "Hobby" Bastler und kein Experte.

Statisch heisst noch nicht, dass sie eindeutig sind oder nicht auch mehrere solcher Adressen auftauchen können, und auf IPv4 nimmt IPv6 (angesehen von wenigen Ausnahmen) überhaupt nicht Bezug.

IPv6 setzt vor allem auf Auto-Konfiguration, d.h. ein Gerät berechnet seine IPv6-Adresse selbst - genaugenommen setzt es die Adresse aus einem netzwerkseitig vorgegebenem Präfix und einem berechneten Interface Identifier zusammen.
Beide sind zunächst jeweils 64 Bit breit, wobei z.B. Dein ISP auch ein kürzeres Präfix vergeben kann (z.B. 56 Bit), was Dir wiederum einen größeren Adressraum beschert, den Du individuell vergeben kannst (wiewohl dieser dann öffentlich! sichtbar ist).

Es gibt also zwei Quellen für mögliche Adressänderungen:
Entweder das Präfix ändert sich (z.B. infolge einer Neuzuordnung des öffentlichen Präfix -aus dem Bereich 2000::/3- durch den ISP im Rahmen einer in D täglich üblichen Zwangstrennung), oder der Interface Identifier wird vom Gerät neu berechnet, z.B. durch Privacy Extensions oder bei subnetzübergreifender Verwendung von statischen privaten Adressen.

Für ULAs -aus dem Bereich fd00::/8- kann lediglich ausgeschlossen oder zumindest vorhersehbar sein, dass sich das Präfix ändert, nur für link-lokale Adressen -aus dem Bereich fe80::/10- steht das Präfix fest.

Neuberechnungen des Interface Identifiers werden jedoch geräteseitig veranlasst. Ein Gerät (bzw. dessen Betriebssystem) bestimmt also selbst , wann und mit welcher Methode der Interface Identifier neu berechnet wird.

Wenn Du nun auf einem Gerät Privacy Extensions aktiviert hast (was bei öffentlichen IPv6-Verbindungen durchaus sinnvoll ist), dann wird zusätzlich zu den vorhandenen Adressen (bis auf die öffentliche, die wird ersetzt) eine neue IPv6-Adresse aus Präfix und Interface Identifier gebildet. Dadurch wird die Anzahl an IPv6-Adressen eines Geräts (genauer: einer Netzwerkschnittstelle) nahezu verdoppelt.

Daher solltest Du bei der Auswahl der ULA-Adresse für Deinen Pi-hole darauf achten, dass Du die (auf der MAC-Adresse basierende) EUI64-Adresse oder die alternativ verwendete statische private Adresse auswählst. Für letztere kann allerdings auch manuell eine Neuberechnung erfolgen, was z.B. passiert, wenn erstmals eine solche IPv6-Adresse ermittelt wird (also eventuell auch beim Aufsetzen von Pi-hole).

Objektiv gesehen bietet IPv6 für den Privatanwender bislang wenig bis keine Vorteile, denen jedoch eine erhebliche Lernkurve mit etlichen Seiteneffekten gegenübersteht.

Wenn das alles zu wenig durchsichtig erscheint, wäre also auch das Deaktivieren von IPv6 im Router eine Option, sofern individuell kein zwingender Grund für die Verwendung vorliegt.

Wer sich mit IPv6 erst einmal langsam vertraut machen möchte, kann ebenfalls IPv6 in der FB deaktivieren und im Heimnetz bei seinen Clients zunächst relativ gefahrlos auf Privacy Extensions verzichten.
Aber Achtung: Bei Smartphones oder anderen mobilen Geräten mit wechselnden Einsatzorten (z.B. Laptops) gilt diese Vorgabe eventuell systemweit, wodurch Geräte ausserhalb des FB-Heimnetzwerks ggf. ohne PE über IPv6 exponiert wären.

Mein persönlicher Rat wäre:
Wer sich um die Risiken und Nebenwirkungen von IPv6 keine Gedanken machen möchte, schaltet das in der FB ab.

Wer lernbereit ist, sich mit den Einzelheiten, Problemen und Seiteneffekten auseinanderzusetzen, fängt mit rein lokaler IPv6-Nutzung an.

Wenn dann nach einigem Experimentieren das Verständnis gewachsen ist, kann man sich erneut die Frage stellen, ob man sein Netz auch über öffentliches IPv6 nutzen möchte.

3 Likes

Danke für die ausführliche Antwort. Ich bin soweit ich weiss hinter einer Firewall und hatte schon immer IPV6 aktiv. Das ist mir nur jetzt erst aufgefallen. Prinzipiell könnte ich es auch deaktivieren. Aber ich möchte schon verstehen, was hier genau passiert. Die fd00 Adressen, die von der FB vergeben werden sollten sich nicht ändern. Ich habe nur ein Subnetz und das Präfix hat doch auf die fd00 Adresse keinen Einfluss, da es manuell festgelegt wird. Hat Privacy extension auch auf die fd00 Adressen Einfluss? Ich bin bisher davon ausgegangen, dass die local link und die fd00 Adressen sich nicht ändern und daher eindeutig wie die IPV4 Adresse den Partner im Netzwerk identifizieren. Aber die wichtigste Frage....wie erkennt PI-hole wer da fragt? Wie wird über IPV6 kommuniziert (erste Adresse, fe80, fd00)? Wenn ich Gruppen anlegen möchte, dann macht das mit variablen Adressen keinen Sinn. Wird intern eine bevorzugt bzw. Erkennt Pi-hole wer da klopft wenn er eine neue Adresse hat? Falls nein, wie mache ich in einem solchen System ein Client management? Bitte entschuldige mein Unwissen aber ich bin hier unten auf der steilen Lernkurve......

Die FB vergibt zunächst einmal das ULA-Präfix, nicht die vollständigen Adressen.

Selbst wenn die FB wie bei DHCP für IPv4 ihren Clients eine feste IPv6-Adresszuteilung über DHCPv6 anbieten wollen würde: Ein Gerät entscheidet selbständig darüber, ob es sich über SLAAC oder Stateless bzw. Stateful DHCPv6 integriert.
Geräte, die letzteres unterstützen, hätten dann damit u.U. auch noch eine dritte Adresse, neben EUI64 bzw. statisch privater und PE-Adresse.

Eine nicht routbare, link-lokale fe80:-Adresse ist zwingend erforderlich und wird immer vollständig vom Gerät berechnet. Sie ist nur im selben Netzwerksegment sichtbar, d.h. z.B. nur direkt mit der FB verbundene Geräte können garantiert über solche Adressen miteinander kommunizieren.

Im Gegensatz dazu sind ULA und öffentliche Adressen zunächst global gültig, wobei ULA-Adressen nur eingeschränkt im Heimnetz routbar sind, während öffentliche IPv6-Adressen tatsächlich weltweit eindeutig sind.

Pi-hole verarbeitet nun ausschließlich DNS-Anfragen, und das DNS-Protokoll kennt dementsprechend auch nur und ausschließlich die IP-Adresse des Absenders. Im Hinblick auf IPv6 lässt sich dabei nicht vorhersagen, mit welcher Adresse ein Client anfragt. U.U. kann man clientseitig eine Präfix-Präferenz festlegen.

Pi-hole 5.0 hat die zunächst nur für die Admin-Oberfläche verwendete Netzwerkübersicht (Network overview) um IPv6 erweitert.

Darüber wäre es nun möglich, bei der Auswertung der Anfragen auch weitere Identifkationsmerkmale zur Gruppierung zu nutzen, solange ein (auch zeitlich) eindeutiger Zusammenhang zur in der DNS-Anfrage verwendeten IP-Adresse hergestellt werden kann. Aktuell laufen dazu die bereits erwähnten Untersuchungen in der Entwicklung, die bislang einigermassen vielversprechend ausfallen.

Zwischenzeitlich kann man sich bei flachen Netzwerken mit einem Trick behelfen (oder eben IPv6 abschalten): Wenn Du statt der ULA Pi-holes link-lokale IPv6-Adresse verwendest, zwingst Du Clients, auch nur link-lokal anzufragen.

In größeren Netzwerken wird dies allerdings nicht mehr sauber funktionieren: Geräte, die über zusätzliche Netzwerkgeräte wie z.B. einen weiteren Router, AP oder L3-Switch verbunden sind, können Pi-hole über die link-lokale Adresse dann u.U. nicht mehr erreichen.

Vielen Dank, ich bin froh, dass ich endlich jemanden gefunden habe, der dieses Thema auch mir erklären kann. Nur um mein Verständniss zusammenzufassen:
Ich könnte im Pi-hole (oder genauer im Raspberry Pi4) die hinterlegte IPV6 Adresse (die ich bereits von der globalen auf die ULA umgestellt habe) auf die fe80 ändern. Das gleiche könnte ich in der Fritzbox tun um die Anfrage beim Pi-hole auf fe80 zu zwingen. Damit zwinge ich dann alle im Netzwerk die IPV6 tauglich sind auch die fe80 zu nutzen? Stimmt das so vereinfacht gesagt?

Ich verstehe nicht, warum das (falls ich alles richtig verstanden habe) in grösseren Netzwerken nicht mehr funktioniert. Ich habe aber ein kleines Netzwerk. Zwar 4 WLAN APs aber alles nur im gleichen Mesh und auch die 2 Switch laufen im gleichen Subnetz. Keine VLANS oder ähnliches installiert.

Was macht Pi hole eigentlich mit "known clients" die nicht konfiguriert sind also einfach im drop down stehen? Werden die immer automatisch auf default gesetzt? So scheint es mir zumindest.

@Bucking_Horn Danke für deine hilfreichen Ausführungen zu IPv6. Vielleicht kannst du mir/uns bei folgenden Fragen weiterhelfen:

  1. Was passiert wenn man die IPv6 Unterstützung in der Fritzbox einfach abschaltet und Pihole / PiVPN bereits eingerichtet ist?
  • Muss dann irgendwas neu konfiguriert werden?!?
  • Ich konnte bisher auch nicht herausfinden ob man IPv6 zwingend braucht um den Telekom-VDSL Anschluss zu verwenden?!?
  1. In der Fritzbox gibt es zwei IPv6 Optionen die danach klingen als ob man damit die Adressänderungen unterbinden könnte:
  • Unter Internet --> Zugangsdaten --> IPv6 --> Verbindungseinstellungen gibt es den Punkt "Statische Einstellungen nutzen"
  • Heimnetz --> Heimnetzübersicht --> Netzwerkeinstellungen --> IPv6-Adressen --> DHCPv6-Server im Heimnetz --> DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen --> Dort steht in der Erläuterung: Geräte im Heimnetz bekommen eine IPv6-Adresse via DHCPv6 zugewiesen. Das hört sich ja danach als ob sich die Geräte nicht mehr selber Ihre Adressen zusammenstellen können/dürfen?

Ja, das stimmt.
Die Anzeige in Pi-hole ist dabei jedoch zunächst kosmetischer Natur, denn ein Interface kann mehrere IPv6-Adressen tragen.
Ob Pi-hole nun eine link-lokale oder eine ULA-IPv6-Adresse anzeigt, ist zweitrangig, solange diese Adresse tatsächlich auf dem von Pi-hole verwendeten Interface aktiv ist.
Das findet man auf einem RPi z.B. über folgendes Kommando heraus:

ip -6 address show

Entscheidend ist, dass eine dieser Adressen in der FB eingetragen ist.
Über pihole -r und Reconfigure lässt sich eine neue Adresse für Pi-hole einstellen und so auch die Anzeige sowie die korrekte lokale Namensauflösung für diese Adresse festlegen.

Das hat technische Gründe: Nur Geräte im selben Netzwerksegment (Link) können direkt miteinander kommunizieren - grob vereinfacht gesagt, hängen diese am selben Kabelstrang und können über diesen elektrische Signale senden und empfangen.

Geräte in unterschiedlichen Segmenten müssen ihren Datenverkehr über ein dediziertes Gerät leiten, dass seinerseits eine Verbindung zu einem anderen Segment herstellen kann. Ein solches Gateway ist z.B. ein Router, aber auch L3-Switches oder APs können ein eigenes Netzwerksegment definieren und als Gateway fungieren.

In Deinem Fall lässt sich ohne Studium der Handbücher oder konkretes Ausprobieren also nicht sagen, ob nicht einer Deiner 4 WLAN APs genau ein solches neues Segment definiert.

VPNs sind ein eigenes komplexes Thema, das kann ich nicht beantworten, zumal ich PiVPN nicht kenne.

Generell sind IPv6-VPN-Verbindungen nicht unproblematisch, da hierfür auf den beteiligten Endgeräten zwingend IPv6 laufen muss. In den meisten Mobilfunknetzen kommt einerseits derzeit immer noch IPv4 zum Einsatz. Bei DualStack Lite z.B. hat die FB andererseits keine öffentlich erreichbare IPv4-Adresse mehr, wodurch VPN-Verbindungen zu einem Server in Deinem Heimnetz auch zwingend auf IPv6 angewiesen wären.

Ob das Abschalten von IPv6 eine Option ist, hängt also von der Art des Anschlusses und der von Dir gewünschten (VPN-)Verwendung ab.

Unter Zugangsdaten konfigurierst Du die Verbindung der FB zu Deinem Anbieter. Statisch bedeutet hier, dass die FB ihre Einstellungen nicht mehr vom ISP bezieht, sondern Du diese manuell vorgibst.
Das Verhalten der Clients ändert sich dadurch nicht.

Dieses habe ich prinzipiell schon erläutert:
IPv6 setzt vor allem auf Auto-Konfiguration, d.h. ein Gerät berechnet seine IPv6-Adresse selbst.

Ob ein Gerät eine von der FritzBox angebotene IPv6-Adresse annimmt, hängt also vom Gerät ab. Theoretisch könnte die FB stattdessen auch eine vom Gerät gewünschte IP-Adresse in ihre Identity Association übernehmen, und selbst wenn ein Gerät die Adresse von der FB übernimmt, wird es sich dadurch nicht davon abhalten lassen, bei Bedarf eigenständig weitere IPv6-Adressen zu berechnen, z.B. für temporäre Privacy Extensions.

Und schliesslich bestimmt auch das Gerät selbst darüber, ob und welche Daten es über DHCPv6 überhaupt anfragt. Android z.B. verwendet ausschließlich SLAAC und würde somit die von der FB über DHCPv6 angebotenen Informationen nie abfragen. Die meisten anderen Betriebssysteme unterstützen mittlerweile beide Varianten (soweit ich weiss, Apple seit Lion, MS seit Win10, Linux theoretisch schon immer), wobei ich nicht vorherzusagen vermag, welches Verfahren unter welchen Umständen jeweils bevorzugt werden würde.

1 Like

@Bucking_Horn : ich dachte ich hätte es jetzt verstanden und versuche die Variante mit fe80 Adressen mal. Jetzt schiesst mir ein neues IPhone quer und hat 6 (!) fe80 Adressen. Die werden munter geändert. Wie kann ich mir das jetzt erklären? Ich dachte wenigstens hier ist eine eindeutige Client Zuordnung im Pi hole möglich. Gibt es eine weitere Möglichkeit oder muss ich doch IPV6 deaktivieren um die Gruppenzuordnung nuten zu können?

Tragen diese sechs verschiedenen fe80:-Adressen für Dein iPhone alle eine ff:fe Ziffernfolge zwischen dem sechsten und siebten Hex-Ziffernblock?

Edit: z.B. fe80::4600:10ff:feba:ddad

Keine einzige davon. Ich habe auch schon versucht modified EUI-64 zu finden aber von einem bekannten kam auch die Beschwerde, dass das neue IPhone sich untypisch verhält und ein Adresschaos verursacht. Alles natürlcih nur bei IPV6.

Ich halte es für unwahrscheinlich, aber nicht für ausgeschlossen, dass Dein iPhone dann tatsächlich Privacy Extensions für link-lokale Adressen verwendet.

Wahrscheinlicher ist aber meine Vermutung, dass Dein iPhone die EUI64 durch eine RFC7217-Adresse ersetzt, um die MAC zu verbergen. Eine solche stabile private Adresse sollte allerdings innerhalb desselben Netzwerks auch stabil bleiben.

Wenn die sich trotzdem ändert, erkennt Dein iPhone eventuell die von Deinen vier APs aufgespannten WLANs nicht als ein- und dasselbe Netz, oder die zugrundeliegende MAC-Adresse wird pro AP randomisiert.

Vom Aufbau her lassen sich diese RFC7217-Adressen kaum von Privacy Extensions unterscheiden, da beide pseudo-zufällig erzeugt werden.

Wenn Du auf dem iPhone Zugang zu einer Kommandozeile hast, kannst Du die Adressen aber mit folgendem Kommando prüfen:

ip -6 address show

Die PE-Adressen sind in der Ausgabe an einem temporary zu erkennen, im folgenden Beispiel ist dies die erste gezeigte:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:db8::a1b5:b96d:3d80:f9d3/64 scope global temporary deprecated dynamic 
   valid_lft 246sec preferred_lft 0sec
inet6 2001:db8::221:beff:feef:dead/64 scope global dynamic 
   valid_lft 6842sec preferred_lft 3421sec
inet6 fe80::221:beff:feef:dead/64 scope link 
   valid_lft forever preferred_lft forever

Ich besitze kein iPhone, daher nur als Vermutung:
Lässt sich das MAC-Adressen-Würfeln ggf. auf dem iPhone für ein WLAN-Netz gezielt deaktivieren? Eventuell vielleicht auch indirekt über eine Option, das WLAN-Netz als vertrauenswürdig einzustufen?
EDIT: Und wenn es doch eine Privacy-Extension-Adresse nach RFC 4941 sein sollte: Lässt sich das vielleicht für ein WLAN deaktivieren?

Wieder einmal danke für das Licht im Dunkel :slight_smile:
Also ich habe mal die 7 (!) fe80 in die clients im pi hole aufgenommen (Alle von EINEM iPhone). Gehen wir mal davon aus, dass die irgendwie mit den 4 Zugangspunkten zusammenhängen. Anscheinend kommunizieren jetzt alle anderen Geräte über fe80 oder ipv4. Es sieht erstmal so aus, als ob die 7 Adressen des IPhone konstant bleiben wollten…..ich melde mich morgen nochmal und berichte! Witzigerweise hat es KEINE fd00 Adresse, die es aber von der Fritzbox als ULA eigentlich zwangsweise bekommen muss......das vertehe ich jetzt überhaupt nicht aber eins nach dem anderen. Ich habe leider keinen command Zugang zu dem Gerät aber das kommt bald.

Noch ein paar kleine Fragen zum pi-hole:

  1. Kann ich in der Ansicht für die Query logs von Namen auf Adressen bei den Clients umstellen (ich will prüfen, ob wirklich nur die fe80 genutzt wird)
  2. welche Blacklists werden genommen falls Adressen ankommen, die keiner Gruppe zugeordnet sind? Alle die auf default stehen?

Wenn es tatsächlich PE-Adressen sein sollten, würde sich die Anzahl im Laufe des Tages wahrscheinlich verdoppeln. Die Gültigkeit der IPv6-Adressen liegt oft bei 24 Stunden; es gibt aber durchaus BS, die Gültigkeiten im Stundenbereich ausgeben (bei Ubuntu waren das bei meinem letzten Versuch z.B. zwei Stunden).

Zu 1.

Nein, das geht nicht.

Du kannst aber Tools|Tail pihole.log benutzen, wo live und immer ausschließlich die Client-Adressen auftauchen.
Alternativ suchst Du Anfragen über Kommandozeile direkt auf dem Pi-hole-Rechner:

grep -n "from" /var/log/pihole.log

Zu 2.

Richtig.
Nicht zugeordnete Clients werden über Default gefiltert.

OK, die Adressen sehe ich jetzt und es scheinen auch nur noch fe80 zu sein. Das Iphone überrascht mit einer fd00 Adresse die jetzt in der Fritzbox angezeigt wird (zusätzlich zu den 7 fe80 Adressen).......nach 2 Tagen im Netz.

Wenn alle Unbekannten über default gehen, dann kann ich noch immer über die fe80 und die IPV4 filtern. Das betrifft für einige Listen nur Geräte die EINE fe80 haben. Ich hoffe nur, dass diese Geräte dann nicht irgendwie den Filter umgehen können weil sie eine fd00 haben die nicht konfiguriert ist und dann doch aus mir unbekannten Gründen diese Adressen nutzen um an den Blacklisten der Gruppe vorbeizukommen.

Ich teste die Konfiguration so und hoffe, dass das funktioniert. Ich melde mich in ein paar Tagen Testphase

Nutzt iOS auch Mac-Randomization? Bei Android ist es mittlerweile ab Version 10 scheinbar per default aktiv und gaukelt je Wifi-Netz eine andere MAC-Adresse vor.

Das soll prinzipiell eine Datenschutzfunktion sein und die Identität verschleiern.