Pi-Hole + FritzBox + IPv6 Dual Stack Lite - Welche IPv6 in die FritzBox eintragen?

[mx2k]

Servus,

Ich habe einen Pi-Hole als primären DNS Server laufen und wundere mich weiterhin, welche der diversen IPv6 Adressen des Pi-Hole denn nun die korrekte ist, um sie in die FritzBox als per DHCPv6 zu verteilenden DNS Server einzutragen.

Die FritzBox läuft an einem Dual Stack Lite Anschluss, also ich habe ein vom ISP zugeteiltes IPv6 Präfix. ULA wird von der FB nur vergeben, wenn kein Präfix bezogen werden kann.

Ich habe bisher die fe80:: Adresse des Raspi verwendet (scheinbar die einzige, die wirklich immer statisch ist). Allerdings bin ich nun auf folgenden Artikel irgendwo hier im Forum gestoßen:

Ein möglicher, aber unsaubererer Workaround bestünde darin, Deine FB die (nicht routbare(!)) link-lokale Adresse Deines Pi-holes (aus dem Adressbereich fe80::/10) verteilen zu lassen. Das ist deshalb unsauber, weil diese Adresse nur für die direkte Kommunikaton in denselbem Netzwerksegment vorgesehen ist. Geräte, die über einen L3-Knoten (weiterer Router, Switch, Access Point,...) verbunden sind, können Pi-hole somit nicht mehr erreichen.

Kurzum steht hier, dass diese Methode nicht sauber ist (dennoch, meine Geräte an Switches können den Pi-Hole auf der fe80:: alle erreichen)

Allerdings sehe ich auch immer wieder IPv6-NODATA Antworten der FritzBox, die evtl. damit zu tun haben könnten? Sieht in den Logs so aus (Die FritzBox kennt die IPv6 der Geräte und sollte eigentlich nicht mit NODATA antworten):

Apr  3 03:09:00 dnsmasq[26278]: query[A] mx-nas.fritz.box from fe80::a41f:aed6:1ea7:bbe3
Apr  3 03:09:00 dnsmasq[26278]: forwarded mx-nas.fritz.box to 10.1.1.1
Apr  3 03:09:00 dnsmasq[26278]: reply mx-nas.fritz.box is 10.1.1.5
Apr  3 03:09:00 dnsmasq[26278]: query[AAAA] mx-nas.fritz.box from fe80::a41f:aed6:1ea7:bbe3
Apr  3 03:09:00 dnsmasq[26278]: forwarded mx-nas.fritz.box to 10.1.1.1
Apr  3 03:09:00 dnsmasq[26278]: reply mx-nas.fritz.box is *NODATA-IPv6*

---

Zur eigentlichen Frage:

Kann mir jemand kurz und schmerzlos beantworten, welche der zur Auswahl stehenden IPv6 des Pi-Hole die Richtige ist, um sie in die FritzBox einzutragen?

Eher die mit dem ISP-Präfix und /128, oder die mit /64?

Verstehe ich richtig, dass diese beiden Adressen mit ISP-Präfix quasi statisch sind, es sei denn, der ISP kommt auf die Idee, das Präfix zu ändern?

> $ ip addr
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:xx:xx:aa:a7 brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.6/8 brd 10.255.255.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever

     inet6 [ISP IPv6 Präfix]:e9dc:8727:cead:xxxx/128 scope global dynamic noprefixroute
        valid_lft 7048sec preferred_lft 3448sec

     inet6 [ISP IPv6 Präfix]:3bd0:e69f:2229:xxxx/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 2373sec preferred_lft 2373sec
	   
     inet6 fe80::e9dc:8727:cead:xxxx/64 scope link 
        valid_lft forever preferred_lft forever

Vielen Dank und frohe Ostern!

[Bucking_Horn]

@mx2k

Allerdings sehe ich auch immer wieder IPv6-NODATA Antworten der FritzBox, die evtl. damit zu tun haben könnten?

Das sind reguläre Antworten eines DNS-Servers. Sie bedeuten schlicht, dass für den angefragten Typen keine IPv6-Daten existieren (also z.B. das für eine Domäne keine IPv6-Adresse existiert).

@mx2k

Verstehe ich richtig, dass diese beiden Adressen mit ISP-Präfix quasi statisch sind

Nein, auch der Interface Identifier kann sich ändern.
Ob und wann das passiert, hängt u.a. auch von der jeweiligen IPv6-Konfiguration des jeweiligen Clients ab.

Die öffentlichen GUA-Adressen solltest Du also meiden, da sich bei diesen normalerweise sowohl das Präfix als auch der Interface Identifier ändern können. Hinzu kommt, dass solche öffentlichen IPv6-Adressen prinzipiell auch von außerhalb Deines Heimnetzes erreichbar sein können, sofern der Router dies nicht unterbindet.

Eine vorhandene ULA-Adresse solltest Du gegenüber einer link-lokalen IPv6-Adresse bevorzugen. Die FB sollte daher das ULA-Präfix immer zuteilen. Wenn Dein Netzwerk gesichert nur aus einem Segment (oder link) besteht, kannst Du auch link-lokale Adressen ohne Bedenken verwenden.

[mx2k]

@Bucking_Horn

Das sind reguläre Antworten eines DNS-Servers. Sie bedeuten schlicht, dass für den angefragten Typen keine IPv6-Daten existieren (also z.B. das für eine Domäne keine IPv6-Adresse existiert).

Das Problem an sich tritt dann auf, wenn ich z.B mit nslookup oder dig die IPv6 eines Clients im LAN abfragen will. Sprich nslookup pi.hole (oder NAS, etc.) liefert nur die IPv4 zurück, obwohl in der FritzBox zu dem Gerät diverse IPv6 bekannt sind.

Ich weiß, dass die nslookup Abfragen "früher" mal beide IPs (4 & 6) eines Client zurückgeliefert haben, aber seit irgendeinem der Updates der letzten Jahre ist das irgendwie kaputt gegangen (oder durch deaktivieren der ULA Zuweisung?). Hieran zerbeiße ich mir schon ewig die Zähne.

Am Anfang, wo noch alles funktioniert hat, hatte ich (wenn die Erinnerung stimmt) noch "ULA immer Zuweisen" in der FB an, da ich noch keinen nativen v6 Anschluss hatte. Das habe ich aber auf Anraten des AVM Support umgestellt, damit nur bei IPv6 Verbindungsausfall die ULA zugewiesen wird. Dies scheint aber irgendwo dann doch nicht so sinnvoll zu sein.

@Bucking_Horn

Eine vorhandene ULA-Adresse solltest Du gegenüber einer link-lokalen IPv6-Adresse bevorzugen. Die FB sollte daher das ULA-Präfix immer zuteilen. Wenn Dein Netzwerk gesichert nur aus einem Segment (oder link ) besteht, kannst Du auch link-lokale Adressen ohne Bedenken verwenden.

Wie weis ich denn, ob mein LAN aus einem Segment besteht? Verkabelung sieht so aus: FB am 24 Port Managed Switch, von da aus noch Unterverteilung mit kleineren 8-Port Switches pro Raum. Der Pi-Hole hängt am Managed Switch im Port neben der FB.

Alle Geräte im LAN kommunizieren gefühlt problemlos mit dem Pi-Hole. Bzw. die FritzBox gibt per Router Advertisement oder DHCPv6 Ihre eigene fe80:: Adresse als primäre Gateway Adresse an die Clients weiter. Daher dachte ich, im LAN nimmt man immer die fe80::.

Frage am Rande: Wenn VPN Software (wireguard/ovpn) mit auf dem gleichen Rechner wie Pi-Hole läuft, würde die Verwendung der fe80:: erklären, wieso ich mich aus dem LAN ohne Probleme in das VPN einwählen kann, von Unterwegs aus z.B. mobilen Netzen von Außen einfach keine Verbindung herzustellen ist (obwohl die entsprechenden Ports offen sind)? Klingt irgendwo logisch, wenn die fe80:: nicht routbar ist.

An anderen Stellen hier im Forum habe ich gelesen, man soll am besten die von pihole -r ermittelte IPv6 hernehmen, diese ist aber identisch mit einer der GUA Adressen, die das ISP-Präfix enthalten. Mal gespannt, ob sich das ändert, wenn ich die ULA Zuweisung wieder aktiviere.

Und es gibt scheinbar möglichkeiten, eine kurze, statische IPv6 per Config-Datei zuzuweisen. Sowas wie fd00::2. Wie sinnvoll wäre dieser Schritt?

[mx2k]

Bzw. nochmal mit Screenshots am Beispiel meiner NAS:

Die lokalen Anfragen IPv4/6 werden per Conditional Forwarding an die FB geschickt, weil die ja als DHCP die Adressen an die Clients vergibt.

Bisschen per Brecheisen die ganze .arpa Domain für IPv6 an die FritzBox weitergeleitet. Zusätzlich zur im Webinterface eingestellten IPv4 Conditional Forwarding. Wurde mir vor gefühlt 2 Jahren in irgendeiner Diskussion hier empfohlen, das so zu machen, aber ob das so sinnvoll ist, weis ich halt nicht. Manch anderer sagt nur die 10.0.0.0/8 im Webinterface einstellen ist völlig ausreichend.

Wie dem auch sei, Screenshots!

DNS auf der FB lokal für v4/v6 auf Port 53:

Netzwerk Infos auf der NAS (NAS hat 3 bekannte IPv6)

NAS in der FritzBox (FritzBox kennt gerade nur 2 davon, weil ich ULA erst vor 1min aktiviert habe)

Abfrage der NAS mit nslookup:

Und die Abfrage in den Logs:

Und hier das anhaltende Verständnisproblem: FritzBox kennt ganz offensichtlich einige IPv6 des Client. Gibt aber NODATA auf die AAAA Anfrage zurück. Das kommt mir immer noch fehlerhaft vor. Oder irgendwas ist am DNS auf der FB kaputt (das Ding ist alt und stürzt gerne mal ab).

Ich weiß noch sicher vom Testen bei der Ersteinrichtung des Pi-Hole, dass damals alle der FB bekannten IPv4 und v6 Adressen (auch die temporären bei Windows Clients) bei der nslookup bzw dig Abfrage eine korrekte AAAA Antwort der FB bekamen, und nicht NODATA.

AVM Support hatte auch keine Erklärung, warum es damals ging und jetzt nicht mehr.

Oder klemmt hier irgendwas in meinem Kopf, dass ich die Abläufe immer noch nicht richtig verstehe?

Edit: Vor allem das hier ist mir nach wie vor ein Rätsel. Wenn ich den Pi-Hole selbst unter der Standard-Domain pi.hole per nslookup abfrage, liefert er zumindest die eigene ULA zurück. Wenn ich den Pi-Hole über seinen Hostname rpi-dnshole abfrage, liefert er nur die IPv4 zurück. Woran kann denn sowas liegen?

Auch interessant, Abfrage eines Windows PCs gibt nen Timeout und N/A, anstelle von NODATA.

[mx2k]

Und direkt noch ne ULA Frage:

ULA immer Zuweisen mal testweise eingeschaltet, diverse Clients kontrollier. Die meisten haben ihre Interface ID mit fd00:: anstatt fe80:: erhalten.

Ausgerechnet beim Pi-Hole wurde natürlich eine komplett neue ULA ausgewürfelt, die auch wieder nen valid_lft Timer hat.

Wie sicher ist, dass diese neue ULA Adresse nun unverändert bleibt? Bei der link-local steht ja valid_lft forever. Dort steht zumindest dabei, das diese wirklich statisch ist. Nicht dass ich die ULA jetzt in der FB als zuzuweisenden v6 DNS Server eintrage und in paar Tagen ändert sich die wieder.

Weis wer, woran das liegen kann, dass manche Geräte quasi ihre Interface ID für die ULA hernehmen, andere wiederum eine neue "erfinden"?