Ich betreibe den Pi-hole nun schon einige Monate und habe mit der IPv6-Konfiguration leider so meine Probleme:
Wenn ich es richtig verstehe, erzeugt sich der RasPi seine globale IPv6-Adresse mit dem vom ISP zugeteilten Präfix selbst und wechselt regelmäßig (privacy-Schutz).
Was ich absolut nicht verstehe ist weshalb mir in der Pi-hole Admin Console > Settings die globale IPv6-Adresse angezeigt wird. Diese wird ja auch von dnsmasq für geblockte Seiten zurückgegeben.
Sollte da nicht eher die link-lokale (= Netzwerk-interne) Adresse ausgegeben werden, um nicht abhängig vom ISP-Präfix zu sein?
Die angezeigte und zurückgegebene IPv4-Adresse ist ja auch nur netzwerk-intern gültig.
Von einem Tag auf den anderen hatte die globale IPv6-Adresse (Präfix glieb aber gleich) des RasPis gewechselt.
Um die geänderte IPv6-Adresse in der Admin Console und in dnsmasq zu aktualisieren musste ich pihole -r > repair ausführen.
Mittlerweile habe ich in /etc/dhcpcd.conf den Parameter SLAAC auf hwaddr geändert, weil ich gelesen hatte, dass dann die link-lokale Adresse aus der MAC erzeugt wird.
Nach einem Neustart wurden aber nun sowohl die link-lokale alsauch die globale IPv6-Adresse aus der MAC gebildet. Jedenfalls sollte sie sich somit nicht mehr ändern....
Ja und Nein. Per Standard sollte die Privacy Extension aktiv sein (d.h. kein direkter Rückschluss von Scope global auf MAC Adresse möglich), jedoch keine regelmäßig rotierenden Adressen verteilen. Wie kommst Du auf diese Einschätzung? Ich bin ja immer gerne bereit sowas herauszufinden und zu diskutieren.
Achtung Fallstrick: Die Sicherheits-Policy der Deutschen Telekom schreibt bei einigen Geräten (insb. Speedport W723V) eine regelmäßige Erneuerung der IPv6 Adressen vor. Dies ist bei einigen Modellen (z.B. Speedport W724V) abschaltbar.
Idealerweise sollte sich der ISP-Präfix gar nicht ändern (was er normalerweise auch nicht tut). Die DT stellt hier leider wieder eine Ausnahme dar. Scope Link Adressen zu verwenden ist eine ganz schlechte Idee (s.u. für mehr Details).
Hier zeigt sich dann so langsam, warum Du "Verstehe IPv6 nicht so ganz" als Überschrift gewählt hast. Wir reden hier über derartig andere Konzepte, dass der Vergleich hier schon im Allgemeinen extrem hinkt. Bedenke, dass die IPv4 Adressen jeweils entweder von einem DHCP Server oder manuell vergeben werden und überhaupt nicht funktionieren würden, wenn es kein NAT gäbe, dass jedes ein- und ausgehende Paket umschreibt (zusätzliche Latent).
Nehmen wir nun für ein Beispiel einen Rechner mit zwei Netzwerkkarten: Es ist natürlich sofort klar, dass diese beiden Interfaces an unterschiedlichen Netzwerken angeschlossen werden müssen, denn es können nicht beide an unabhängigen Netzwerken mit jeweils 192.168.1.x angeschlossen werden. Woher soll das System denn ansonsten wissen mithilfe welcher Karte die Adresse 192.168.1.1 angesprochen werden soll, bzw. - noch schlimmer - wenn das Gerät in beiden Netzen existiert, welches denn nun das Richtige ist. Das Problem: Das Netzwerk ist nicht mehr eindeutig, denn der Präfix ist nicht eindeutig.
Genau dieses Problem haben wir nun bei Scope Link Adressen, denn diese können in allen Netzwerken vorkommen.
Auf zu ein paar Computerexperimenten:
ich@buero ~ $ ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2003:89:e66:X:X:X:X:X64 scope global noprefixroute dynamic
valid_lft 604753sec preferred_lft 86353sec
inet6 fe80::2e3:10ff:X:X/64 scope link
valid_lft forever preferred_lft forever
3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2003:89:e3f:Y:Y:Y:Y:Y/64 scope global noprefixroute dynamic
valid_lft 14385sec preferred_lft 1785sec
inet6 fe80::d250:99ff:Y:Y/64 scope link
valid_lft forever preferred_lft forever
In meinem Netzwerk (verbunden über eth2) existiert nun auch noch folgendes Gerät:
me@ubuntu ~ $ ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2003:89:e3f:Z:Z:Z:Z:Z/64 scope global temporary dynamic
valid_lft 14392sec preferred_lft 1792sec
inet6 2003:89:e3f:W:W:W:W:W/64 scope global dynamic
valid_lft 14392sec preferred_lft 1792sec
inet6 fe80::feaa:14ff:V:V/64 scope link
valid_lft forever preferred_lft forever
Also versuche ich es nun über die Scope Global Adresse an zu pingen:
ich@buero ~ $ ping6 2003:89:e3f:Z:Z:Z:Z:Z
PING 2003:89:e3f:Z:Z:Z:Z:Z(2003:89:e3f:Z:Z:Z:Z:Z) 56 data bytes
64 bytes from 2003:89:e3f:Z:Z:Z:Z:Z: icmp_seq=1 ttl=255 time=0.391 ms
64 bytes from 2003:89:e3f:Z:Z:Z:Z:Z: icmp_seq=2 ttl=255 time=0.191 ms
^C
--- 2003:89:e3f:Z:Z:Z:Z:Z ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.192/0.291/0.391/0.100 ms
Alles klar, das hat gut funktioniert - schließlich ist der IPv6 Präfix bei der Scope Global Adresse ja auch eindeutig und unser Rechner kennt die zu nutzende Route daher bzw. kann sie bei seinem Gateway erfragen. Nun versuchen wir das gleicher mit der Scope Link Adresse:
Wieso hat das nun nicht geklappt? Wie ich oben beschrieben habe ist die Scope Link Adresse eben nicht eindeutig, sodass das Interface noch mitangeben werden muss:
ich@buero ~ $ ping6 fe80::feaa:14ff:V:V%eth2
PING fe80::feaa:14ff:V:V%eth2(fe80::feaa:14ff:V:V) 56 data bytes
64 bytes from fe80::feaa:14ff:V:V: icmp_seq=1 ttl=255 time=0.203 ms
64 bytes from fe80::feaa:14ff:V:V: icmp_seq=2 ttl=255 time=0.176 ms
64 bytes from fe80::feaa:14ff:V:V: icmp_seq=3 ttl=255 time=0.182 ms
^C
--- fe80::feaa:14ff:V:V%eth2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.176/0.187/0.203/0.011 ms
Dieser kritische Aspekt mag bei Geräten, die grundsätzlich nur eine Netzwerkschnittstelle aufweisen, maskiert sein, darf aber nicht übersehen werden. Wir haben eine große Anzahl an Nutzern, die sich auch einen VPN-Server aufgesetzt haben, sodass hier zwei Schnittstellen vorliegen. Außerdem geht eine immer größere Anzahl an Nutzern weg vom Raspberry und hin zu virtuellen Maschinen. Wenn diese dann in großen Rechenzentren liegen, haben sie meist auch mehrere (virtuelle) Schnittstellen.
Zu der ganzen Problematik kommt dann noch hinzu, dass die großen Browser (Chrome, Firefox, etc.) zunehmend Probleme mit dem Ansprechen von Scope Link Adressen haben (und das noch nicht einmal über die Betriebssysteme hinweg konsistent ist).
Ich hoffe ich konnte etwas Licht ins Dunkel bringen.
Man erlaube mir noch ein P.S.: IPv6 ist eine tolle Sache, den sie bringt den ursprünglichen Gedanken des Internets wieder hervor: jedes Gerät hat eine eindeutige Adresse und es können somit "echte" Ende-zu-Ende Verbindungen aufgebaut werden. Das NAT war immer nur eine Notlösung (sonst wäre IPv4 natürlich schon vor einigen Jahren komplett ausgelaufen) und sollte niemals als "Sicherheit" verstanden werden. Solange die Firewall korrekt eingestellt ist, werden alle IPv6 Geräte genau so gut geschützt - selbst wenn sie von außen nun eindeutig identifizierbar sind. Die Privacy Extension ist etwas was sich viele gewünscht haben, jedoch einige Vorteile wieder etwas einstampft. Ich weiß selbst, dass die Gedankenumstellung IPv4 -> IPv6 nicht trivial ist und man sich ohne "schützendes" IPv4-NAT im IPv6-Dschungel zunächst etwas nackt fühlt, aber das geht vorbei, sobald man beginnt das Konzept richtig zu verstehen. Vertrau mir!
Hi.
Danke erstmal für die sehr ausführliche Antwort und die Erklärungen
Dann hatte ich das trotz diverser Erklär-Videos auf youtube falsch interpretiert.
Nach einigen Tagen Betrieb von Pi-hole hatte ich -warum auch immer- das Phänomen dass sich eben die scope global-Adresse des Raspberrys geändert hatte (ifconfig zeigte eine andere globale IPv6-Adresse als in der WebGui).
Dummerweise beantwortete Pi-hole dann DNS-Anfragen zu blockierten Domains aber weiter mit der alten (= falschen) IPv6-Adresse. Nicht mal ein Neustart konnte das beheben, sondern erst die Reparatur von Pi-hole mittels pihole -r > Repair.
Damit dies eben nicht erneut passiert habe ich die Privacy Extension deaktiviert.
Bei der Telekom bin ich auch. Muss ich bei der Fritzbox auch irgendwo die regelmäßige Erneuerung der IPv6-Adressen abschalten?
Habe dazu bisher noch keine Checkbox gesehen.
Was ich mich dann auch noch Frage: Wie funktioniert dann die netzwerk-interne Kommunikation, falls mal die Internetverbinung ausfällt bzw. garnicht vorhanden ist, also wenn kein Präfix mitgeteilt wird.
Werden dann die zuvor zugeteilten Adressen weiterverwendet?
Oder müsste ich dann DHCPv6 in der Fritzbox aktivieren um die Kommunikation zu ermöglichen?
Ich hatte mal testweise auf meinem Windows-Laptop IPv4 deaktiviert um zu sehen ob die Kommunikation auch rein über IPv6 funktionieren würde. ipconfig /allgibt mir folgendes zurück:
Ping an die eigene globale Adresse und die des Raspberrys klappt problemlos.
Aber die DNS-Server-Adressen scheinen nicht zu stimmen.
Die Fritzbox ist doch eigentlich per Standard so eingestellt, dass sie lediglich den DNSv6-Server bekanntgibt. Das sieht aber nicht danach aus
Siehe auch meine Antwort auf die nächste Frage. Wenn Dich Dein Router dazu zwingt, dass sich der Präfix einmal täglich ändert, dann bringt Dir das leider auch nichts, denn selbst wenn der Suffix nun über die MAC definiert ist, wird Dir der Präfix von der Telekom zugewiesen. Das kann dann also einmal täglich (routerabhängig) oder zumindest zwangsläufig bei jeder Einwahl (tägliche Zwangstrennung gibt es ja glücklicherweise nicht mehr) zu einer Vergabe neuer Adressen führen.
Wir haben das Problem mit anderen Nutzern (wie auch bei mir) immer im Zusammenspiel mit Speedport-Routern gesehen. Wie gesagt, einige Modelle "zwingen" Dich dazu, andere (teurere) Speedport-Modelle lassen Dir die Wahl. Vielleicht ist das mit der Fritzbox ebenso (ich werde mir niemals eine Fritzbox zulegen, aber das ist ein anderes Thema).
Ja, das ist jetzt so ein Problem. Verschiedene Betriebssysteme unterstützen die unterschiedlichen Standards unterschiedlich gut (siehe hier). Abseits von Linux (z.B. Ubuntu) ist das leider weiterhin ein Trauerspiel. Während Windows in der aktuellsten Version mit DHCPv6 klar kommt, trifft das z.B. nicht auf Android und andere zu. Ein funktionierendes Netzwerk ohne Scope Global Präfix ist ein Lotteriespiel.
Ja, das ist bei einer vorher einmal zugewiesenen Präfix problemlos möglich. Die Geräte wissen, zu welchem Präfix sie gehören (z.B. 2003:7f:8f56:5400:xxx:xxxx:xxxx:xxxx/64 von Dir) und werden entsprechend Geräte mit beliebigen Werten für x in Deinem lokalen Netzwerk suchen, denn nur dort dürfen sie existieren.
Wenn kein Präfix zur Verfügung steht, dann funktionieren grundsätzlich immer die Scope Link Adressen (fe80:*). Pings werden immer ankommen - bei einem Rechner mit mehr als einer Netzwerkschnittstelle muss das Interface eben mit angegeben werden (bei Dir scheinbar %4, was auch immer Windows mit "4" meint...).
ABER (wie schon in meinem vorherigen Beitrag erwähnt): Obwohl bspw. ping und ähnliche Netzwerkprogramme problemlos damit umgehen können, ist die Browserunterstützung für Scope Link Adressen ebenso lücken- und sprunghaft wie die IPv6 Unterstützung der Betriebssysteme (Beispiel: Firefox, die Liste lässt sich beliebig fortsetzen). Gerüchten zufolge kann der Internet Explorer in begrenztem Umfang damit umgehen, solange nur eine Netzwerkschnittstelle aktiv ist, ich habe aber kein Windows, kann also auch nichts testen. Ähnliches gilt für Chromium, aber nur unter Linux. Alles leider recht undurchsichtig...
Das Problem haben wir häufiger gesehen - es kommt mit weit überwiegender Häufigkeit daher, dass die Router entweder zu wenig Optionen für die Einstellung des DHCP-Servers bieten oder diese sogar teilweise falsch umsetzen. Gerade zum Thema Fritzbox und IPv6 gibt es hier auf Discourse bereits mehrere (englischsprachige) Diskussionen. Zusammenfassend kann man sagen, dass man wohl am besten damit fährt die Fritzbox zunächst so zu konfigurieren, dass sie gar keinen IPv6-DNS Server verteilt. Dann greifen alle Gerät über IPv4 auf das Pi-hole zu und das funktioniert. Natürlich kann unabhängig von der zugrunde liegenden IPv4-Kommunikation eine IPv6 Adresse vom DNS Server abholen, sodass es hier keine Funktionseinbußen gibt. Sollte in ein paar Jahrzehnten wirklich einmal IPv4 eingestampft werden, dann wird es bis dahin hoffentlich Router geben, die nicht nur halbherzig mit dem Thema umgehen können...
In den letzten Tagen musste ich zuerst meine Fritzbox neustarten (WebGui war nicht mehr erreichbar) und kurz danach auch meinen Raspberry (die usv war dummerweise falsch konfiguriert und löste den shutdown schon nach 10s anstatt nach 10min aus).
Nun hat sich der vom ISP zugeteilte IPv6-Präfix geändert. Obwohl die IPv6-Adresse des PIs mit ifconfig korrekt ausgegeben wird, zeigt die Pi-Hole-WebGui weiterhin die alte IPv6-Adresse an und diese alte Adresse wird auch bei blockierten Domains zurückgegeben.
Im Endeffekt dauert das Laden der Webseiten dann eine Ewigkeit, weil der Browser anscheinend IPv6 bevorzugt und vergebens auf eine Antwort von der falschen IPv6-Adresse wartet.
Lässt sich das nicht automatisieren, dass Pi-Hole merkt, wenn sich die IP-Adresse ändert und die Gravity-Listen neu einliest?
Notdürftig habe ich nun in /etc/pihole/setupVars.conf die Zeile IPV6_ADDRESS so abgeändert, dass hier nun nicht mehr die IPv6-Adresse steht, sondern die interne IPv4-Adresse und IPv6-Schreibweise und anschließend pihole -g ausgeführt.
Oh, Du leidiges Thema... Bislang haben wir dieses Verhalten bei der Telekom (inkl. mir) und bei 1&1 bestätigt...
Ein Telefonat mit einem wirklich fachkundigen Mitarbeiter der Telekom hat leider geben, dass in nächster Zeit für Privatkunden nicht mit einer Besserung zu rechnen ist.
Ja, den Plan gibt es durchaus (IPv4 und IPv6 während pihole -g ermitteln und dann diese Werte verwenden), uns fehlt es aufgrund starker beruflicher Einbindung des Großteils des Entwicklerteams die Umsetzungsfähigkeit. Die Mechanismen sind ziemlich komplex und ein Umbau bedarf einer umfassenden Serie an Tests, die wir zurzeit nicht leisten können. Daher lassen wir es dann lieber (vorübergehend) weg als nachher teilweise nicht funktionierende Installationen zu riskieren.
Ich habe nun ULA in meiner FritzBox aktiviert.
Musste danach aber die ULA-Adresse händisch in /etc/pihole/setupVars.conf eintragen und mit pihole -g aktiv setzen.
Denn leider hat sich pihole nach einer Rekonfigurierung (mittels pihole -r) wieder die globale IPv6-Adresse anstatt der vorhandenen ULA-Adresse gezogen.
Nun läuft es wieder ordentlich und ich hoffe dass dies auch so bleibt. Vielen Dank @DL6ER für die Mühe und die sehr hilfreichen Ausführungen.
Ich leiste aktuell noch etwas Überzeugungsarbeit im Entwicklerteam, da man hier noch nicht so richtig von der Verwendung der ULAs überzeugt ist. Scheinbar macht kein bedeutender Provider außerhalb Deutschlands so eine sonderbare Aktion mit nicht-statischen IPv6-Prefixen
Bislang wird daher vom Installationsskript immer nach eine GUA-Adresse gesucht.
@DL6ER,
könntest du mir bitte sagen, wie man die IPv6 Adresse an dem Beispiel des
Speedport 724v in dem Bild des Link liesst?
Ich komm damit nicht klar. Mehrfache Doppelpunkte sollen für jeweils 0000 stehen,
ich komme dabei aber nur auf 7 Gruppen, nicht 8.
Somit kann ich die IPv6 nicht richtig in den Pi (setupVars.conf) eintragen.
Vielen Dank
Die führenden Nullen kann man ohne Informationsverlust ersatzlos weglassen: 2001:ab1:0:0:0:0:0:1
Zusammenhängende Null-Blöcke dürfen (maximal einmal) gänzlich gestrichen und durch :: ersetzt werden 2001:ab1::1
Diese Adresse ist doch schon viel handlicher
Pi-hole versteht alle diese von mir hier aufgeschriebenen Formen (zumindest ist das der Plan). Wenn Du festgestellt hast, dass Du die Adressen mit Nullen auffüllen musst, dann hast Du einen Fehler gefunden. Dann bitte ich um Deinen Bericht.
Hallo DL6ER,
ach jetzt kapier ich (hoffentlich
Die beiden Doppelpunkte setzen soviel Nullblöcke,wie benötigt um die 8 Blöcke
vollzukriegen?
Ich dachte 2 Doppelpunkte seien 2 Nullblöcke und das ging dann nicht auf.
Muss ich nahher sofort probieren.
Vielen Dank!
Edit: Es hat bei mir auch unter OS X funktioniert.
Meine Einstellungen habe ich unter dem Thread "3 Tage Pihole, naja" abgelegt.
