Ich habe PiHole bisher ausschließlich für natives IPv4 (öffentliche, dynamische IPV4 Adresse) konfiguriert und jahrelang im Einsatz gehabt (inklusive Unbound und OpenVPN).
Nun habe ich es aber mit deutlich anderen Umständen zu tun: Bei dem Anschluss handelt es sich um eine Glasfaser Leitung mit privater, dynamischer IPv4 Adresse und (nativer) öffentlicher, dynamischer IPv6 Adresse (die vom Provider bervorzugt genutzt wird). Also DS-Lite. Ein Wechsel auf Dual-Stack scheint erstmal nicht möglich.
Nun möchte ich den PiHole inklusive Unbound entsprechend konfigurieren (und später VPN, was aber eine eigene Baustelle wird).
Ich bin ursprünglich nach dieser und dieser Anleitung vorgegangen.
Soweit läuft auch erstmal alles wie gewünscht: Die DNS-Anfragen laufen zu 100% über Unbound. Der gesamte Internetverkehr wird ausnahmeslos durch PiHole gefiltert oder geblockt (Fritzbox kennt nur den PiHole als DNS und verweist alle Geräte ans PiHole).
Nun habe ich aber diverse Probleme mit IPV6. IPV4 Only nutzen kann ich nicht, da dann die Hälfte des Datenverkehrs (IPV6) nicht ins Internet kommt oder nicht gefiltert wird.
Die Geräte machen manchmal Anfragen über IPV6 mit ständig wechselnden Adressen:
Ein Beispiel: Eine Playstation 4 sendet sämtliche DNS Anfragen per lokaler IPv4 an den PiHole. Sie wird über die MAC-Adresse, bzw. IPv4 Adresse vom Pihole erkannt und entsprechend den Adlisten-Gruppen zugewiesen. Nun passiert es aber, sobald sie sich am Playstationnetwork anmelden will, sendet sie eine einzige DNS-Anfrage über ihre lokale IPV6 Adresse. Diese wird vom PiHole als "unbekanntes Gerät" erfasst und der Gruppe "default" zugewiesen. Da bei mir aber unbekannte Geräte keinen Zugriff auf's Internet erhalten sollen, ist der Gruppe "Default" als einziges der Blacklist RegEx "." zugewiesen. Die Anfrage der Playstation kommt also nicht durch "weil Regex "."". Nun kann ich die Playstation unter Clients aber nicht ausfindig machen (ist ja bereits mit MAC und iPv4 eingetragen). Gebe ich ihre IPv6 Adresse manuell ein, macht sie die nächste Anfrage unter einer ihrer vielen anderen IPV6 Adressen und kommt wieder nicht durch.
Ehrlich gesagt verstehe ich es ohnehin nicht, warum diese IPv6 Geschichte so unfassbar kompliziert gestaltet wurde. Kein Wunder, dass die Industrie sich seit 30 Jahren weigert, auf diesen Schwachsinn umzusteigen. Die IPv4 auf die Länge der IPv6 zu vergrößern hätte völlig ausgereicht, ohne diese ganzen Extrawürste die mit IPv6 noch einhergehen.
Das ist eingestellt:
Fritzbox:
Internet, IPv6:
- IPv6-Unterstützung aktiv
- Native IPv6-Anbindung verwenden (nativ IPv4 geht nicht), IPv4-Anbindung über DS-Lite herstellen, AFTR-Adresse automatisch über DHCPv6 ermitteln
- Globale Adresse automatisch aushandeln
- DHCPv6 Rapid Commit verwenden
- IPv6-Adresse der FRITZ!Box zufällig festlegen
DNS-Server: - Andere DNSv4-Server verwenden: [lokale IPv4 vom Pihole]
- Andere DNSv6-Server verwenden: [lokale IPv6 vom Pihole]
- Verschlüsselte Namensauflösung im Internet (DNS over TLS), Zertifikatsprüfung für verschlüsselte Namensauflösung im Internet erzwingen, [inklusive 4 eingetragene DNS-Server wie dnsforge z.B.]
- alles andere deaktiviert
"Internet" -> "Filter": so gesetzt, dass nur Anfragen übers PiHole zugelassen werden.
PiHole:
DNS:
- alles deaktiviert, ausser: Custom DNS1: 127.0.0.1#5335, "Allow only local requests"
Domains: - der Gruppe "default" den Blacklist Regex "." zugewiesen und sonst nichts, damit dem PiHole unbekannte Geräte keinen Internetzugang haben. Allen bekannten Geräten entsprechenden Gruppen zugewiesen.
Unbound:
/etc/unbound/unbound.conf.d/pi-hole.conf
server:
# If no logfile is specified, syslog is used
logfile: "/var/log/unbound/unbound.log"
verbosity: 1
interface: 127.0.0.1
port: 5335
do-ip4: yes
do-udp: yes
do-tcp: yes
# May be set to yes if you have IPv6 connectivity
do-ip6: yes
# You want to leave this to no unless you have *native* IPv6. With 6to4 and
# Terredo tunnels your web browser should favor IPv4 for the same reasons
prefer-ip6: no
# Use this only when you downloaded the list of primary root servers!
# If you use the default dns-root-data package, unbound will find it automatically
#root-hints: "/var/lib/unbound/root.hints"
# Trust glue only if it is within the server's authority
harden-glue: yes
# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
harden-dnssec-stripped: yes
# Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
# see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
use-caps-for-id: no
# Reduce EDNS reassembly buffer size.
# IP fragmentation is unreliable on the Internet today, and can cause
# transmission failures when large DNS messages are sent via UDP. Even
# when fragmentation does work, it may not be secure; it is theoretically
# possible to spoof parts of a fragmented DNS message, without easy
# detection at the receiving end. Recently, there was an excellent study
# >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
# by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
# in collaboration with NLnet Labs explored DNS using real world data from the
# the RIPE Atlas probes and the researchers suggested different values for
# IPv4 and IPv6 and in different scenarios. They advise that servers should
# be configured to limit DNS messages sent over UDP to a size that will not
# trigger fragmentation on typical network links. DNS servers can switch
# from UDP to TCP when a DNS response is too big to fit in this limited
# buffer size. This value has also been suggested in DNS Flag Day 2020.
edns-buffer-size: 1232
# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes
# One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
num-threads: 1
# Ensure kernel buffer is large enough to not lose messages in traffic spikes
so-rcvbuf: 1m
# Ensure privacy of local IP ranges
private-address: 192.168.0.0/16
#private-address: 169.254.0.0/16
#private-address: 172.16.0.0/12
#private-address: 10.0.0.0/8
private-address: fd00::/8
private-address: fe80::/10
Ist es möglich, lokal ausschließlich IPv4 zu nutzen (die Vergabe von IPv6 komplett zu verbieten) und nach aussen dennoch IPv6 zu unterstützen?