Pi-Hole - source IP der clients aus anderem Subnetz weitergeben

Hallo zusammen,

ich nutze aktuell ein Pi-hole und zwei subnetze mit folgendem Aufbau:

(192.168.178.0/24) --> Pihole(192.168.178.10)
|
|
Router (10.10.10.0/16) --> CLients

Der router ist im 192 als auch im 10er netz.

Nun habe ich als DNS Server im 10er netz den Router der wiederrum als Relaqyyserver den pihole eingetragen hat. Klappt alles

Nun meine frage: Im pihole wird die IP adresse der clients aus dem 10er nicht angezeigt bzw durchgeschliffen. sondern die des Router. Gut das ist soweit klar, aber wie kann ich dies dem Router mitteilen, dies nicht zu machen sondern eine art relay der Client Cource IP's zu nutzen?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 2693085901

Url: https://administrator.de/forum/pi-hole-source-ip-der-clients-aus-anderem-subnetz-weitergeben-2693085901.html

Ausgedruckt am: 22.12.2024 um 14:12 Uhr

12 Kommentare

Neuester Kommentar

Moin,

Hast Du für das Interface der Clients NAT in Richtung des pihole aktiv? Dann sieht der pihole nämlich immer nur das Routerinterface und nie den einzelnen Client.

Gruß Looser

Sind auf den clients wirklich der pihole als dns eingetragen oder der router zwischen den netzen?
So wird er immer den router als anfragendes gerät erkennen.

Im pihole wird die IP adresse der clients aus dem 10er nicht angezeigt

Machst du denn NAT auf dem Router aus dem 10er Netz?
Das wäre ja dann ziemlicher Quatsch wenn das 2 lokale IP Netze sind. Diese routet man natürlich ohne NAT und dann werden die IPs auch richtig angezeigt im PiHole.
Leider bist du recht oberflächlich mit der Konfig Beschreibung deines Routers so das eine zielführende Hilfe nicht gerade einfach ist ohne kristallkugeln zu müssen.

Off Topic: Vielleicht auch mal ein Auge auf AdGuard werfen, das etwas fortschrittlicher ist als das etwas in die Jahre gekommene PiHole, da es auch DoH und DoT out of the Box supportet auf dem RasPi. Ebenso deutlich verbesserte Funktionen des App Blockings.
https://www.heise.de/select/ct/2021/7/2101113595336903136
https://blog.daniel.wydler.eu/2021/02/21/adguard-home-im-netzwerk-implem ...

Hallo, sorry für die magere Beschreibung.

Also der Router als knotenpunkt hat kein NAT gesetzt. Reines routing der beiden Netze also.

Problem ist: ich gebe den Clients im 10er netz den Router als DNS (OpenWRT nutzt hier ebenfalls ein dnsmasq): also in dem fall 10.10.10.1

Im Pihole steht natürlich als "Absender" der Router. Das möchte ich aber nicht

Mein Frage daher: kann ich die Client IP's dem Router-DNS mitteilen und dieser wiederum dem PiHole DNS Server? Sodass im Pihole die Client IP's stehen?

Im Pihole steht natürlich als "Absender" der Router.

Gut, das ist klar, denn wenn du den OpenWRT immer als ProxyDNS aus den Subnetzen benutzt dann kommen die eingehenden DNS Requests der Clients am PiHole allesamt logischerweise immer mit der Absender IP des OpenWRTs dort an.
Kannst du dir am PiHole auch immer selber ansehen wenn du dort einmal ein tcpdump port 53 eingibst. Alle Client Requests kommen dann erwartungsgemäß mit der OpenWRT Adresse.
(tcpdump vorher ggf. mit sudo apt install tcpdump installieren)

Die Lösung ist aber kinderleicht...
Definiere am DHCP Server des OpenWRT für die Clients nicht den OpenWRT als DNS Server sondern immer die PiHole Adresse. Dann fragen die Clients den PiHole direkt und dann stimmt es wieder mit der Anzeige der Clients im PiHole. 😉
Der tcpdump wird dir das dann auch zeigen.

Zitat von @aqui:

Im Pihole steht natürlich als "Absender" der Router.

Danke, das direkte verteilen des PIHOLE-DNS per DHCP klappt auch, nur möchte ich gerne den OpenWRT den clients mitteilen, also proxy DNS.

Somit gehe ich davon aus, es gibt keine möglichkeit die Client IP's "durch zu reichen" ?

nur möchte ich gerne den OpenWRT den clients mitteilen, also proxy DNS.

Dann wirst du aber immer die Source IP verlieren.
Zäume das Pferd doch andersrum auf. Client -> PiHole -> OpenWRT Proxy
Also das der PiHole als Uplink den OpenWRT hat.
Anders geht es nicht...wie auch?!

Moin,

Somit gehe ich davon aus, es gibt keine möglichkeit die Client IP's "durch zu reichen" ?

doch, gibt es wenn der jeweilige DNS Server das Feature EDNS Client Subnet (ECS, EDNS0) unterstützt.

Gruß,
Dani

@Dani
hört sich jetzt viel zu kompliziert an nur dafür die Statistik Seite im PiHole passt

Die idee mit dem EDNS ist eigentlich dann wohl die iteressanteste hier. Aber wird dies voll von dnsmasq (welches ja auf pi (DNSFTL) als auch openwrt läuft) unterstützt?

Habe hierzu evtl. passende configs gefunden.

--add-mac[=base64|text]
    Add the MAC address of the requestor to DNS queries which are forwarded upstream. This may be used to DNS filtering by the upstream server. The MAC address can only be added if the requestor is on the same subnet as the dnsmasq server. Note that the mechanism used to achieve this (an EDNS0 option) is not yet standardised, so this should be considered experimental. Also note that exposing MAC addresses in this way may have security and privacy implications. The warning about caching given for --add-subnet applies to --add-mac too. An alternative encoding of the MAC, as base64, is enabled by adding the "base64" parameter and a human-readable encoding of hex-and-colons is enabled by added the "text" parameter.   
--add-cpe-id=<string>
    Add an arbitrary identifying string to DNS queries which are forwarded upstream. 
--add-subnet[[=[<IPv4 address>/]<IPv4 prefix length>][,[<IPv6 address>/]<IPv6 prefix length>]]
    Add a subnet address to the DNS queries which are forwarded upstream. If an address is specified in the flag, it will be used, otherwise, the address of the requestor will be used. The amount of the address forwarded depends on the prefix length parameter: 32 (128 for IPv6) forwards the whole address, zero forwards none of it but still marks the request so that no upstream nameserver will add client address information either. The default is zero for both IPv4 and IPv6. Note that upstream nameservers may be configured to return different results based on this information, but the dnsmasq cache does not take account. Caching is therefore disabled for such replies, unless the subnet address being added is constant.

    For example, --add-subnet=24,96 will add the /24 and /96 subnets of the requestor for IPv4 and IPv6 requestors, respectively. --add-subnet=1.2.3.4/24 will add 1.2.3.0/24 for IPv4 requestors and ::/0 for IPv6 requestors. --add-subnet=1.2.3.4/24,1.2.3.4/24 will add 1.2.3.0/24 for both IPv4 and IPv6 requestors. 
--umbrella[=deviceid:<deviceid>[,orgid:<orgid>]]
    Embeds the requestor's IP address in DNS queries forwarded upstream. If device id or organization id are specified, the information is included in the forwarded queries and may be able to be used in filtering policies and reporting. The order of the deviceid and orgid attributes is irrelevant, but must be separated by a comma.   