Fast nur noch Queries von der FBox?

Troy_McClure · August 7, 2018, 12:00pm

Hi,

damit auch die Anfragen der User im Gastnetzwerk der FBox gefiltert werden dachte ich es sei eine gute Idee der FBox als übergeordneten DNS auch einfach den Pi-Hole zu verpassen... Die Clients im internen Netz bekommen direkt den Pihole als DNS über den DHCP der FBox. Jetzt sehe ich in der Admin-Console dass der Löwenanteil der Anfragen von der Box kommt, obwohl zur Zeit niemand im Gastnetzwerk ist und die Anfragen z.B. auch definitiv von meinem PC kommen...

Ausserdem ist bei den Forward Destinations die Box auf einmal ganz vorne, vorher war der größte Teil local...

was könnte da los sein?

DL6ER · August 7, 2018, 4:34pm

Schau mal in Deinem /var/log/pihole.log nach was passiert.

Troy_McClure · August 7, 2018, 5:06pm

Die Datei gibt es nicht...

/var/log/pihole ist auch leer...

DL6ER · August 7, 2018, 5:07pm

Ja, mein Fehler ... zu warm im Westen und schon zu viele Nachrichten heute hier geschrieben ... ich habe die Datei oben angepasst.

Troy_McClure · August 7, 2018, 6:16pm

Sei dir verziehen
Danke erstmal, allerdings kann ich mit der log auch nicht viel anfangen, da sehe ich nur dass eben sehr viel an die Fritzbox weitergeleitet wird. warum die Fritzbox selbst aber überhaupt den Pi-Hole fragt ist mir ein Rätsel, alle Clients sollten ja ansich direkt den Pi-Hole fragen (tun sie auch, zumindest ist er als einziger DNS hinterlegt auf allen clients)

Debug Token: otar9a0thf

DL6ER · August 7, 2018, 7:15pm

Also die Tatsache, dass die Box viel gefragt wird ist komisch, wird aber vermutlich daran liegen, dass sie irgendwie schneller antwortet als die anderen forward destinations (OpenDNS). Warum das Verhältnis local zu 192.168.178.1 so schief liegt ist mir auch nicht klar. Wenn Du mal im Query Log schaust, passt das Bild dann? Es würde ja bedeuten, dass durchschnittlich 70% an die Box weitergeleitete werden und nur noch ca. 10% aus dem Cache beantwortet werden. Siehe mein Beispiel im Folgenden woran das liegen könnte:

Möglicherweise hast Du ansonsten eine Totschleife erzeugt. Folgender hypothestischer Hergang:

Dein PC stellt eine Anfrage "google.de"
Dein Pi-hole leitet diese an die schnellste Forward Destination weiter (FritzBox)
Deine Fritzbox weiß nicht wer "google.de" ist und fragt daher das Pi-hole da sie weiß dass das ein DNS Server ist
Das Pi-hole sieht eine eingehende Anfrage von der Fritzbox, und leitet die Anfrage wiederum weiter (ebenfalls an die Fritzbox)
...
...
... (das geht ein paar mal hin und her)
Irgendwann erkennt der interne Mechanismus in FTL das hier eine Endlosschleife vorliegt und stellt die Anfrage sicherheitshalber auch an OpenDNS woher dann auch eine Antwort kommt.

Das Phänomen:
In den Punkten 1 hat Dein Rechner eine Anfrage generiert. In den Punkten 3, 5, 7, ... hat die Fritzbox eine Anfrage gestellt (erklärt eine hohe Zahl an Anfragen von der Fritzbox). Außerdem wurde sehr oft die Fritzbox gefragt was den hohen Anteil in der Forward Destinations Grafik erklären würde.

Lösung: Entweder die Fritzbox als Forward Destination raus nehmen oder sicherstellen, dass die Fritzbox die Anfragen nicht wiederum an das Pi-hole stellt um Endlosschleifen von vorn herein zu unterbinden.

Troy_McClure · August 7, 2018, 7:26pm

Ich hab gerade bei einer anderen Frage den Tipp bekommen Conditional forwarding zu aktivieren, das scheint ja neu zu sein und würde die Box als Upstream DNS überflüssig machen... Das mit der Schleife klingt nämlich ganz schlüssig.
blöderweise hatte ich jetzt conditional forwarding aktiviert und hatte die box auch noch als custom DNS drin, jetzt hat sich das FTL erstmal verabschiedet und kommt nicht wieder hoch, mal gucken wie es nach einem Reboot aussieht...

DL6ER · August 7, 2018, 7:39pm

Wenn Du irgendwelche Fehlermeldungen hast, dann immer her damit. Conditional Forwarding gibt es schon länger es ist aber etwas was ich selbst nicht zuhause nutze (mein Pi-hole regelt alles, inkl. DHCP für LAN + WLAN).

Troy_McClure · August 7, 2018, 8:03pm

Ich hab es erst jetzt drin, ich musste vorher eine ältere Version benutzen weil das dnsmasq auf dem NAS zu alt war... ich dachte jetzt wo es integriert ist kann ich ja updaten, aber nachdem ich das häkchen gesetzt habe ist mir alles um die Ohren geflogen... dnsmasq kann nicht gestartet werden, webinterface läuft nach einer neuinstallation auch nicht mehr alles Katastrophe. evtl. muss ich doch wieder zurück auf die v3.2.1

naja damit hab ich erstmal genug zu tun

DL6ER · August 7, 2018, 8:05pm

Bitte denk daran, dass wir das vom System bereitgestellte eigenständige dnsmasq nicht mehr benutzen sondern pihole-FTL mit nun integriertem dnsmasq (!) den DNS Server stellt. Du solltest niemals mehr irgendwas mit sudo service dnsmasq ... ausführen (außer vielleicht stop ).

Troy_McClure · August 7, 2018, 8:20pm

irgendwas macht es aber scheinbar noch mit dnsmasq... wenn ich es stoppe sieht es so aus:

sobald dnsmasq wieder läuft:

DL6ER · August 7, 2018, 8:22pm

sudo service dnsmasq stop
sudo service pihole-FTL restart

sollte alles in Gang bringen falls Du mit dem aktuellen Pi-hole v4.0 arbeitest. Falls Du noch mit Pi-hole v3.x arbeitest, dann brauchst Du noch dnsmasq.

Da ich z.Zt. eigentlich nur Fragen zum Thema Pi-hole v4.0 beantworte, hatte ich das bei Dir ohne Nachfrage auch einfach leichthin angenommen.

Troy_McClure · August 7, 2018, 8:23pm

ja, hab heute das update gemacht und seitdem hat es sich ziemlich zerlegt. das Problem mit der Schleife hatte ich aber schon vorher, der Rest lief aber...

root@Outer_Space:/var/www/html/admin# sudo service dnsmasq stop
[warn] Stopping DNS forwarder and DHCP server: dnsmasq[....] (not running) ... (warning).
root@Outer_Space:/var/www/html/admin# sudo service pihole-FTL start
Not running

chown: cannot access ‘/etc/pihole/dhcp.leases’: No such file or directory
Failed to set capabilities on file `/usr/bin/pihole-FTL' (Invalid argument)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file

dnsmasq: failed to create listening socket for port 53: Permission denied

DL6ER · August 7, 2018, 8:26pm

Okay, was sagt

df -h

und

mount

?

Troy_McClure · August 7, 2018, 8:27pm

root@Outer_Space:/var/www/html/admin# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 1.8T 1.4T 462G 75% /
/dev/shm 245M 0 245M 0% /dev/shm
root@Outer_Space:/var/www/html/admin# mount
rootfs on / type rootfs (rw)
/dev/root on / type ext4 (rw,relatime,user_xattr,barrier=1,journal_checksum,data=ordered)
none on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=250708k,nr_inodes=62677,mode=755)
none on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
none on /proc type proc (rw,nosuid,nodev,noexec,relatime)
none on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
/tmp on /tmp type tmpfs (rw,relatime)
/run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
/proc/bus/usb on /proc/bus/usb type usbfs (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw,relatime)
/dev/md2 on /volume1 type ext4 (rw,relatime,user_xattr,synoacl,barrier=0,journal_checksum,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)
none on /config type configfs (rw,relatime)
none on /proc/fs/nfsd type nfsd (rw,relatime)
proc on /proc type proc (rw,relatime)

DL6ER · August 7, 2018, 8:30pm

Okay, das sieht gut aus. Das Dateisystem ist ext4.

Was ist die Ausgabe von

sha1sum /usr/bin/pihole-FTL

?

Troy_McClure · August 7, 2018, 8:31pm

e61d4502d044ce54d3645a32fe8e78b5da4ee9f4 /usr/bin/pihole-FTL

DL6ER · August 7, 2018, 8:35pm

Hmm, das macht mir Sorgen. Welches Betriebssystem ist das? Beim Hauptsystem auf einer 2TB ext4 Platte ist das vermutlich kein Raspberry Pi.

Troy_McClure · August 7, 2018, 8:35pm

Nee, das ist ein Debian Chroot auf einer DS213j^^ Frickelei

DL6ER · August 7, 2018, 8:36pm

Hmm, es kann sein dass Pi-hole v4.0 nicht in einer chroot Umgebung läuft...